« Previous month (Jun 2009) | Main | Next month (Aug 2009) »
Thursday Jul 30, 2009

OpenSSO's Secret Place

Look in the OpenSSO-Deploy-Base*/opensso directory and you'll find ssoadm.jsp. This best kept secret is the web version of the ssoadm command line interface and can be used as such - although it's technically a secret. So check it out but don't tell them I sent you.

And now listen to Joni Mitchell and Peter Gabriel singing My Secret Place.

* OpenSSO-Deploy-Base represents the directory in which your particular web container deploys the opensso.war.

Posted at 02:44AM Jul 30, 2009 by Michael Teger in Sun  |  Comments[0]

Wednesday Jul 29, 2009

OpenSSO ASP.NET Fedlet, Multiple Identity Providers and An Angel's Kiss in Spring

I was reading the latest scoop on The Whalpin Chronicles when I found a comment from someone requesting information on how to configure the ASP.NET Fedlet with multiple identity providers. Sure there's a README now but in a week or so this will be official. As Whalpin said, check out the nightly.

This procedure can be followed to enable the ASP.NET Fedlet to communicate with multiple identity providers. It assumes that you have already followed the instructions in Using the ASP.NET Fedlet with OpenSSO Enterprise 8.0 Update 1 to configure and test the ASP.NET Fedlet with an initial identity provider.
  1. Get the standard metadata file for the new identity provider and name it idp2.xml.
    If using OpenSSO, create the identity provider using the Common Tasks work flow and export the identity provider's standard metadata by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp.
  2. Copy idp2.xml to the directory created during initial configuration of the ASP.NET Fedlet.
    During initial configuration, move the /SampleApp directory from the Fedlet-unconfigured.zip file to a directory outside of the decompressed archive. For this article, we will use /tmp/asp.net/SampleApp/App_Data/. See Using the ASP.NET Fedlet with OpenSSO Enterprise 8.0 Update 1 for more information.
  3. Add the identity provider to the appropriate circle of trust by modifying the Fedlet's .COT file.
    1. To add to an existing circle of trust, append the entity ID of the new identity provider (specified by the entityID attribute in the idp2.xml metadata) to the value of the sun-fm-trusted-providers attribute in the appropriate .COT file (for example, fedlet.cot) within the /tmp/asp.net/SampleApp/App_Data/ directory.
      Use a comma (,) as the separator.
    2. To add to a new circle of trust follow this procedure.
      1. Create a new .COT file named (for example, fedlet2.cot) using the existing fedlet.cot as a template.
      2. Change the value of the cot-name attribute in the new .COT file to the name of the new circle of trust.
      3. Add both the new identity provider entity ID and the Fedlet entity ID as the value for the sun-fm-trusted-providers attribute in the new .COT file.
        Use a comma (,) as the separator.
      4. Put fedlet2.cot in the /tmp/asp.net/SampleApp/App_Data/ directory.
      5. Add the new circle of trust name to the value of the cotlist attribute in the ASP.NET Fedlet/service provider extended metadata file, sp-extended.xml.
        For example:
        <Attribute name="cotlist">
        <Value>saml2cot</Value>
        <Value>cot2</Value>
        </Attribute>
         sp-extended.xml is in the /tmp/asp.net/SampleApp/App_Data/ directory.
  4. Create a new file named (for example, idp2-extended.xml) to define the extended metadata for the new identity provider using the existing idp-extended.xml as a template.
    1. Change the value of the entityID attribute to the entityID of the new identity provider.
    2. IF APPLICABLE, change the value of the cotlist attribute to the name of the new circle of trust.
    3. IF APPLICABLE, change the setting of the hosted attribute in the EntityConfig element to false to define it as a remote identity provider.
  5. Send the ASP.NET Fedlet/service provider standard metadata (for example, sp.xml) found in the /tmp/asp.net/SampleApp/App_Data/ folder to the second identity provider.
  6. Import the ASP.NET Fedlet/service provider standard metadata to the appropriate circle of trust on the identity provider side.
    If using OpenSSO, use Register Remote Service Provider under the Common Tasks tab.
  7. Repeat these steps for any number of identity providers using the circle of trust and file-naming formats as discussed.
  8. Using the Internet Information Services (IIS) Manager, restart the Application Pool associated with the ASP.NET application.
    Each ASP.NET web application hosted on IIS is associated with an Application Pool that controls the application's runtime behavior (for example, session properties, memory allocation and garbage collection).
