Q

How single sign-on works

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 first 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.

This was first published in May 2001

Dig deeper on Enterprise Single Sign-On (SSO)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close