Everything about Single Sign on - Kerberos Authentication
INSTANTLY dtSearch TERABYTES OF POPULAR DATA TYPES; hundreds of reviews, etc.!
I have seen so many users are requesting for single sign on mechanism implementation and configuration. I read so many websites for this and finally came out with the conclusion that Kerberos Authentication mechanism is the best way to implement Single sign on. I have consolidated all information of Kerberos authentication here which will helps you a lot.
What is Single Sign On?
Single sign on is a session/user authentication process that allows a user to provide his or her credentials once in order to access multiple applications. The single sign on authenticates the user to access all the applications he or she has been authorized to access. It eliminates future authenticaton requests when the user switches applications during that particular session.
Web Single sign on works strictly with applications accessed with a web browser. The request to access a web resource is intercepted either by a component in the web server, or by the application itself. Unauthenticated users are diverted to an authenticaton service and returned only after a successful authentication.
Benefits of Single Sign-On
Benefits of single sign-on include:
1. Reducing password fatigue from different user name and password combinations
2. Reducing time spent re-entering passwords for the same identity
3. Can support conventional authentication such as Windows Credentials (i.e., username/password)
4. Reducing IT costs due to lower number of IT help desk calls about passwords
5. Security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users
6. Centralized reporting for compliance adherence.
Types of Common Single Sign-On
1. Kerberos based
2. Smart card based
3. OTP - One-time password Token
4. Integrated Windows Authentication
We will discuss about Kerberos Authentication based single sign on. The main advantage of this is you need to log in only once on server and run multiple application without
requiring the password. The main intension behind the implementation is to run all the application under the security context of the user. The following are the components of
Kerberos Authentication protocol:
1. AS = Authentication Server
2. TGS = Ticket Granting Server
3. SS = Service Server
4. TGT = Ticket Granting Ticket
The introduction discussed the problems associated with password based authentication and, in particular, how passwords can be collected by eavesdropping. In addition to the
security concern, password based authentication is inconvenient; users do not want to enter a password each time they access a network service. This has led to the use of even
weaker authentication on computer networks: authentication by assertion.While more convenient for the user, authentication by assertion hardly qualifies as authentication at all. Examples include the Berkeley R-command suite and the IDENT protocol. With authentication by assertion, applications assert the identity of the user and the server believes it. Such authentication is easily thwarted by modifying the application.
This may require privileged access to the system, which is easily obtained on PCs and personal workstations. While most uses of authentication by assertion require that a
connection originate from a ``trusted'' network address, on many networks, addresses are themselves simply assertions.Stronger authentication methods base on cryptography are required. When using authentication based on crytography, an attacker listening to the network gains no information that would enable it to falsely claim another's identity. Kerberos is the most commonly used example of this type of authentication technology. Unfortunately, strong authentication technologies are not used as often as they should be, although the situation is gradually improving.
How Kerberos works?
The Kerberos Authentication System uses a series of encrypted messages to prove to a verifier that a client is running on behalf of a particular user. The Kerberos protocol is
based in part on the Needham and Schroeder authentication protocol, but with changes to support the needs of the environment for which it was developed. Among these changes are the use of timestamps to reduce the number of messages needed for basic authentication, the addition of a ``ticket-granting'' service to support subsequent authentication without re-entry of a principal's password, and different approach to cross-realm authentication (authentication of a principal registered with a different authentication server than the verifier). To Setting up the authentication server and implementation of Kerberos Protocols see http://gost.isi.edu/publications/kerberos-neuman-tso.html.
Kerberos is a method to distribute session keys for use in encrypting traffic between two entities in a network. These session keys include a timestamp so that they are valid for a limited duration (preventing replay attacks), and are provided by a Key Distribution Center (KDC). The KDC must be implemented on a secure platform, because it holds the
identities of all parties involved in the Kerberos system. The KDC contains two services: an Authentication Service that handles the initial request and a Ticket Granting
Service that makes use of an encrypted channel for requests to other services. It should not be used for other services because of the danger that those services might compromise the Kerberos database. The following is the standard Bob-Alice example to see how Kerberos Authentication works:
1. Alice requests access to the Ticket Granting Server (TGS) from the KDC in plaintext.
2. The KDC sends a session key for the TGS (encrypted in Alice’s secret key).
3. Alice uses the session key to get a Ticket Granting Ticket (TGT) from the TGS and subsequently uses that session key and the TGT to obtain tickets for new services. This
prevents her from having to continually send traffic encrypted in her secret key (which gives more data to brute-force decoding attack).
4. When Alice requests a service on Bob, she sends a request to the TGS encrypted with her session key that contains her TGT, a newly constructed Authenticator to identify
her, and the service identifier for Bob.
5. The TGS returns a ticket valid for use with Bob and also a new session key to use when communicating with Bob, encrypted in the session key for the TGS.
6. Alice sends the Ticket (which includes the specific service requested) and her Authenticator for that ticket to Bob.
7. Bob decrypts the ticket (which is encrypted with Bob’s secret key), and extracts the session key for the session with Alice. Bob uses the session key to decrypt the authenticator received from Alice.
The Kerberos protocol ends at this point, with Alice and Bob mutually authenticated (since only the true Bob could decrypt the Ticket), and with a randomly generated session key they can use to encrypt further traffic for the service. Each service needs to have its own session key, although different applications might use the same principals to create
their unique session keys.
To build Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication, you will need to follow very simple steps see
1. Confirm That the Client Account Is Configured for Delegation
2. Confirm That the Server Process Account Is Trusted for Delegation
Downside of Kerberos Authentication mode
1. Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers and fallback authentication mechanisms.
2. Kerberos requires the clocks of the involved hosts to be synchronized. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration requires that clock times are no more than 10 minutes apart. In practice Network Time Protocol daemons are usually used to keep the host clocks synchronized.
3. The administration protocol is not standardized and differs between server implementations. Password changes are described in RFC 3244.
4. Since the secret keys for all users are stored on the central server, a compromise of that server will compromise all users' secret keys.
5. A compromised client will compromise the user's password
3. You can refer http://www.codeproject.com/KB/aspnet/SingleSignon.aspx which talks about implememntation of single sign on in ASP.NET at Cookie and Domain Level.
4. http://technet.microsoft.com/en-us/library/cc780469.aspx#w2k3tr_kerb_what_pckk talks about Kerberos Authentication, Architecture and benifits.
Popularity (6482 Views)