If you use the Sample Application return to the default page for a list of identity providers from which to choose. See To Configure the Sample Application and Test the ASP.NET Fedlet.

Now relax with a glass of Summer Wine as made by Nancy Sinatra and Lee Hazlewood. Strawberries, cherries, and an...oh, you know the rest.

Posted at 09:25AM Jul 29, 2009 by Michael Teger in Sun  |  Comments[0]

Thursday Jul 16, 2009

I Want Web Services Security To Work With One Instance of OpenSSO

Securing web services communications using OpenSSO entails embedding security information within the SOAP request sent to the web service provider (WSP), and within the response returned to the web service consumer (WSC). The communications may then securely pass through multiple intermediaries (firewalls and load balancers, for example) before reaching its intended receiver. The following sections illustrate how to configure and test secure web services communications using OpenSSO and included samples.

In this simple scenario, the message security is achieved using an instance of OpenSSO that communicates with a security agent deployed on both the WSC and WSP sides. The agent profiles for the deployment are configured using OpenSSO. The following procedures illustrate how to configure for web services security and test the configurations using the OpenSSO Stock Quote Service sample.

The first steps are to install three instances of Glassfish Application Server to host the WSC, the WSP and OpenSSO respectively. (Alternately, you can install one Glassfish instance and configure three different domains to host the WSC, the WSP and OpenSSO.) When finished with Glassfish, install OpenSSO. Instructions to install Glassfish and OpenSSO can be found in this (admittedly old but still valid with more recent downloads) blog entry or in the official documentation for Glassfish and OpenSSO. After completing these installations, proceed down the following list of procedures.

Installing a Web Services Security Agent

Follow this procedure to install each security agent with the Express Build 8 installer (not yet released). Before Express Build 8, use the old installer.
  1. Create a text file that contains the agentAuth password in clear text and save it.
    Configured out of the box, agentAuth is an agent profile with permission to read other configured agent profiles including the default wsc, wsp and SecurityTokenService. The agentAuth password is changeit.
  2. Download openssowssproviders.zip.
  3. Create a directory to which you will inflate the ZIP.
    % mkdir /tmp/wssunzip (or \wssunzip on Windows)
  4. Unzip openssowssproviders.zip to the directory.
  5. Stop the Glassfish instance on which the agent is to be installed.
  6. Begin the installation with one of the following steps.
    • On UNIX and Linux, change to the /tmp/wssunzip/bin directory and run chmod 755 wssagentadmin. Following that, run ./wssagentadmin --install or ./wssagentadmin --custom-install.
    • On Windows, change to the \wssunzip\bin directory and run wssagentadmin.bat --install or wssagentadmin.bat --custom-install.
    Both options install the agent but --custom-install allows you to specify the application server instance name whereas the --install assumes the instance name to be server.
  7. Review the license information, if applicable.
  8. Enter the absolute path of the application server domain configuration directory.
  9. Enter the application server instance name if you ran the installer with the --custom-install option.
    In the case of Sun Application Server Enterprise Edition, a domain can have more than one application server instance so enter the name of the application server instance in which you are installing the agent.
  10. Enter the OpenSSO deployment URL using the format protocol://host:port/deployURI.
    protocol is either http or https; host is the fully qualified domain name of the machine on which OpenSSO is running and deployURI is the OpenSSO deployment URI; by default, opensso.
  11. Enter agentAuth, the user with permission to read the agent profiles.
  12. Enter the path to the agentAuth password file created at the beginning of this procedure.
  13. Review the summary and choose Continue with Installation to begin the process.
  14. Restart the Application Server instance or domain after installation is complete.

Adding Java Security Permissions

