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

OpenSSO Secure Token Server – 2

This blog is the second 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.

Configure the WebLogic Trust Keystores

Ensure that the WebLogic containers are using the keystore and trusted certificate stores crea:ted previously.  In Windows this can be done by editing the create service command file as follows

  • Edit the createSvc.cmd file to include the following JAVA_OPTIONS parameters for the web service container and save as createWSPSvc.cmd:
    set JAVA_OPTIONS=-Djavax.net.ssl.trustStore=C:\Sun\Middleware\user_projects\domains\wss\resources\cacerts
    -Djavax.net.ssl.keyStore=C:\Sun\Middleware\user_projects\domains\wss\resources\server.jks
    -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStorePassword=changeit
  • Repeat for the web service client and OpenSSO containers.
  • Run the commands to create the services.
    For example:
    echo off
    SETLOCAL
    set DOMAIN_NAME=wsp
    set USERDOMAIN_HOME=C:\Sun\Middleware\user_projects\domains\wss
    set SERVER_NAME=AdminServer
    set PRODUCTION_MODE=false
    set JAVA_VENDOR=Sun
    set JAVA_HOME=C:\Sun\Middleware\jdk160_24
    set MEM_ARGS=-Xms256m -Xmx512m
    set JAVA_OPTIONS=
    -Djavax.net.ssl.trustStore=C:\Sun\Middleware\user_projects\domains\wsp\resources\cacerts
    -Djavax.net.ssl.keyStore=C:\Sun\Middleware\user_projects\domains\wsp\resources\server.jks
    -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStorePassword=changeit
    call “C:\Sun\Middleware\wlserver_10.3\server\bin\installSvc.cmd”
    ENDLOCAL

Configure OpenSSO Web Service Profiles

Web Services Client http://ws-client.ltes.com:8001
Web Services Provider
http://ws-provider.ltes.com:7001
OpenSSO Server
http://opensso.ltes.com
This deployment uses the default WSC and WSP profiles shipped with OpenSSO.

  • Access the OpenSSO Console by entering the following URL:
    http://opensso.ltes.com/opensso
  • Log in to the OpenSSO Console as amadmin.
  • Go to Access Control -> Default realm -> Agents, as shown below:

Update the Web Service Client Profile

  • Select the Web Service Client tab:

  • In the Agent panel select WSC.
  • Click the WSC profile to edit it.
  • In the Security section select the STSSecurity as the Security Mechanism, SecurityTokenService as the STS Configuration and set Preserve Security Headers in Message as true.

  • Check Is Request Signed Enabled and Is Response Signature Verified in the Signing and Encryption section then uncheck all signing values except Body.

  • Enter the key aliases, keystore location and password

  • Save the changes.

OpenSSO – Secure Token Server

I think that the demise of OpenSSO has been greatly over exaggerated. There are positions open for people with OpenSSO skills and there are many forums with people asking for help in solving OpenSSO/OpenAM problems.

One question that comes up regularly is how to configure OpenSSO as a Secure Token Server.

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

A Secure Token Server is a third-party broker that allows a Web Service client to authenticate and receive a security token which is then sent to a Web Service Provider. The Web Service Provider validates the token and verifies that it came from a trusted secure token server.  It then uses the token to make authentication and authorization decisions.

Create and Deploy the SSL Certificates

This deployment uses self-signed certificates. The following instructions describe how to create and install them using OpenSSL and keytool.

  1. Create root certificate.
  2. Create the trusted certificates store
  3. Create key and signing requests.
  4. Sign the requests.
  5. Create the keystores.
  6. Add the public certificates to the keystores.

It is assumed that openssl.cfg has already been created.

Create the root certificate

openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config openssl.cnf

Create the trusted certificates store

openssl x509 -outform DER -in cacert.pem -out cacert.cert
keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias cacert -file cacert.cert

Create a Key and Signing Request

Client

openssl req -new -nodes -out clientReq.pem -keyout private/clientKey.pem -config openssl.cnf

Server

openssl req -new -nodes -out serverReq.pem -keyout private/serverKey.pem -config openssl.cnf

OpenSSO

openssl req -new -nodes -out openssoReq.pem -keyout private/openssoKey.pem -config openssl.cnf

Sign the Requests

Client

openssl ca -out clientCert.pem -config openssl.cnf -infiles clientReq.pem

Server

openssl ca -out serverCert.pem -config openssl.cnf -infiles serverReq.pem

OpenSSO

openssl ca -out openssoCert.pem -config openssl.cnf -infiles openssoReq.pem

Create the Keystores

The following instructions use the ImportKey class to import the keys into the Java keystore.

Client

  • Convert both, the key and the certificate into DER format
    openssl pkcs8 -topk8 -nocrypt -in private\clientKey.pem -inform PEM -out clientKey.der -outform DER
    openssl x509 -in clientCert.pem -inform PEM -out clientCert.der -outform DER
  • Import the files into the JKS
    java ImportKey clientKey.der clientCert.der
  • Copy and rename the keystore
    copy “\<home directory>\keystore.ImportKey client.jks
  • Change keystore password:
    keytool -keystore client.jks -storepasswd
  • Change certificate password:
    keytool -keypasswd -alias importkey -keypass importkey -new changeit -keystore client.jks
  • Change the alias
    keytool -keystore client.jks -storepass changeit -changealias -alias importkey -keypass changeit -destalias client
  • Check the Keystore Contents
    keytool -list -v -keystore client.jks

