OpenSSO - Open Web SSO [Single Sign-On]

The Open Web SSO project (OpenSSO) provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. OpenSSO provides the foundation for integrating diverse web applications that might typically operate against a disparate set of identity repositories and are hosted on a variety of platforms such as web and application servers. This project is based on the code base of Sun Java System Access Manager, a core identity infrastructure product offered by Sun Microsystems.

OpenSSO Enterprise won the 'Security' category of the Developer.com Product of the Year 2009 awards.

OpenSSO provides complete and flexible access management and federation management capabilities, in the form of a simple lightweight Java EE application thereby scaling horizontally and vertically as enterprise security needs change over time.

Sun OpenSSO Builds

Sun offers Open SSO in two different distributions

· Open SSO Enterprise

· Open SSO Express

The differences between these two distributions are as below

Open SSO Enterprise	Open SSO Express
Commercially supported version	Available as open source as well as paid support
New features released every 12 months	New features available in every 3 months
Hot patches and fixes available when required	No patches or fixes.
Extensive manual and automated testing by Sun QA team	Extensive automated testing and moderate manual testing by Sun QA team
Suitable for Production	Suitable for development and staging environment.

 

Architecture Of OpenSSO

The following services are provided:

1. Authentication

The Authentication service is based on Java Authentication and Authorization Service (JAAS). Several authentication modules are supplied out of the box, examples: LDAP, Radius, SecureID, Windows Desktop, Certificate, and Active Directory. New authentication modules can be added using a JAAS based SPI.

2. Authorization (Policy)

The Policy service provides the authorization service of OpenSSO. It is a rules based engine. A Policy comprises:

Service name schema for the policy type that describes the syntax of policy (amPolicy.xml)

3. Session (SSO)

A session also serves as an efficient inter-process communication mechanism to communicate simple attributes related to the specific authenticated user.

4. Auditing/Logging

A common Logging service is invoked by all components - both residing on the server and those on the client. This allows the actual mechanism of logging to be separated from contents of the logs, which are specific to each component.

5. Identity Repository access

The Identity Repository service allows OpenSSO to integrate an existing user repository, such as the corporate LDAP server. It provides an abstraction to access user profiles as well as group & role assignments consumed by client and other OpenSSO services. This abstraction is capable of spanning multiple repositories even of different types. The current implementation supports any LDAPv3 compliant repository (certified for Sun Directory Server and Active Directory).

6. Federation

Virtual Federation is a recently added feature of OpenSSO. Virtual Federation addresses two key issues in deploying federation:

(i) More than one federation standard in a Circle of Trust and

(ii) Legacy applications and existing authentication mechanisms.

Policy Agents (PAs) are provided as add-on components one for each container type that ease the protection of web based network resources (enterprise applications and services). PAs consume the public APIs mentioned above and take care of the integration with the specific container such that its presence is largely transparent to the contained protected resources.

Features and Benefits of OpenSSO

Sun OpenSSO Enterprise integrates all the capabilities required to handle SSO, authorization, and personalization into a single, comprehensive solution

Sun OpenSSO Express Builds:

• Makes it possible to deploy next-generation features developed by the OpenSSO community with the same support and indemnification provided by commercial releases without having to wait.
• Accelerates time to market for new applications created with next-generation features.

Single WAR File Distribution:

Speeds installation and simplifies configuration by eliminating external dependencies

Simple Product Configuration:

Enables configuration within minutes, no matter how many instances of Sun OpenSSO Enterprise are being deployed

Embedded Directory Server:

• Simplifies deployment by eliminating the need to configure a directory to support the configuration store.
• Provides a robust, scalable directory for maintaining information

Common Task Flows:

Makes common features repeatable, scalable, and easy to use

Centralized Agent Configuration Management:

• Simplifies agent configuration
• Provides a scalable, repeatable method of centrally establishing agent enforcement policies

Centralized Server Configuration:

Allows configuration and management of complex horizontal deployments from an easy-to-use, central console

Virtual Federation Proxy:

• Enables multiple legacy products to start federating before addressing internal SSO issues
• Eliminates need to either federate-enable all existing products or solve SSO problems before federating

Popular Access Management Products

Below are the few Access Management products available and their features are listed.

OpenSSO