If the Glassfish Security Manager is enabled, you must add Java security permissions to all domains used in this deployment. If, for example, the WSC and WSP are deployed in one domain, edit only one server.policy file for the both.
  1. Append the Java security permissions defined in /tmp/wssunzip/config/OpenSSOJavaPermissions.txt to the server.policy file of the specific Application Server domain.
    Each Application Server domain has its own standard J2SE policy file named server.policy located in the /ApplicationServer-install/domains/domain-name/config directory.
  2. Restart the Application Server instance.

Deploying the Web Service Client and Web Service Provider Application Sample

The web services security sample contains the /tmp/wssunzip/samples/glassfish/StockQuoteClient and /tmp/wssunzip/samples/glassfish/StockService directories for the client and provider respectively. A /tmp/wssunzip/samples/glassfish/glassfish.properties file contains the configuration properties for Glassfish.
Deploying the Web Service Client Sample
  1. Create a password file for the Glassfish administrator.
    The password file should have read permissions and the line AS_ADMIN_password=password
  2. Edit glassfish.properties as follows: glassfish.home = WSC Glassfish installation directory (for example, /export/glassfishv2ur2/glassfish) glassfish.host = WSC Host where glassfish is installed (for example, opensso.sun.com) glassfish.passwordfile = path to Glassfish administrator password file (for example, /tmp/GFadmin_passwd)
  3. Set JAVA_HOME to JDK1.5 or 1.6 and ensure java and javac are in the PATH.
  4. Replace localhost and 8080 in the StockQuoteClient/src/java/com/samples/GetQuote.java and StockQuoteClient/src/java/com/samples/SOAPMessage.java files with the fully qualified domain name and port to which the web service provider was deployed.
    localhost and 8080 are the default OpenSSO values. These files would need modification if you changed the values for the web service provider during installation.
  5. Change to the StockQuoteClient directory and run WSC-ApplicationServer-install/lib/ant/bin/ant all.
    This will build and deploy the Stock Quote Sample Client to the WSC Glassfish container.
Deploying the Web Service Provider Sample
  1. Create a password file for the Glassfish administrator.
    The password file should have read permissions and the line AS_ADMIN_password=password
  2. Edit glassfish.properties as follows: glassfish.home = WSP Glassfish installation directory (for example, /export/glassfishv2ur2/glassfish) glassfish.host = WSP Host where glassfish is installed (for example, opensso.sun.com) glassfish.passwordfile = path to Glassfish administrator password file (for example, /tmp/GFadmin_passwd)
  3. Set JAVA_HOME to JDK1.5 or 1.6 and ensure java and javac are in the PATH.
  4. Change to the StockService directory and run WSP-ApplicationServer-install/lib/ant/bin/ant all.
    This will build and deploy the Stock Quote Sample Service to the WSP Glassfish container.

Creating the WSC, WSP and STS Agent Profiles Using OpenSSO

The agent profiles for a WSC (wsc), a WSP (wsp), and a Security Token Service (SecurityTokenService) are created when OpenSSO is installed. These can be used with the sample.
Configure the WSC Agent Profile
  1. Login to the OpenSSO console as the administrator; by default, amadmin.
  2. Click the Access Control tab.
  3. Click the top level realm.
  4. Under the Agents tab, click Web Service Client.
  5. OPTIONAL: Click New to create the WSC agent profile if you do not see the default wsc in the table.
    1. Enter wsc as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  6. Click wsc from the table to access the profile.
  7. Select the appropriate Security Mechanism.
    If you select STSSecurity as Security Mechanism, the WSC is requesting that the OpenSSO Security Token Service (STS) generate a token to secure the request to the WSP. See To Configure the STS Agent Profile to create a profile for the Security Token Service.
  8. Check Is Request Signed.
  9. Check Preserve Security Headers in Message.
  10. Specify http://wsp-host-name:portnumber/StockService/StockService as the Web Service End Point.
  11. Save the changes.
  12. Click Back to Main Page.
