Single sign-on

Single sign-on:

Single sign-on enables users to authenticate (log in) once and gain access to multiple web applications.

Usage example

Log in to one web application (e.g. your intranet), then move between your other web applications without having to log in repeatedly.

Centralized authentication

Centralized authentication is when an end-user has the same username and password used across all web applications, even if the application cannot participate in single sign-on. This is often a major milestone before single sign-on is achieved within an organization

Usage example

• Consolidate all of your logins down to a single username and password. Your users will no longer need to remember multiple usernames and passwords
• Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.
• Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar.

Logging in to Google Apps using SAML

In Microsoft Office SharePoint Server 2007, single sign-on (SSO) authentication enables users to access multiple system resources without having to provide authentication credentials more than once.

Cookie and Domain Level

• Cookies are restricted to a certain domain level for security reasons. Based on FRC 2901 and 2965, cookies can’t be set to a top-level domain such as .com, .org, .gov, etc.
• The minimum domain level required is the second. For example, mysite.com (second level) and public.mysite.com (third level) are both fine to set a cookie.
• The third level domain and beyond are often called “sub domains”. www.myiste.com, public.mysite.com, and art.mysite.com are all sub domains of the second level domain mysite.com.
• If a domain name ends with a two letter country code, a minimum of third level domain will be required.
• A cookie set to a second-level domain is visible at all its third-level domains. However, a cookie set to a third-level domain is not visible at its parent second level domain and at other sub domains.
• If no domain name is specified when a cookie is written, the cookie’s domain attribute defaults to the domain name in which the application resides. For example, if a cookie is set by the page http://public.mysite.com/myapp/defauylt.aspx without specifying a domain attribute, the domain of the cookie will default to public.mysite.com. As a result, the cookie will only be visible at this particular sub domain - public.mysite.com. It is not visible at another sub domain like art.mysite.com or at its second level domain mysite.com

Forms Authentication Ticket and Cookie

• ASP.NET keeps track of a user through a Forms authentication ticket which is a securely encrypted text string. This ticket is passed back and forth between a web server and a client browser to persist the user authentication status
• During login, the user’s credentials are first verified against a data store, and then the FormsAuthentication.SetAuthCookie method (or other methods) is called to log the user into the application.
• This method call generates a Forms authentication ticket and at the same time creates a Forms authentication cookie to hold the ticket. In other words, upon successful authentication, ASP.NET creates a Forms authentication cookie that has the value of the Forms authentication ticket. Both the ticket and the cookie are securely encrypted by the Framework.
• Please note that the authentication ticket is generally saved into a cookie unless the ASP.NET application is specified as “cookieless”, in which case, the ticket will be appended to a URL by the Framework. This is beyond the scope of this article.

Single Sign-on Within a Sub Domain

• Forms authentication is done through a Forms authentication ticket, if all applications share one authentication ticket, a user will only be required to log in once, thus, single sign-on. Let’s say we have two applications with these URLs: http://public.mysite.com/app1/default1.aspx   http://public.mysite.com/app2/default2.aspx
• As you can see, they are basically two virtual directories under the same sub domain - public.mysite.com. A cookie written by app1 will be visible by app2, and vice versa. However, this does not mean when a user logs into app1, he is automatically logged into app2. The reason is that each ASP.NET application, by default, uses its own encryption keys to create a Forms authentication ticket and cookie. Therefore, the cookie written by app1 can’t be successfully read by app2, even though it is visible to app2.

Windows Authentication

• The client's identity is called a security principal. To authenticate with a server application, the client provides some form of credentials to allow the server to verify the client's identity. After the client's identity is confirmed, the application can authorize the principal to perform operations and access resources.
• If your application uses an Active Directory user store, you should use Integrated Windows authentication.
• When you use Integrated Windows authentication with an ASP.NET application, the best approach is to use an Internet Information Services (IIS) authentication method coupled with the Windows authentication provider for ASP.NET.
• With this approach, a WindowsPrincipal object (encapsulating a WindowsIdentity object) is automatically created to represent the authenticated user. You do not need to write any authentication-specific code.
• ASP.NET also supports custom solutions for using Windows authentication, which bypasses IIS authentication. For example, you can write a custom ISAPI filter that checks the user's credentials against Active Directory. With this approach you must manually create a WindowsPrincipal object.

IIS Authentication

• When ASP.NET is configured for Windows authentication, it relies on IIS to authenticate its clients using the configured authentication mode.
• IIS determines the authentication mode for a particular application by examining its metabase settings.
• After successfully authenticating a user, IIS passes the Windows token representing the authenticated user to the ASP.NET worker process (w3wp.exe) in which the ASP.NET application is hosted.
• If your application uses a virtual directory that is configured in IIS to support anonymous access, the token represents the anonymous Internet user account; otherwise, the token represents the authenticated user.