« Previous month (Apr 2009) | Main | Next month (Jun 2009) »
Friday May 08, 2009

An ASP.NET OpenSSO Fedlet? Sign of the Times

In light of the OpenSSO Fedlet's recent award for innovation, here are instructions to configure and test the new ASP.NET Fedlet.

The Fedlet is a small archive that can be embedded into a service provider's web application to allow for SAMLv2 single sign-on between an identity provider instance of OpenSSO and the service provider application - WITHOUT installing OpenSSO on the service provider side. With the upcoming release of OpenSSO Enterprise 8.0 Update 1, the Fedlet technology has been extended to the ASP.NET platform. The code is currently available in the nightly builds.

OpenSSO Enterprise 8.0 Update 1 includes the Fedlet.dll, template metadata files, and a sample ASP.NET application for testing the communications. The Fedlet.dll initiates single sign-on with an identity provider and enables the receipt of an authentication response by the service provider using an HTTP-POST binding.

To configure the Sample Application for communications with the ASP.NET Fedlet, follow these first three procedures. The final procedure has the ASP.NET code to use in an existing application.

To Configure the Identity Provider

  1. Create the hosted identity provider using the Common Tasks work flow in the OpenSSO Enterprise console.

    You will need the name of the circle of trust in To Configure the Service Provider and the ASP.NET Fedlet.

  2. Export the identity provider's standard metadata file.

    idp.xml can be exported by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp

  3. Register the remote service provider using the modified standard metadata file sp.xml and the Register Remote Service Provider work flow in the OpenSSO Enterprise console.

    This standard metadata is modified in To Configure the Service Provider and the ASP.NET Fedlet thus, registering the service provider on the identity provider machine is the last step of that procedure.

To Configure the Service Provider and the ASP.NET Fedlet

  1. Download the OpenSSO Enterprise ZIP archive to the service provider machine and unzip it.

  2. Unzip the Fedlet-unconfigured.zip in the /opensso/fedlet/ folder.

  3. Move the /opensso/fedlet/asp.net/ folder to a temporary directory.

  4. Change to the /tmp/asp.net/conf directory.

  5. Make copies of the template files.

    • Copy sp.xml-template to sp.xml.
    • Copy sp-extended.xml-template to sp-extended.xml.
    • Copy idp-extended.xml-template to idp-extended.xml.
    • Copy fedlet.cot-template to fedlet.cot.

  6. Swap out the following tags in the copied metadata files.

    • Replace FEDLET_COT with the name of the circle of trust of which the remote identity provider and the local service provider are members.
    • Replace FEDLET_ENTITY_ID with a unique identifier used to locate the Fedlet. This value is analogous to the service provider EntityID. The EntityID attribute is under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of a configured entity provider when looking in the OpenSSO console is the value of the EntityID.
    • Replace FEDLET_URL with the URL of the Fedlet; for example, http://sp-machine.domain/SampleApp/fedletapplication.aspx.
    • Replace IDP_ENTITY_ID with the entity ID of the remote identity provider. The EntityID attribute is under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of a configured entity provider in the OpenSSO console is the value of the EntityID.

  7. Return to the identity provider machine to register the service provider using the modified sp.xml file and making sure to associate the service provider and the identity provider with the same circle of trust.

To Configure the Sample Application and Test the ASP.NET Fedlet

The Sample Application should be deployed using ASP.NET version 3.5 and Microsoft Internet Information Server versions 6 or 7.

  1. Navigate to the /tmp/asp.net/conf folder on the service provider machine.

  2. Copy the modified metadata files idp-extended.xml, sp.xml, sp-extended.xml, and fedlet.cot) to /tmp/asp.net/SampleApp/App_Data/.

  3. Copy the remote identity provider's standard metadata file to the service provider machine.

    Be sure the file is named idp.xml.

  4. Place idp.xml in /tmp/asp.net/SampleApp/App_Data/.

  5. Confirm that the Fedlet.dll is in the Sample Application's /tmp/asp.net/SampleApp/bin/ folder.

  6. Within Internet Information Server (IIS), create a virtual directory using the /tmp/asp.net/SampleApp/ directory.

    • IIS 6 (Windows 2003) has Add Virtual Directory. Be sure to have Read and Script permissions set for the application.

    • IIS 7 (Windows 2008 and Vista) has Add Application with no additional options required to be set.

  7. Open the Sample Application in your browser using the URL, http://sp-machine.domain/SampleApp

  8. Click the IDP Initiated SSO link to perform identity provider-initiated single sign-on.

  9. Enter the appropriate user credentials.

    The OpenSSO user demo with a password of changeit will work. After a successful authentication, the fedletapplication.aspx page is displayed with access to the AuthnResponse information.