Configure the Security Token Service Agent Profile
If you did not select STSSecurity as the Security Mechanism in To Configure the WSC Agent Profile, skip this procedure.
  1. Under the Agents tab, click STS Client.
  2. OPTIONAL: Click New to create the Security Token Service agent profile if you do not see the default SecurityTokenService in the table.
    1. Enter SecurityTokenService as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  3. ClickSecurityTokenService from the table to access the profile.
  4. Select the appropriate Security Mechanism.
  5. Enter openssoserver_protocol://openssoserver_host:port/openssoserver_deploy_uri/sts as the Security Token Service End Point.
  6. Enter openssoserver_protocol://openssoserver_host:port/openssoserver_deploy_uri/sts/mex as Security Token Service MEX End Point.
  7. Save the changes.
  8. Click Back to Main Page.
Configure the WSP Agent Profile
  1. Under the Agents tab, click Web Service Provider.
  2. OPTIONAL: Click New to create the WSP agent profile if you do not see the default wsp in the table.
    1. Enter wsp as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  3. Click wsp from the table to access the profile.
  4. Select all Security Mechanism choices.
  5. Check Is Request Signature Verified.
  6. Check Preserve Security Headers in Message.
  7. Specify http://wsp-host-name:portnumber/StockService/StockService as the Web Service End Point.
  8. Save the changes.
  9. Click Back to Main Page.
Review the Agent Authenticator Profile
  1. Under the Agents tab, click Agent Authenticator.
  2. Click agentAuth.
  3. Confirm that wsp, wsc, and SecurityTokenService have been added to the Selected list under the Agent Profiles allowed to Read attribute.
    If not, add them into the list and save the changes.
  4. Log out of the OpenSSO console.

Testing the Sample

  1. Access the stock quote client page at http://wsc-host-name:portnumber/StockQuoteClient/index.jsp.
    The browser will be redirected to the OpenSSO Authentication Service.
  2. Enter the user name and password of an existing OpenSSO user.
    Upon successful authentication, the browser is redirected back to the Stock Quote Service.
  3. Enter "JAVA" (or any other stock symbol) and click Get Quote.
    Stock quote information for the entered symbol is displayed.

And now that you've tested your web services security, check out Bow Wow Wow's video for I Want Candy.

Posted at 10:57AM Jul 16, 2009 by Michael Teger in Sun  |  Comments[2]

Wednesday Jul 08, 2009

OpenSSO Under Replay Attacks

A replay attack occurs when a valid data transmission is maliciously intercepted and retransmitted. Digital signatures alone do not provide protection against replay attacks in web services communications as a signed message can still be recorded and resent. The WS-Security specification recommends a number of options to protect against replay attacks; from those options, the OpenSSO web services framework has implemented the use of the time stamp. That said, here is some preliminary information about preventing replay attacks using OpenSSO.

More to come. Below is subject to tweak. But you got it first.
The OpenSSO web services security framework is driven primarily by security agents that install on deployed web containers remote to OpenSSO. The security agent accesses the web services security framework using the SOAPRequestHandler interface in the Client SDK to validate SOAP messages and authenticate against OpenSSO. As part of the process, digital signatures and encryptions are validated and, following that, the message's time stamp is processed to check for replay attacks. The time stamp can be processed using either of the following options.
  • MessageID
    The WS-Addressing MessageID header can be optionally included in a SOAP message. The value of the MessageID from a first request is cached. The messageIDMap cache uses the MessageID value to index the local time stamp (stamped when the message is received). Any message requests that use the same MessageID and are found to be within a configured time interval will be treated as a duplicate and will be rejected. (If a MessageID is not found in the incoming SOAP request, the authenticated subject identifier is used to index the time stamp.)

  • nonce
    If implementing the Username Token profile for web services security, you can cache the cryptographically random value of the nonce element from each initial request. The messageIDMap cache uses the nonce value to index the creation time stamp (time at which the token was generated). Any message requests that use the same nonce and are found to be within a configured time interval will be treated as a duplicate and will be rejected.

