Interview questions about Login, urgent!
henry_cui
Greenhorn
Posts: 5
posted 16 years ago
Hello, everyone,
I was asked twice about the same question:Login.
A project is as follows:
There are different roles in the system: employee, manager, general manager. When they login, a servlet will dispatch them to different pages. e.g, when employee login, servlet dispatch employee to employee page. Manager login, servlet dispatch manager to manager page.
There are actually two steps in this action, first, it must check the user name, password. Then it must determin the role, then dispatch.
Some say we can use LDAP(Authentation). But LDAP can't determin the role(Authorization).
Some say there is a database table behind the scene. But what are these tables? I heard there are many tables behind the scene.
Some say we can use deployment descriptor. But some books say in real project, we'd better use LDAP or DB.
What are the complete best solutions for this problem?
Best Regards,
Henry
I was asked twice about the same question:Login.
A project is as follows:
There are different roles in the system: employee, manager, general manager. When they login, a servlet will dispatch them to different pages. e.g, when employee login, servlet dispatch employee to employee page. Manager login, servlet dispatch manager to manager page.
There are actually two steps in this action, first, it must check the user name, password. Then it must determin the role, then dispatch.
Some say we can use LDAP(Authentation). But LDAP can't determin the role(Authorization).
Some say there is a database table behind the scene. But what are these tables? I heard there are many tables behind the scene.
Some say we can use deployment descriptor. But some books say in real project, we'd better use LDAP or DB.
What are the complete best solutions for this problem?
Best Regards,
Henry
BJ Grau
Ranch Hand
Posts: 234
posted 16 years ago
I don't know the best answer, but I can tell you two ways I have done this.
On one project, LDAP did not contain any passwords, only general employee info. The actual directory behind LDAP was an X500. We authenticated our users against the customer's NT domain, and then authorized them with our application's own DB. We used LDAP for general employee info that was not specific to our application. We did this because the customer maintained this directory for all it's employees and we knew we had a readily available source of dynamic employee data that our application did not have to maintain (such as phone #, cube location, etc). We did not have access to insert users into this LDAP directory and no password inforamtion was stored in it. In this case LDAP was jsut a way for our applciation to have accurate data that would be otherwise hard to keep up to date for thousands of users.
On another, the LDAP was used to authenticate the user, and then returned a user key which could be used to look up the user's authorization and personal info in the DB. In this case we could insert new users into the LDAP directory and we had some control over it.
The answer is going to depend a lot on what the customer already has in place and what it is they want to do.
Hope this helps.
On one project, LDAP did not contain any passwords, only general employee info. The actual directory behind LDAP was an X500. We authenticated our users against the customer's NT domain, and then authorized them with our application's own DB. We used LDAP for general employee info that was not specific to our application. We did this because the customer maintained this directory for all it's employees and we knew we had a readily available source of dynamic employee data that our application did not have to maintain (such as phone #, cube location, etc). We did not have access to insert users into this LDAP directory and no password inforamtion was stored in it. In this case LDAP was jsut a way for our applciation to have accurate data that would be otherwise hard to keep up to date for thousands of users.
On another, the LDAP was used to authenticate the user, and then returned a user key which could be used to look up the user's authorization and personal info in the DB. In this case we could insert new users into the LDAP directory and we had some control over it.
The answer is going to depend a lot on what the customer already has in place and what it is they want to do.
Hope this helps.
henry_cui
Greenhorn
Posts: 5
posted 16 years ago
Hello, BJ Grau,
Thank you very much for your reply. It's very informative.
Nowadays there's always tough questions.
In EJB, we can use the deployment descriptor information to check the permissions by using isCallerInRole(). I don't know if your project uses EJB.
But when we use DB to check the permission, the interviewer continue to ask the following question: For every method, do you always go to the DB to get the permission info? I really don't know the answer. It's obvious that this will affect performance.
Someone told me they use Toplink or something to load the information to the web server so that they don't need to always to go to the DB. Someone says we can write a cache. Can you tell me how to solve it?
Thank you again.
Henry
Thank you very much for your reply. It's very informative.
Nowadays there's always tough questions.
In EJB, we can use the deployment descriptor information to check the permissions by using isCallerInRole(). I don't know if your project uses EJB.
But when we use DB to check the permission, the interviewer continue to ask the following question: For every method, do you always go to the DB to get the permission info? I really don't know the answer. It's obvious that this will affect performance.
Someone told me they use Toplink or something to load the information to the web server so that they don't need to always to go to the DB. Someone says we can write a cache. Can you tell me how to solve it?
Thank you again.
Henry
