How does single sign-on work? Do I have to create the privileges and roles for each application, or do I create...
the roles and privileges only once?
The definition for single sign-on from The Open Group is, "Single sign-on (SSO) is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure, and is therefore highly desirable but difficult to implement." How single sign-on systems work is implementation dependent. For example, in a Windows NT (or 2000) network, applications can use integrated Windows NT authentication mechanisms. If set up to require particular users or groups of users, anyone who is allowed access that has already been authenticated to that domain will be granted access. They do not need to sign on again. Novell takes a different approach. All applications still have their own usernames and passwords, but they are stored in what they call SecretStore. According to their Web site, "Once you authenticate to NDS, SecretStore automatically collects and encrypts your application passwords the time you use them. When you next attempt to use an application, the application's client will try to verify that you are authenticated to NDS. If NDS responds that you are authenticated, the client requests your application password from the SecretStore. NDS retrieves your encrypted password from the SecretStore and sends it to your workstation, where it is decrypted and used to give you access to the desired application. This entire process takes only seconds and is completely transparent: Once you authenticate to NDS, Single Sign-on manages the rest of your logon processes." There are other methods of implementing single sign-on as well. What this means in any case, is that you need to define who has access to each application and to what level, on a per application basis. However, if you define standard groups or roles, it should be easy use the same definitions from application to application. Implementing single sign-on in a secure way is not trivial and needs to be well thought out before beginning implementation.
Dig Deeper on Single-sign on (SSO) and federated identity
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.