The Client SDK can not use the high availability and failover features of OpenSSO. Thus, the solution is to provide an interface to use for persistent storage of the state of the cache on the web services provider side. The com.sun.identity.wss.security.handler.WSSCacheRepository interface assumes a repository has already been configured and the cache can be persistently stored in it. There is no out of the box implementation for this interface but the name of the implementation class, if developed, needs to be entered as the value of the com.sun.identity.wss.security.cacherepository.plugin attribute in the AMClient.properties file. To enable the replay attack prevention feature, you create a web services provider agent profile under the appropriate realm. Once the profile has been created, follow this procedure.
  1. Click the name of the realm in which the agent profile was created.
  2. Click the Agents tab.
  3. Click the Web Service Provider tab.
  4. Click the name of the appropriate web service provider profile.
  5. Enable Detect Message Replay if applicable.
    This enables the MessageID option.
  6. Enable Detect User Token Replay if applicable.
    This enables the nonce option.
  7. Save the configuration.
You also need to add the web service client instance of OpenSSO and the Security Token Service instance of OpenSSO as a value in the Trusted Server listing. The cache is cleaned up using a periodic cleanup thread with a configurable time interval.

And now ABBA, a group that knows something about being Under Attack.

Posted at 12:00AM Jul 08, 2009 by Michael Teger in Sun  |  Comments[0]

Thursday Jul 02, 2009

Celebrating Canada and the United States

When my manager mentioned that he was also celebrating Canada Day this weekend I thought, how interesting that both of these days are together on the calendar. Did Canada try to emulate the United States when deciding to make their day in the first week of July? Not that I have any idea what Canada Day is. So I decided to investigate to see if the fact that these two days occupy the same week in the calendar is interesting at all. I know that July 4th is the day a declaration of independence from the British government was signed in the United States. According to Wikipedia, July 1 is popularly referred to as Canada's Birthday.

The occasion marks the joining of the British North American colonies of Nova Scotia, New Brunswick, and the Province of Canada into a federation of four provinces (the Province of Canada being divided, in the process, into Ontario and Quebec) on 1 July 1867. Although Canada is regarded as having become a kingdom in its own right on that date, the British Parliament kept limited rights of political control over the new country that were shed by stages over the years until the last vestiges were surrendered in 1982 when the Constitution Act patriated the Canadian constitution.
So July 1 is a declaration of federation with a declaration of independence chaser and a 100 year mortgage. Now what I find interesting is the long arm of the British Parliament.

To all who celebrate this weekend, enjoy your hot dogs (vegetarian in this household), cherry pie, nanaimo bars, and Henry Gibson (yes, that one) performing 200 Years from the Nashville soundtrack.

Posted at 11:16AM Jul 02, 2009 by Michael Teger in Personal  |  Comments[0]

Wednesday Jul 01, 2009

Synchronizing OpenSSO SAMLv2 Sessions Doesn't Make Me Anxious Anymore

After a successful SAMLv2 single sign-on, sessions are created on both the identity provider side and the service provider side. The sessions are independent from each other with their own maximum session time out and idle time out values so if one session times out or is destroyed locally, the other will not be notified. This results in an inconsistent session state between the two providers. For the upcoming Express Build 8 release, OpenSSO has added a new configuration property to support session synchronization between the two providers. The service provider will notify the identity provider when a session is refreshed (by access) or at a fixed interval.

The Session Synchronization attribute (available only in builds later than OpenSSO Enterprise 8.0) is displayed only after creating a SAMLv2 hosted identity or service provider configuration first. See Part II Federation, Web Services, and SAML Administration in the OpenSSO Enterprise 8.0 Administration Guide. Following that, under the Federation tab, click the name of the appropriate provider to display its attributes. Under the Advanced tab is the Session Synchronization attribute which can be enabled for a hosted SAMLv2 provider. If session synchronization is enabled for the hosted identity provider and a session times out (due to hitting a maximum idle time out value or maximum session time value), the identity provider will send a SOAP logout request to all affected service providers. If session synchronization is enabled for the hosted service provider, it will send a SOAP logout request to all affected identity providers.

A few weeks back, I posted an article on one time password authentication with a musical clip of The Beautiful South. The Beautiful South was one fork that grew after the breakup of The Housemartins. (The other was Fatboy Slim.) In that vein, here is an excellent live clip of The Housemartins performing Anxious from their debut LP.

I miss The Housemartins.

Posted at 10:51AM Jul 01, 2009 by Michael Teger in Sun  |  Comments[4]