Monday Dec 21, 2009

A URL List for the Relay State You're In

When an identity provider and a service provider are communicating using SAMLv2 (a redirect or an assertion exchange, for example), the RelayState parameter is used to store the URL to which the user will be redirected after the action (single sign-on, single log out or termination, for example) is complete. (If a RelayState value is not specified, the value of the defaultRelayState property in the extended metadata configuration of the entity provider is used. See Constructing SAML Messages in the Sun OpenSSO 8.0 Developer's Guide for more information.)

To avoid the RelayState parameter's being used to redirect the user to an invalid site, the Relay State URL List has been added as an Advanced property in the Standard Administration Console to the hosted identity provider, the hosted service provider and the Fedlet metadata. The value of this property is essentially a white list of URLs. If the property contains no URLs, no further check is done and the user is redirected to the URL value of the RelayState parameter as per usual. If URLs are specified, both the hosted identity provider and hosted service provider (or Fedlet, if applicable) will check the value of the RelayState parameter in the communication against the URLs and, if there is a match, redirection to the value of the RelayState parameter is allowed. If there is no match, the user is shown a browser error indicating Invalid Relay State URL specified.

To add to the Relay State URL List, log in to the OpenSSO Standard Administration Console as administrator.

  1. Click the Federation tab.
  2. Click the name of the appropriate hosted entity provider from the Entity Providers table.
  3. Click the Advanced tab.
  4. Click Relay State URL List (or scroll to the page's bottom).
  5. Add one or more URLs based on the following supported patterns.
    • \*
    • http://host:port/\*
    • http://\*:\*/\* - (if no port number is specified, defaults to 80 as the protocol is http)
    • https://\*:\*/\* - (if no port number is specified, defaults to 443 as the protocol is https)
    • http://\*:\*/\*?\* - (if query string is present)
    • http://host:port/-\*-/test - (one level wild card support)
  6. Click Save.

Now enjoy this video from (very early) Bananarama - State I'm In. They look like they're in a Dexy's Midnight Runners state.

Or if you prefer the Squeaky Mix - half the time, double the BPM and quadruple the laughs.

Wednesday Nov 11, 2009

A Wonderful Use of Fedlet with Access Manager 7.1

Vimal P., Sun quality assurance engineer extraordinaire, has joined the blogosphere with his first post (well, second if you count the Hello, World test). Here's Vimal's one line description:

This blog describes how to setup the Single Sign On between Access Manager 7.1+ SAMLv2plugin acting as IDP and OpenSSO fedlet as SP.

So, jump from my part of the blogosphere world to Vimal's entry called How to Use Fedlet with Access Manager 7.1+ to learn how it's done. But first luxuriate in the sanguine tones of Louis Armstrong performing What A Wonderful World.

Monday Nov 02, 2009

Switch On Switch Off OpenSSO SAMLv2 Services

Currently, the SAMLv2 Service servlets are always listening. For example, if you don't want to use the Artifact Resolution Service or the Manage Name ID Service it is still on. To switch the services off, you can remove the endpoints from the entity provider's configuration.
  1. Log into the OpenSSO console as administrator.
  2. Click the Federation tab.
  3. Click the name of the entity provider for which you want switch off a particular SAMLv2 Service.
  4. Click the Services tab.
  5. Remove the appropriate endpoint.
  6. Click Save.
You can also use the ssoadm command line interface.
  1. Use ssoadm export-entity to export the extended metadata.
  2. Modify the exported extended metadata.
  3. Use ssoadm delete-entity to delete the original extended metadata.
  4. Use ssoadm import-entity to import the modified extended metadata.
Disabled services return an HTTP error code.

Interestingly enough, after I titled this entry using the B-Movie single Switch On Switch Off, I was unable to find a video for that song anywhere. (It was a failed single but really this IS the internet.) In absentia, here is B-Movie's biggest hit (of which there are plenty of videos) Nowhere Girl.

3743

Monday Aug 31, 2009

Addicted to Session Attributes in a SAMLv2 Assertion

So you want to copy session attributes and set them to a SAMLv2 assertion? Simply modify the attribute mapping for the identity provider or the remote service provider (you can do it using the OpenSSO console). The default OpenSSO SAMLv2 attribute mapper will find the appropriate attributes in the session and set them in the SAMLv2 assertion.

Now how about Puretone (aka Josh Abrahams featuring Amiel Daemion) and Addicted to Bass?

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.

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.

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.

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today