Server

  • Convert both, the key and the certificate into DER format
    openssl pkcs8 -topk8 -nocrypt -in private\serverKey.pem -inform PEM -out serverKey.der -outform DER
    openssl x509 -in serverCert.pem -inform PEM -out serverCert.der -outform DER
  • Import the files into the JKS
    java ImportKey serverKey.der serverCert.der
  • Copy and rename the keystore
    copy \<home directory>\keystore.ImportKey server.jks
  • Change keystore password:
    keytool -keystore server.jks -storepasswd
  • Change certificate password:
    keytool -keypasswd -alias importkey -keypass importkey -new changeit -keystore server.jks
  • Change the alias
    keytool -keystore server.jks -storepass changeit -changealias -alias importkey -keypass changeit -destalias server
  • Check the Keystore Contents
    keytool -list -v -keystore server.jks

OpenSSO

  • Convert both, the key and the certificate into DER format
    openssl pkcs8 -topk8 -nocrypt -in private\openssoKey.pem -inform PEM -out openssoKey.der -outform DER
    openssl x509 -in openssoCert.pem -inform PEM -out openssoCert.der -outform DER
  • Import the files into the JKS
    java ImportKey openssoKey.der openssoCert.der
  • Copy and rename the keystore
    copy \<home directory>\keystore.ImportKey opensso.jks
  • Change keystore password:
    keytool -keystore opensso.jks -storepasswd
  • Change certificate password:
    keytool -keypasswd -alias importkey -keypass importkey -new changeit -keystore opensso.jks
  • Change the alias
    keytool -keystore opensso.jks -storepass changeit -changealias -alias importkey -keypass changeit -destalias opensso
  • Check the Keystore Contents
    keytool -list -v -keystore opensso.jks

Add the Public Certificates to the KeyStores

Server

  • Add the Client Public Certificate
    keytool -importcert -alias client -trustcacerts -keystore server.jks -storepass changeit -file clientCert.der
  • Add the OpenSSO Public Certificate
    keytool -importcert -alias opensso -trustcacerts -keystore server.jks -storepass changeit -file openssoCert.der
  • Check the contents of the Keystore
    keytool -list -v -keystore server.jks
    Client
  • Add the Server Public Certificate
    keytool -importcert -alias server -trustcacerts -keystore client.jks -storepass changeit -file serverCert.der
  • Add the OpenSSO Public Certificate
    keytool -importcert -alias opensso -trustcacerts -keystore client.jks -storepass changeit -file openssoCert.der
  • Check the contents of the Keystore
    keytool -list -v -keystore client.jks

OpenSSO

  • Add the Client Public Certificate
    keytool -importcert -alias client -trustcacerts -keystore opensso.jks -storepass changeit -file clientCert.der
  • Add the Server Public Certificate
    keytool -importcert -alias server -trustcacerts -keystore opensso.jks -storepass changeit -file serverCert.der
  • Check the contents of the Keystore
    keytool -list -v -keystore opensso.jks

That’s it for now.  I’ll post the next installment next week.

Arsenal

I think that Arsene Wenger has bought well so far in this transfer window but he has to get a more disciplined and defensive minded midfielder in to replace Alex Song.  With two weeks of the transfer window remaining I’ve decided not to give my opinion on the team until it closes.

OpenAM – Open Identity Gateway

The Open Identity Gateway is based on a reverse proxy architecture.  The great benefit of OpenIG is that it makes it possible to extend an SSO or Federation network to existing applications without modification.

There are two versions of the Open Identity Gateway, the Gateway and the Federation Gateway.  The Federation Gateway consists of the Gateway plus the Federation libraries.

OpenIG is a Java web application deployed in an application server.  The configuration information for each module within the gateway is stored in a json file which is a text file that can be updated directly using a text editor or via the management console.

Requests flow through the gateway as defined in a configured chain of filters and handlers.

Filters are responsible for processing HTTP requests in the Gateway and may be combined in a chain to act on the input stream coming from the browser or the output stream returned back from the target application.  These filters can be configured to extract data from the incoming requests and replay credentials depending on the requirements of the back-end application and can also be configured to retrieve user credentials from a database, an LDAP directory, a flat file,  HTTP headers,  SAML assertions or an SSO agent before they are submitted to the application by a handler.

The final processing of every chain ends in a call to a handler.  A handler may simply call another chain or it may send the request on to the target application.

When deployed within an existing SSO deployment the SSO agent is installed on the gateway and intercepts access requests as normal.  However, on successful authentication, the agent passes the required authentication information to the gateway and the gateway passes the user credentials to the back-end application in the format required.

When the Federation Gateway is enabled, the Gateway acts as the Service Provider in a Circle of Trust with a SAML2 compliant Identity Provider.  The Federation service supports both IDP and SP initiated SAML2 profiles.

The Federation Gateway may be a Service Provider in the classic Federation use case where the IDP and SP are different companies or domains.

The Gateway SP may also be used as a Policy Enforcement Point for a proprietary Access Management solution deployed within an enterprise.

Installing the policy agent on a reverse proxy in front of one or more back-end web resources is not new.  This is recognized as an efficient way of protecting web resources that are similarly configured.  When deploying OpenAM in this architecture would it be more efficient to front the web resources with a true web proxy or OpenIG?

I’ve not been able to find any information to answer this question so will run some tests in the lab to find out.

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.