• Open Source offering from Sun Microsystems. Same code base as Sun Java Systems Access Manager.
• Available as commercial product (OpenSSO enterprise) as well as free (OpenSSO express).
• Good documentation available.
• Commercial support available through Sun Microsystems.
• Policy agents available for BEA web logic / portal, Sun Java Systems Application Server, proxy server and Web Server, IBM web sphere, Apache Tomcat, IIS and SAP as well as web and J2EE agents.
• OpenDS as embedded data store.
• Code written in Java.
• Single war file distribution

Acegi Security

• Spring framework.
• Good documentation.
• Flexible. Most implementations can be replaced i.e. we can provide custom authentication providers to retrieve credentials from our own schema; we can replace the access decision manager implementation and so on.
• ACL framework is provided. ACL checks are done using the parameters of the method being called i.e. the path (these can be configured to the user level)
• Suitable for Spring Framework applications.
• Needs external framework integration for SSO.

JOSSO

• J2EE and spring transparent single sign on.
• Runs in Apache Tomcat, JBoss application server, BEA Web Logic 9 and Web Logic 10 application server, Apache Geronimo application server.
• LDAP support for storing user information and credentials
• Password recovery support.
• “Remember me” support.
• Written in Java
• Pluggable Framework to allow the implementation of custom identity components using Spring or built-in IoC container

Gabriel

• Access management framework written in Java.
• API’s available for extending and implementation.

Shibboleth

• Consists of separate Identity provider and service provider packages.
• Security information travels in SAML.
• Attribute based access control also available.
• Can be integrated with other access manager products as identity provider.
• Policy agent not available. Custom/ third party policy agents will need to be used. This needs to be explored further during evaluation.

Evaluation

OpenSSO is quite a popular open source offering from Sun with code base same as that of SJS Access Manager. Since its commercial and open development happens on the same code base, the quality of the product can be trusted. This has an embedded data store (OpenDS). Also good documentation is available. Policy agents are available to work with OpenSSO.

Acegi security system does not look a likely candidate for evaluation as it is only for spring framework applications.

Gabriel is a framework for securing applications and from the initial evaluation it looks like there would be a need for lot of custom development if we use the same.

Shibboleth is again another popular offering in open source access management products. Attribute based access control is an interesting feature. Policy agents are not available for this. We might need to look at SAML (Security Assertion Markup Language) compliant third party agents or develop custom agents using SAML.

OpenSSO Vs Others

Feature	Oracle Access Manager	OpenSSO	JOSSO
Policy Agents	Weblogic	Weblogic, Sun(Application and Web Server), tomcat, apace, JBoss	Weblogic, tomcat, apace, JBoss
User / group provisioning through access manager	Yes	Yes	No
Pre and Post operation tasks	Yes	No	No
Centralized Policy Management	Yes	Yes	No
Application Policy management	No	No	Yes
User Interface pages for project requirements	Existing pages customized	Development required	Development required
Commercial Support	Yes (Oracle)	Yes (Sun Microsystems)	Yes (Atricore)

OpenSSO Installation

Install a GlassFish web container in global zone of virtual machine. Then deploy OpenSSO in the web container and verify the deployment.

Tasks are:

• Install GlassFish Application Server software
• Deploy OpenSSO

An OpenSSO instance is running in the GlassFish web container on port 8080 in the global zone. The configuration data store, which holds the OpenSSO configuration, also holds the user directory. This deployment scenario is suitable only for very simple test deployments.

Preparation

Navigating Around the Solaris Sandbox

1) In a terminal window

2) Run the lab –p command

The lab –p command prepares the Solaris Sandbox zones for networking and GUI display.

3) Start a web browser:

Firefox &

Download the required software from the given link:

Software - GlassFish application server (version 2)

URL – https://glassfish.dev.java.net

Software – OpenSSO Enterprise 8.0

URL – https://opensso.dev.java.net

Copy to /opt/software/

Task 1  -  Installing GlassFish Application Server

1) Install the GlassFish software:

a. Run the following command:

/opt/software/glassfish-v3preview/glassfish-v3-prelude-unix.sh

The Welcome dialog box appears.

b. Click Next.

A dialog box with the GlassFish license appears.

c. Select I Accept the Terms in the License Agreement, and then click Next.

