Single Sign-on and the OBSSOCookie

The Oracle Access System implements single-domain and multi-domain single sign-on
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user’s browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.


When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.


When the cookie is generated, part of the cookie is used as an encrypted session token.


The encrypted session token contains the following information:
- The distinguished name (DN) of the authenticated user.
- The level of the authentication scheme that authenticated the user.
- The IP address of the client to which the cookie was issued.
- The time the cookie was originally issued.
- The time the cookie was last updated.

If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.


Unencrypted ObSSOCookie data includes:
- Cookie expiry time.
- The domain in which the cookie is valid.
- An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie


The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.

More Here

Courtesy:http://securidm.wordpress.com/2009/07/13/single-sign-on-and-the-obssocookie/

Single Sign On with Pubcookie

A couple of months ago I had to find a solution to offer a single sign on service in a environment with PHP applications and Plone. I decided to use Pubcookie which is a good solution and has a good documentation although due to its small niche market its community is not very big.

According to SLOCCount most of the code is C and it has almost 50 thousand lines of code

Totals grouped by language (dominant language first):
ansic: 40864 (85.89%)
cpp: 4215 (8.86%)
sh: 2500 (5.25%)

Total Physical Source Lines of Code (SLOC) = 47,579

The documentation is available here, it is clear but from my point of view it lacks of a set of examples. The first time I installed pubcookie I was a bit confused, my first error was trying to install it without understand completely how it worked so my first advice is that you must understand how it works before. The key concept is to realize that the authentication and creation/validation of cookies is going to be performed by the pubcookie service. Your web applications won’t have to deal with this issues anymore.

Have a look at the diagram in the section How Pubcookie Works. In our example with Plone, PHP applications 

and Apache our agents would be:

• User-Agent, your browser
• Application Server, an apache module installed in the server which offers the web application. In our example we would have one for each web application
• Login Server, the service in charge of creating and delivering the important cookies and dealing with the user login form
• AuthN Server, in our example it could be offered by an LDAP server. The Login Server would deal with this authentication server. We only need one

Every time the user visits a protected url (by the apache module / application server) in one of the server applications, the application server finds out whether the users’ cookie is valid or not. Depending on the type of cookie the user provide, it (the application server) can forward the user to the login server or give him access as logged in. Once the application server ensures the user is a valid user with a valid cookie it passes the user to the web application using an apache header, this last step is very important from the security point of view. The web applications will blindly accept the user passed in that HTTP header so it must come only from localhost and only when the apache module checks the request comes from a valid user.

Hands on. Download it and install all the components (keyserver, keyclient, apache module ..), you will need to generate some keys used to sign and encrypt the cookies which are exchanged between the login server and the application server.

Once the daemons are running and the apache module is built, we can start setting up our Plone. The most important part is the configuration of the apache module, there is a Plone plugin (product) calledWebServerAuth that will do the rest of the job.

This is the important part of the apache configuration for our traffic over SSL:


ServerName www.example.com
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/example.crt
SSLCertificateKeyFile /etc/apache2/ssl/example.key
# Prompt for authentication:

AuthType EXAMPLEAuth
PubcookieAppID zope
Require valid-user

# once we know the user is a valid user, we set the HTTP header with the username
RewriteEngine On
RewriteRule .* - [E=RU:%{REMOTE_USER}]
RequestHeader set X_REMOTE_USER %{RU}e

....


As I remarked before, the application (Plone in this case) will accept any user in the HTTP_X_REMOTE_USER header so we must avoid that header when our apache module for pubcookie is not checking it is sent by a valid user. That is, we remove this header unless it goes to the URL protected by the apache module (our application server).


...
RequestHeader unset X_REMOTE_USER
...

At this point, you would be able of using the single sign on service with Plone. The next step would be to add more web applications. If you don’t find a pubcookie plugin for your PHP application, you would have to edit the code to bypass the user and session verification in order to accept the user included in the HTTP_X_REMOTE_USER header.

Last but not least, thanks to cewing and erikrose in #plone IRC channel at freenode.net, they were very helpful 

More Here

Courtesy:http://sanacl.wordpress.com/2010/02/24/single-sign-on-with-pubcookie/

Single Sign-On – Choosing Practical over Paranoid Security

As various business processes are automated in enterprises, a complex IT landscape is created. Multiple applications and platforms require different authentication checks before granting user access. Users need to sign on to multiple systems, each involving a different set of credentials. As a result, accessing systems gets increasingly complicated and frustrating for users and hampers their daily tasks.

Implementing a single sign-on (SSO) security functionality can significantly simplify systems access. SSO provides a unified mechanism to manage user authentication and implement business rules determining user access. As only one set of credentials are needed to access multiple systems, SSO improves usability, increases productivity and reduces helpdesk expenses, without compromising system security.

SSO also reduces human error, because the user logs in once and gains access to all systems without being prompted to log in again for each, a major component of systems failure.

Why is SSO relevant?

The need for SSO is accentuated by several issues enterprises face including:

• Enforcing strong security and password policies at a central level
• Multiple helpdesks
• Need for helpdesks to engage in more value-adding tasks rather than be consumed by resetting passwords for users
• Management of multiple platforms and application models
• Risk of unsecured, unauthorized administrative and user accounts

SSO types you need to know

Two of the most important types of SSO are:

Enterprise SSO

Enterprise single sign-on (ESSO) systems are designed to minimize the number of times that a user must type their ID and password to sign into multiple applications. The ESSO automatically logs users in, and acts as a password filler where automatic login is not possible. Each desktop/laptop is given a token that handles the authentication.

Web SSO

Single sign-on for web-based applications and few supported proprietary closed source web applications. It is a browser-based mechanism, with single sign-on to applications deployed on web servers (domain).

The main differences between ESSO and Web SSO approaches are given in the table below.

ESSO can provide tangible benefits to an enterprise through:

• Enhanced user productivity - users are no longer bogged down by multiple logins and they are not required to remember multiple IDs and passwords
• Improved developer productivity - developers get a common authentication framework – developers don’t have to worry about authentication at all
• Simplified IT administration – the administrative burden of managing user accounts is simplified. The degree of simplification depends on the applications since SSO only deals with authentication
• Reduced password fatigue from different user name and password combinations
• Reduced IT costs due to fewer help desk calls about passwords
• Improved security through reduced need for a user to handle and remember multiple sets of authentication information
• Reduced time spent re-entering passwords for the same identity.
• Integration with conventional authentication such as Windows username/password.
• Centralized reporting for compliance adherence like ISO 27001, etc.

Clearly, SSO functionality is a practical approach to security management in an enterprise. Its detractors highlight that once a password is breached through SSO, then other systems become highly vulnerable. However, while weighing the pros and cons of the SSO approach, its benefits in the form of lesser maintenance and increased usability far outweigh the disadvantages. It can even ensure a better protection of the single password, with stronger policies in place, which may not be practically possible if there were multiple passwords to remember. SSO can be a suitable choice for most enterprises which are struggling with the burden of managing multiple accesses.

More Here

Courtesy:http://aujasus.com/2010/12/07/single-sign-on/

Single SignOn and HTTP Cookies

In this article we will see how the Single Sign On implementations use the HTTP Cookies.

Recently we integrated one of our intranet portals in a company-wide SSO. I wanted to test some functionality in the portal locally before releasing it to the Integration environment but was not able to login to the portal
because the codebase was dependent on the SSO solution.

To address this one of my colleague suggested to hit Integration environment and login there. After this in the same browser window type the URL of the locally deployed application.
Of course this is not going to work. Even if the local application has the similar URI, the browser shall not transmit cookie belonging to other domains to locally deployed application or for that matter applications in different domains.




To understand this we need to see how cookies are used in SSO applications.

Let’s say we own on a portal “foo.com” that is SSO enabled. In a Siteminder enabled SSO solution the cookie named “SMSESSION” is used to store the client identity. Consider that I am developing a webapp that will be part of foo.com named “myapp”. Now when we want to integrate this “myapp” as part of the SSO solution we use a sub-domain say “myapp.foo.com”. Of course we need to write some code that would read this SMSESSION and do the thing that would login the respective user in your application.(in this case “myapp”).
Now why we need the sub-domain in this case.

Domains share their cookie information with their sub-domains.

Hence when the Siteminder solution sets the cookie for “foo.com” and when we navigate to “myapp.foo.com”, the server side code serving “myapp” would get SMSESSION cookie that is set at the domain level. Reading and using SMSESSION, “myapp” can login the user in “myapp” and proceed.

In the figure below I am trying to explain this graphically.
Single SignOn and HTTP Cookies

Single SignOn and HTTP Cookies

Hence if you try a workaround as mentioned above it is not going to work.
In case of tomcat my URL will be “http://localhost:8080/myapp” which is not part of the main domain “foo.com”. Due to this cookie information will never be shared with “myapp” deployed locally.

More Here

Courtesy:http://punekaramit.wordpress.com/2010/09/01/single-signon-and-http-cookies/

SAML Single Sign-On (SSO) Component Suite for .NET

The Security Assertion Markup Language (SAML) single sign-on (SSO) component suite consists of components supporting the SAML v1.1 and SAML v2.0 specifications.

The SAML v1.1 component for .NET is a toolkit for adding support for SAML v1.1 SSO to ASP.NET applications.

The SAML v2.0 component for .NET is a toolkit for adding support for SAML v2.0 SSO to ASP.NET applications.

Fully compliant with the OASIS SAML v1.1 and v2.0 specifications, the components offer .NET developers an easy way to build SAML enabled applications.

Numerous example identity provider and service provider ASP.NET projects are included.

A SAML v1.1 component and a SAML v2.0 component are also available separately.

More Here

Courtesy:http://componentspace.wordpress.com/2010/11/20/saml-single-sign-on-sso-component-suite-for-net/