To Integrate the ASP.NET Fedlet with an Existing Application

The Sample Application demonstrates how to retrieve attributes and subject information from the SAMLv2 assertion in an AuthnResponse object. The following code can be integrated in custom applications to do the same. It is expected to be placed in an aspx page or ASP.NET URI to receive the authentication response in an HTTP-POST binding. 

       AuthnResponse authnResponse = null; 
       try 
       { 
           ServiceProviderUtility spu = new ServiceProviderUtility(Context); 
           authnResponse = spu.GetAuthnResponse(Request); 
       } 
       catch (Saml2Exception se) 
       { 
           // invalid AuthnResponse received 
       } 
       catch (ServiceProviderUtilityException spue) 
       { 
           // issues with deployment (reading metadata) 
       }

More information on the Fedlet is in The Fedlet Cyrkle of Information.

And now for another Sign of the Times with the Belle Stars.

Posted at 09:59AM May 08, 2009 by Michael Teger in Sun  |  Comments[0]

Wednesday May 06, 2009

WIKI COMMUNITY REVIEW: Managing OpenSSO Authentication

Feel free to click on over to the OpenSSO Resource Center wiki and review the articles listed on the Managing Authentication page. This is the first chapter to be ported from the Administration Guide on docs.sun.com. The material has been rewritten to include more information and to remove information that is no longer relevant.

Leave your comments here or as comments on the Resource Center page.

But if you're not on the wiki you should be...um...with the great Kirsty MacColl. Here's her video, He's On The Beach. Pop perfection!

Posted at 06:02AM May 06, 2009 by Michael Teger in Sun  |  Comments[0]

Friday May 01, 2009

Romanticizing the OpenSSO WSSAuth Authentication Module

The WS-Security specifies the Username Token Profile for providing basic authentication information. The profile describes how the UsernameToken element can be used as a means for communicating a user identifier and password between a web service provider (WSP) and web service client (WSC). The OpenSSO WSSAuth authentication module validates the credentials presented by the WSC using the UsernameToken profile.

The UsernameToken profile contains an element to present a hash of the user's password - the PasswordDigest element. Using this element adds security as the password is not exposed as clear text. The following steps show how to configure for authentication using the Username Token profile with a one way hash password.
  1. Login into the OpenSSO console as administrator.

  2. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Client -> wsc

  3. Select UserName Token as the value of Security Mechanism.
    This uses the PasswordDigest option.

  4. Enable User Authentication Required to generate a user token.

  5. Change the Name and Password values for the Credential for User Token.
    This attribute contains the shared secrets used by the WSC to generate a user token. The password should be the same as the hashed password stored in the OpenSSO configuration data store. Use ldapsearch if the data store is Directory Server. NOTE: This step is for demonstration purposes only. In real deployments, the WSC and WSP would have a common agreement about their password storage policy.

  6. Navigate to Access Control -> / (Top Level Realm) -> Authentication.

  7. Create a new authentication chain named wssauthchain.
    See Configuring an Authentication Process Using the OpenSSO Enterprise Console.

  8. Click wssauthchain in the list of authentication chains.

  9. Add WSSAuth as the required Authentication Mechanism and click Save.

  10. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Provider -> wsp

  11. Select UserName Token as the value of Security Mechanism and wssauthchain as the authentication chain.

  12. Click Save.

To test the configurations, use the stock quote sample included with the Web Services Security Agent. After attempting to access the sample's main page, the user is redirected to OpenSSO for authentication. After successfully authenticating, the user is redirected back to the main page. When the user clicks the Get Quote button, stock quote values are displayed and the authentication mechanism used is displayed; in this case, Username Token with digest option. Changing the security mechanism would result in the new security mechanism being displayed. When logging is enabled, the OpenSSO logs would also have the appropriate tokens.

More romanticizing with Combo Audio performing the indy version of their tune, Romanticide for this video cover. I thought it was the real deal because the 7" single I owned back then had no band picture. Still a great tune.

Unlike the version they rerecorded after signing with a major label. This cleaner version is okay but not the bomb that was dropped when they released the original. But at least there's a video!

Posted at 08:25AM May 01, 2009 by Michael Teger in Sun  |  Comments[0]