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/

More about → Single Sign-on and the OBSSOCookie

SSO in Web Services Using SAML

Introduction:


Web Services provides a standard mean of interoperating between different software
applications running on a variety of platforms. The simplest web service
consists of a SOAP message for communication and a WSDL for web service
description. Web services use XML extensively which are very well understood
technology. WSDL document defines services as collection of network endpoints
or ports.


One of the main problems in distributed Web Services is security standards. Due to
different platforms the interpretation of security information has different
meaning in different security context. For instance if a J2EE application try
to exchange security information with a COM+ application, the data sent by J2EE
application will not be recognizable to COM+.
The other problem in distributed Web Services application is the
capability for single-sign on. Security Assertion Markup Language (SAML) is a
standard proposed by OASIS to solve problem like security information exchange
and how Single Sign on capabilities be provided within distributed web services
application.


Exploring SAML:


SAML is a set of specifications used for transferring information like user
authentication, entitlement, and attributes to identity provider (IP) which can
authenticate the user and allow access to resources on a server provider. In SAML a third party which is identity provider will assert the authentication information provided by the consumer and will return SAML assertion which can be passed with any incoming request to
the target or resource provider which will identify the assertion and allow
access to the corresponding activity.

By
obtaining the assertion from identity provider consumer can pass it with any
request. The same assertion can be used universally and by any part of
application which is a step forward to interoperability in security context.


All
the security services which implemented SAML are able to interpret security
information transferred by one service to another which makes SAML one of the
most accepted solutions for Web Services Security. The Assertion generated by identity provider
can be used by consumer as long as it is trusted by target or service provider.
The Service Provider can accept the principal an allow authentication.


SAML
provides three types of assertions:


1.
Authentication assertion


2.
Authorization decision assertion


3.
Attribute assertion.


Authentication
Assertion


The
authentication information is received by identity providers which process this
information and authorization assertion is made along with authorization
decision and attributes assertion.
Authentication Assertion is composed of the identity of issuer and the
principal, the period for which the assertion will be valid and some creation
time information. It also input some information about the provider system and
validation time etc.


The
following is the Authentication Statement Schema









































Attribute
Assertion

More Here

Courtesy:http://asadroshan.wordpress.com/2011/01/12/sso-in-web-services-using-saml/

More about → SSO in Web Services Using SAML

A Closer Look at Centrify DirectControl's Web SSO Solution

Core Features


At a high-level, the DirectControl for web/Java agent provides the following five key features:


* SPNEGO Support for Application Servers: the DirectControl for web/Java agent natively extends the security layer of each application server to implement the SPNEGO protocol for Kerberos and NTLM authentication and single sign-on. Per Wikipedia: "SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports...SPNEGO's most visible use is in Microsoft's "HTTP Negotiate" authentication extension. It was first implemented in Internet Explorer 5.01 and IIS 5.0 and provided single sign-on capability later marketed as Integrated Windows Authentication. The negotiable sub-mechanisms included NTLM and Kerberos, both used in Active Directory."


In effect DirectControl is extending the "secret handshake" that Microsoft provides between IE and IIS. Which means that now with DirectControl you can use IE or any other browser that supports SPNEGO and have that SSO experience to not only IIS but to non-Microsoft web servers such as Apache, JBoss, WebLogic and WebSphere (running on either the Windows or UNIX/Linux platforms).
* Kerberos Support for web/Java Applications: Kerberos is the mature approach that Microsoft uses for single sign-on in an all-Microsoft environment. While Kerberos is available for non-Microsoft platforms, like UNIX and Linux, it can be difficult for a non-expert to deploy and manage a Kerberos stack for use in single sign-on. DirectControl for web/Java, in cooperation with DirectControl for Systems, automatically deploys, configures and manages the entire Kerberos stack for the application server and OS that your custom application is installed on.


Optionally, NTLM can also be used for authentication in an environment or system where Kerberos is not functional or appropriate. NTLM is an older technology provided by Microsoft for authentication.
* Authorization based on Active Directory Groups: Using J2EE standards, DirectControl for web/Java can populate the proper J2EE roles based on Active Directory Groups. Additionally, custom user attribute can be passed to the application from Active Directory. This allows a custom web application to provide role-based access and personalization based on a centrally managed identity in Active Directory, regardless of the platform the application server runs on.
* Active Directory Federation Services (ADFS) Support: ADFS, based on industry standards such as the WS-* web services specifications, provides a platform for single sign-on across multiple applications during a single browsing session. Additionally, ADFS provides services that allow authentication and authorization to happen across security, organizational and domain boundaries. These services are included in Windows Server 2003 R2 and 2008. Follow this link for more information on our ADFS web SSO agents for non-Microsoft web servers.
* Support for SSO to the underlying operating systems: Centrify DirectControl delivers secure access control and centralized identity management by seamlessly integrating your UNIX, Linux, Mac, web and database platforms with Microsoft Active Directory. DirectControl effectively turns a non-Microsoft system into an Active Directory client, enabling you to secure that system using the same operating system-level authentication, authorization and Group Policy services currently deployed for your Windows systems.

This means by packaging the DirectControl agent for the operating system and application server, along with installation and configuration documentation and support and services of the DirectControl for web/Java products into a single comprehensive solution, Centrify can help provide a true single sign-on solution at both the OS and application layer that better interoperates with your enterprise.

More Here

Courtesy:http://www.centrify.com/blogs/tomkemp/centrify_active_directory_integration_with_web_java.asp

More about → A Closer Look at Centrify DirectControl's Web SSO Solution

Sharepoint 2007 : Configure and start the Microsoft Single Sign-On service

To use single sign-on, the Microsoft Single Sign-On service (SSOSrv) must be installed on all Microsoft Windows front-end Web servers in the farm. SSOSrv must also be installed on all servers running Excel Services. If the Business Data Catalog search is used, SSOSrv must also be installed on the index server.
SSOSrv is configured by using the Services console. When configuring the service, a logon account is required. The logon account must meet all of the following criteria:

• Must be a domain user account. It cannot be a group account.
• Must be an Office SharePoint Server farm account.
• Must be a member of the local Administrators group on the encryption-key server. (The encryption-key server is the first server on which you start SSOSrv.)
• Must be a member of the Security Administrators role and db_creator role on the computer running Microsoft SQL Server.
• Must be either the same as the single sign-on administrator account, or a member of the group account that is the single sign-on administrator account.

Configure and start the Microsoft Single Sign-On service

1. On the server, click Start, Control Panel, Administrative Tools, and then click Computer Management.
3. In the Computer Management console, expand Services and Applications, and then click Services.
4. Right-click Microsoft Single Sign-On Service, and then choose Properties.
5. On the General tab, change the Startup type to Automatic.
6. On the General tab, under Service Status, click Start.
7. Click OK to save your changes and close the Properties window.
8. Repeat steps 1 through 6 for each applicable server in the farm.Source : http://technet.microsoft.com/en-us/library/cc262932.aspx#Section1

More Here

Courtesy:http://panca.wordpress.com/2009/04/07/sharepoint-2007-configure-and-start-the-microsoft-single-sign-on-service/

More about → Sharepoint 2007 : Configure and start the Microsoft Single Sign-On service