The Installation Directory dialog box appears.

d. Type /opt/glassfish in the Installation Directory field, then click Next.

The Administration Settings dialog box appears.

e. Select Provide Username and Password, and fill out fields in the Administration Settings dialog box as follows:

• Username – admin
• Password – cangetin

f. Click Next.

The Update Configuration dialog box appears.

g. Uncheck Install Update Tool, Then Click Next.

The Ready to Install dialog box appears.

h. Click Install.

Message appear in the Progress dialog box as GlassFish installation proceeds.

The Product Registration dialog box appears.

i. Select Skip Registration, then click Next.

The Summary dialog box appears.

j. Click Exit

2) Start the GlassFish domain administration server(DAS):

/opt/glassfish/bin/asadmin start-domain domain1

Do not create additional GlassFish instance. deploy OpenSSO software to the DAS, strictly as a convenience for learning purpose.

Task 2  -  Deploying OpenSSO

Deploy the OpenSSO software.

1) Deploy the OpenSSO web archive (WAR) file to the DAS using the asadmin CLI:

/opt/glassfish/bin/asadmin deploy –user admin /opt/software/opensso-ent- 8.0/opensso/deployable-war/opensso.war

2) Verify that the OpenSSO WAR file was deployed.

/opt/glassfish/bin/asadmin list-components –user admin

OpenSSO <web> appears in the list of components deployed to the GlassFish instance.

3) In a browser window, navigate to the following URL:

http://example.com:8080/opensso

A page appears with a link that lets you create a new configuration

4) Configuration the OpenSSO instance:

a. Click Create New Configuration (in the Custom Configuration section of the page).

The General page appears.

b. Enter data in the Default User Password section of the General page as follows:

• Default User [amAdmin] : Type cangetin
• Confirm : Type : cangetin

Click Next.

The Server Settings page appears.

Caution - On some Systems, when you attempt to scroll down to the next button, the OpenSSO configuration refuses to scroll down. This is a know problem – OpenSSO issue #1966. One of the following workarounds should fix the problem:

- Press the F11 key to use Firefox in full-screen mode. When you no longer need full-screen mode, press F11 again to leave full-screen mode.

c. Enter data in the Server Settings page as follows:

• Server URL: Verify that the default value is  http://example.com:8080
• Cookie Domain : Verify that the default value is .example.com. The cookie domain value should have a pried (“.”) as its first character.
• Configuration Directory : Type /opt/opensso/instance

Click Next.

The Configuration Data Store Settings page appears.

Note - In the OpenSSO configuration pages, the terms configuration directory and configuration data store might be easily confused.

The configuration directory is a file system directory that contains flat files used for system configuration and other purposes. XML schema files, directory server schema files, log files, and debug files are all located in the configuration directory. In Sun Java System Access Manager (Access Manager) 7.1 – the predecessor release to OpenSSO – these files were stored in various locations, depending on operating system platform. For example, on the Solaris Operating System (Solaris OS), these files were located in the /etc and /var directories.

The configuration data store is an Lightweight Directory Access Protocol (LDAP) directory that contains information about OpenSSO realm, authentication, policy, and other configuration. By default, this LDAP directory in an OpenDS directory that is entirely managed by OpenSSO.

d. Click Next.

The User Data Store Settings page appears.

e. Select OpenSSO User Data Store and click Next.

The Site Configuration page appears.

f. Enter data in the Site Configuration page as follows :

• Will This Instance be deployed behind a Load Balancer?

Select No.

Click Next.

The Default Policy Agent User page appears.

g. Enter data in the Default Policy Agent User page as follows:

• Password : Type cangetinam
• Confirm Password : Type cangetinam

Click Next.

The Configuration Summary Details page appears.

Review the values you have entered. If incorrect values appear on the Configuration Summary Details page, make corrections as necessary.

h. Click Create Configuration.

Progress messages inform you of configuration progress.

The configuration Completes page appears.

i. Click Proceed to Login.

5. The OpenSSO login screen appears.

Log in to OpenSSO as the amAdmin user. The password is cangetin

6. The OpenSSO console start page appears.

7. Log out of the OpenSSO console.

Now fully-operational OpenSSO instance is available. Use this instance as needed for experimentation, research, demonstrating features, and so forth.