OpenSSO Secure Token Server – 4

This blog is the final in a series that will describe how to deploy OpenSSO to protect Oracle WebLogic resources by configuring it as a Secure Token Server.

Part 1 is available here, part 2 is available here and part 3 is available here

Modify the WSS Configuration Files

The following steps describe how to configure OpenSSO WSS Agents.

  • Download and unzip the openssowssagents.zip file. This file contains OpenSSO Web Services Security Agents, based on JAX-WS Handlers.
  • Expand the zip file.
  • Copy the resources/keystore.jks, resources/.keypass, and resources/.storepass files to a convenient directory.  This directory is represented by @KEYSTORE_LOCATION@ in the <wssagents_unzip_location>/config/AMConfig.properties file.
  • Update AMConfig.properties for StockService as follows:

##### Following properties need to be updated for OpenSSO WSS Agents #####

com.iplanet.services.debug.directory=C:/Documents and Settings/Administrator/StockService/Debug

com.iplanet.am.naming.url=http://ws-provider.ltes.com:80/opensso/namingservice

com.iplanet.am.server.protocol=http

com.iplanet.am.server.host=ws-provider.ltes.com

com.iplanet.am.server.port=80

com.iplanet.am.services.deploymentDescriptor=/opensso

com.sun.identity.loginurl=http://ws-provider.ltes.com:80/opensso/UI/Login

com.sun.identity.saml.xmlsig.keystore=C:/Sun/Middleware/user_projects/domains/wss/resources/service.jks

com.sun.identity.saml.xmlsig.storepass=C:/Sun/Middleware/user_projects/domains/wss/resources/.storepass

com.sun.identity.saml.xmlsig.keypass=C:/Sun/Middleware/user_projects/domains/wss/resources/.keypass

com.sun.identity.saml.xmlsig.certalias=service

com.sun.identity.liberty.ws.trustedca.certaliases=cacert:Self-CA

com.sun.identity.wss.wsc.providername=

com.iplanet.am.cookie.encode=true

/*

* Security Credentials to read the configuration data

*/

com.sun.identity.agents.app.username=agentAuth

com.iplanet.am.service.password=changeit

com.iplanet.am.service.secret=

##### End of properties for OpenSSO WSS Agents #####

  • Update AMConfig.properties for StockClient as follows:

##### Following properties need to be updated for OpenSSO WSS Agents #####

com.iplanet.services.debug.directory=C:/Documents and Settings/Administrator/StockClient/Debug

com.iplanet.am.naming.url=http://ws-provider.ltes.com:80/opensso/namingservice

com.iplanet.am.server.protocol=http

com.iplanet.am.server.host=ws-provider.ltes.com

com.iplanet.am.server.port=80

com.iplanet.am.services.deploymentDescriptor=/opensso

com.sun.identity.loginurl=http://ws-provider.ltes.com:80/opensso/UI/Login

com.sun.identity.saml.xmlsig.keystore=C:/Sun/Middleware/user_projects/domains/wsc/resources/client.jks

com.sun.identity.saml.xmlsig.storepass=C:/Sun/Middleware/user_projects/domains/wsc/resources/.storepass

com.sun.identity.saml.xmlsig.keypass=C:/Sun/Middleware/user_projects/domains/wsc/resources/.keypass

com.sun.identity.saml.xmlsig.certalias=client

com.sun.identity.liberty.ws.trustedca.certaliases=cacert: Self-CA

com.sun.identity.wss.wsc.providername=

com.iplanet.am.cookie.encode=true

/*

* Security Credentails to read the configuration data

*/

com.sun.identity.agents.app.username=agentAuth

com.iplanet.am.service.password=changeit

com.iplanet.am.service.secret=

##### End of properties for OpenSSO WSS Agents #####

Modify the StockService Application

  • Expand the unsecured StockService.war file that was created previously using the following command:

jar -xvf StockService.war

  • Create a lib directory under the WEB-INF directory if lib does not exist already then, copy all <wssagents_unzip_location>/lib/*.jar files to the WEB-INF/lib directory.
  • Copy the <wssagents_unzip_location>/config/AMConfig.properties file to the WEB-INF/classes directory.
  • Merge the <wssagents_unzip_location>/config/server_handlers.xml file into the existing configuration file WEB-INF/classes/com/sun/stockquote.

The files must be merged so that the following handler is the first handler in the handler chain:

<handler>

<handler-name>

ServerHandler

</handler-name>

<handler-class>

com.sun.identity.wssagents.jaxws.server.ServerHandler

</handler-class>

</handler>

  • Build the secured StockService application into the StockService.war file with the following command:

jar -cvf StockService.war *

  • Deploy the StockService.war file to the WebLogic container.
  • Access the web service WSDL with the following URL:

http://ws-provider.ltes.com:7001/StockService/StockService?wsdl

Modify the StockClient Application

  • Expand the unsecured StockClient.war file that was created previously using the following command:

jar -xvf StockClient.war

  • Create a lib directory under the WEB-INF directory if lib does not exist already. Then, copy all <wssagents_unzip_location>/lib/*.jar files to the WEB-INF/lib directory.
  • Copy the previously updated AMConfig.properties file into the WEB-INF/classes directory.
  • Merge the <wssagents_unzip_location>/config/server_handlers.xml file into the existing configuration file WEB-INF/classes/server_handlers.xml.

The following handler must be the first handler in the handler chain:

<handler>

<handler-name>

ClientHandler

</handler-name>

<handler-class>

com.sun.identity.wssagents.jaxws.client.ClientHandler

</handler-class>

</handler>

  • Add the following client filter to the WEB-INF/web.xml file.

<filter>

<filter-name>

LoginFilter

</filter-name>

<filter-class>

com.sun.identity.wssagents.jaxws.client.ClientFilter

</filter-class>

</filter>

<filter-mapping>

<filter-name>

LoginFilter

</filter-name>

<url-pattern>

/*

</url-pattern>

</filter-mapping>

  • Build the secured StockClient application into the StockClient.war file with the following command:

jar -cvf StockClient.war *

  • Deploy the StockClient.war file to the WebLogic.
  • Access the web service client with a URL of the following form:

http://ws-client.ltes.com:8001/StockClient

  • The URL redirects to the OpenSSO Authentication service UI for end-user authentication to the default authentication module, as shown in the following figure:

  • After successfully authenticating to the OpenSSO server, the browser is redirected the StockClient application page.

  • Click GetQuote to display the web service response from the StockService application.

OpenSSO Secure Token Server – 3

This blog is the third in a series that will describe how to deploy OpenSSO to protect Oracle WebLogic resources by configuring it as a Secure Token Server.

Part 1 is available here and part 2 is available here.

Update the Web Service Provider Profile

The following steps describe how to create the Web Service Provider profile.

  • Click Web Service Provider. Under Agent click WSP.

  • Select all Security Mechanisms and set Preserve Security Headers in Message to true.

  • Click the checkboxes for Is Request Signature Verified, Is Response Signed.

  • Enter the Web Service End Point URL:

http://ws-provider.ltes.com:7001/StockService/StockService

  • Enter the key aliases, keystore location and password.

  • Save the changes.

Update the Agent Authenticator Profile

This Agent Authenticator (agentAuth) acts as the application user. It authenticates WSS agents to the OpenSSO server through the OpenSSO client SDK in order to retrieve agent profiles or configurations from the OpenSSO server. To do its job, agentAuth requires permission to read the configuration information of the newly created WSC and WSP agent profiles.

Set the agentAuth read permission as follows:

  • Select the Agent Authenticator tab.

  • Under Agent, click agentAuth to edit it.
  • Under the heading Agent Profiles allowed ensure that WSC and WSP are selected.
  • Save the changes and log out of OpenSSO.

Edit the Security Token Service Configuration Parameters

Log onto OpenSSO and navigate to Configuration -> Global -> Security Token Service.

Make the following changes:

  • In the Token Issuance Attributes section change the issuer to Self-CA and the Certificate Alias Name to opensso

  • In the Key Store section change the Private Key Alias and the Public Key Alias of Web Service (WS-Trust) Client to opensso.

  • In the Token Validation Attributes section change the Trusted Issuers to cacert:Self-CA.

Change the Cookie c66Encode Flag

The c66Encode flag resolves a problem whereby some application servers return the wrong cookie id if certain characters are used in the id.  C66Encoding ensures that those characters are not used in the cookie id.

Follow these steps to turn c66Encoding on.

  • Log onto the OpenSSO console and navigate to Configuration -> Servers and Sites.
  • Click the Default Servers Settings button.
  • Select the Advanced tab.
  • Change the value of com.iplanet.am.cookie.c66Encode to true

  • Save the changes
  • Restart the OpenSSO web container

OpenAM – Adaptive Risk Module

Two new features in OpenAM 10 stand out for me:

  • Adaptive Authentication Module
  • Open Identity Gateway
In this post I’ll look at the Adaptive Risk Module.

Adaptive Risk Module

A couple of years ago one of our customers wanted to be able to adjust the authentication level in OpenSSO based on whether an external or internal user was accessing a protected web resource.  Internal users would just be required to perform LDAP authentication whereas external users would be required to perform both LDAP and one time password authentication.  All users had LDAP user accounts.

OpenSSO authentication levels were considered but these apply to all users and the customer wanted to be able to determine the authentication level on a per user basis.  It was finally decided that external users would have an attribute value set in their profile and I wrote a custom authentication module that presented a standard LDAP authentication page to the user, verified successful authentication before checking the specified attribute value in the user’s profile and then presenting one time password authentication via redirect callback if it was set.

If presented with the same scenario today I would use the Adaptive Risk Module.

In this solution an authentication chain is created as depicted in the following image.

The chain consists of LDAP module, the Adaptive Risk Module and HOTP module.

All users are required to perform LDAP authentication. Upon success OpenAM calls the Adaptive Risk module.

This module is designed to assess risk during authentication so that OpenAM can determine whether to require the user to complete further authentication steps.  The risk threshold is the first value set in the module and various checks can be enabled, each with their own score.  For instance, if the Profile Attribute check is set it can be given a value that exceeds the risk threshold if true thus requiring the user to be passed to the next authentication module, in this case HOTP.

The checks that could be used to determine the authentication risk in this scenario are the IP Address Range and Profile Attribute.  Other available checks include:

  • Authentication Level
  • IP Address History
  • IP History Check
  • Known Cookie
  • Device Cookie
  • Max Time Since Last Login
  • Geo Location
  • Request Header
Using this authentication method would have saved over two weeks in coding and testing effort.

Arsenal v Newcastle

Arsenal have the opportunity to close to within a point of Spurs on Monday after their defeat to Everton on Saturday.

It’s a home game against Newcastle that we’d normally be expected to win.  However, Arsenal have been in this position many times over the last few years and have each time failed to take the opportunity.  OK, in the past they’ve been vying for the title but at the end of the day the team’s got previous for choking under pressure.  I only hope that this time we have the character to get a result when it’s needed.  The good news is that the team has finally shown over the last two weeks that it has.

Diaby’s injured again (wow he lasted a whole 20 minutes) but on the bright side Santos, Arteta and Benayoun should be available.  A win will put pressure on Spurs and my feeling is that both Arsenal and Chelsea will be hunting them down from now until the end of the season.  This is new for Spurs and we’ll see how well they cope.

The papers are full of stories of all the players that Arsenal are interested in buying.  We’ve been here before.  In fact every year around this time the stories start and every year we buy no one.  This year should be different though.  After the mess that the club made in last summer’s transfer window culminating in the mad dash to buy players after the 8-2 drubbing at United I’m sure we’ll be in and out of the transfer market early this time so I’m not surprised to hear that negotiations have already started with players like Podolski.

Considering the club is trying to persuade van Persie to sign a new contract I don’t think there’s any choice but to invest in new players.  However, there’s no way the club is going to spend the 65-70 million pounds that is being touted in some newspapers.

Oh well that’s for the summer, in the meantime there’s the small matter of beating Newcastle on Monday.

A Look at OpenAM 10

ForgeRock was born from the ashes of Sun Microsystems and continues the development of Sun’s Open Source product OpenSSO renamed OpenAM since Oracle now own the rights to the OpenSSO product name.

OpenAM 10 Early Access is now available and promises the following features:

  • Open Identity Gateway
    • Java based reverse proxy for integrated SSO
    • Integrates legacy and complex applications
    • Credential replay and header passing
    • Fedlet integrated with the gateway
    • Federate enables any web application
    • Deployed as a reverse proxy or co-located with the application
  • SAML2 IdP Adaptor extension
    • new plug-in hook in the IdP
    • Allows to execute code and even interact with the user before releasing the SAML2 assertion
  • Risk Based Authentication
    • Authentication plug-in model
    • Sample risk auth modules and documentation
  • Integration enhancements
    • SharePoint 2010
    • AD Password reset
  • Self Service User Interface
  • Shared module with OpenIDM
  • User registration and password management
  • Yubikey Authentication Module
  • OAuth 2.0 Authentication Module (Relying party)
  • Upgrade tools
  • Easy upgrade to OpenAM 10.0

Since the sale of Sun both products have been pretty much the same with both Oracle and ForgeRock performing necessary bug fixes to Sun’s last release.  I now expect to see a divergence of the products as ForgeRock enhances OpenAM along the lines of the product road-map while Oracle will quietly kill off OpenSSO.

Over the next few weeks I intend to test-drive ForgeRock’s suite of products:

  • OpenAM – Authentication, Authorization, Federation and Security Token Service.
  • OpenDJ – LDAP v3 Directory Server.
  • OpenIDM – Identity Management and Provisioning
  • OpenIGS – Identity Gateway and Reverse Proxy Server

I can’t sign off without saying a huge well done to Arsenal for last night’s performance.

Trying to overturn a 4 goal deficit against a team like AC Milan was always going to be a huge task but the boys came close, failing by a single goal.  Let’s hope that performance sets the team up for the rest of the season and gives the players the belief that they can overhaul Spurs in 3rd place.