Monday Aug 10, 2009

Store & Retrieve Authentication Info with OpenSSO, She & Him

Here are some words on storing authentication information in an OpenSSO session and retrieving it. It assumes that the authentication module extends AMLoginModule and the information is to be shared with a post authentication plug-in.

If the size of the information is small, you can store it in the SSOToken. If the information is security sensitive and not to be readable by the Client SDK, you could encrypt it before setting it in the SSOToken. (Prefixing the property name with am.protected. defines it as NOT readable by the Client SDK.)

After you put the required information from the authentication module into the module principal class, implement the com.sun.identity.authentication.service.AuthenticationPrincipalDataRetriever interface. It has the following method to get the module principal from authSubject, retrieve the required data, and return that data as a Map (key/value pairs).
    /\*\*
     \* Returns the attribute map from the required Authentication module
     \* Principal, to be set in the SSOToken.    
     \*
     \* @param authSubject Authenticated user Subject.
     \* @return the Attribute Map.
     \*/
    Map getAttrMapForAuthenticationModule(Subject authSubject);
The Authentication Service will store this Map in the authenticated SSOToken. A post authentication plug-in can retrieve this data from the SSOToken later. You will need to set your implementation class as a value of the com.sun.identity.authentication.principalDataRetriever property in the OpenSSO configuration data store.

Now here is Zooey Deschanel and M. Ward, plugged in as She & Him. Why Do You Let Me Stay Here? is from their album, Volume 1. I love M (especially his album Transistor Radio), love Zooey (especially as an actress in the ScyFy take on Oz called Tin Man) and also Zooey's sis, Emily (especially as the femme lead on Bones). The video is quirky and endearing and bloody.

Friday Jan 09, 2009

SAMLv2 Assertion Failover in OpenSSO

SAMLv2 Assertion Failover, when enabled, redirects a request for an assertion to a second identity provider if the identity provider that initially created the assertion is out of commission. The feature piggybacks on OpenSSO Session Failover configuration by using the same databases. Here is the procedure to configure and test SAMLv2 Assertion Failover.
  1. Deploy 2 instances of OpenSSO Enterprise to act as identity providers and 1 load balancer in front of them.
  2. Set up the entities as a site with servers (using the OpenSSO console) and confirm that the configurations work.
  3. Install and setup session failover as documented in the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
  4. Deploy 1 instance of OpenSSO Enterprise to act as service provider.
  5. On all three provider instances of OpenSSO, enable SAMLv2 Assertion Failover.
    1. Log in to the OpenSSO console as administrator.
    2. Click the Configuration tab.
    3. Click the Global tab.
    4. Click the SAMLv2 Service Configuration link.
    5. Check the box next to Enable SAMLv2 Failover.
    6. Click Save.
    7. Log out of the console.
  6. Configure each server instance of OpenSSO as the appropriate entity provider and member of the same SAMLv2 circle of trust.
  7. Export the entity provider metadata from all three server instances of OpenSSO.
  8. Load the service provider and identity provider metadata on the respective instances of OpenSSO and on the load balancer.

    You need to create the metadata for the load balancer. See your load balancer's documentation for more information. Make sure you change the URL values in the load balancer metadata from the OpenSSO instances behind the load balancer to the load balancer URL itself.
  9. Modify the spAssertionConsumer.jsp on the service provider machine to add sleep that allows enough time to shutdown the identity provider on which the request will land. (See step 11.)

    Object newSession = null;
    SAML2Utils.debug.error("Before sleep Assertion Failover");
    SAML2Utils.debug.message("Before sleep Asserion Failover");
    Thread.sleep(50000);
    SAML2Utils.debug.error("After sleep Assertion Failover");
    SAML2Utils.debug.message("After sleep Asserion Failover");
  10. Initiate single sign-on using the following URL: http://host-machine.domain:port/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain

    Before proceeding to the next step, run tail on the SAMLv2 debug logs (located in OpenSSO-install-directory/opensso/debug) on the identity provider host machines to see where the single sign-on request lands.
  11. After providing the service provider user credentials, monitor the log and shutdown the identity provider on which the initial single sign-on request landed.

    Make sure the user is not federated before shutting down the identity provider. The sleep time added to spAssertionConsumer.jsp in the previous step should allow enough time for this. (See step 9.)
  12. Verify that federation successfully occurs after the identity provider is shutdown. This confirms that assertion failover was successful.
  13. Initiate single logout using the following URL:

    http://host-machine.domain:port/opensso/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain
  14. Bring the previously shutdown identity provider back up and, once again, initiate single sign-on again using the following URL:

    http://host-machine.domain:port/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain
  15. Monitor the log and shutdown the identity provider on which this second single sign-on request landed.
  16. Initiate single logout using the following URL:

    http://host-machine.domain:port/opensso/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain
  17. A successful logout confirms assertion failover is working.

And now that Assertion Failover has been correctly configured, put your footsies up and check out this live version of The Killers' latest hit - are we Human or are we dancer?

Friday Jul 18, 2008

Touching Legacy Mode in OpenSSO

Legacy mode in previous versions of the code that was open-sourced as OpenSSO is based on the Sun Java System Access Manager 6.3 architecture. There is no longer a legacy mode installation option in OpenSSO. Legacy mode is supported through upgrade only; if you have Sun Java System Access Manager 7.0 or 7.1 installed in legacy mode, you can upgrade to OpenSSO and keep it in legacy mode. Also, if you have Sun DS with AM schema installed, you can use the legacy mode features with the AMSDK data repository plugin.
There is no timeline set for removing legacy mode but it is strongly recommended not to use this option.

So don't touch legacy mode anymore - instead take a listen to Kim Wilde's 1984 UK hit, The Touch. Loved this song (and album) back then and I also love the pretty girls at the beginning of the video which never made it to this side of the pond until now.

Thursday Jul 17, 2008

Enabling PUT and DELETE Actions in OpenSSO Policy Definitions for Web URLs

Policy rules in OpenSSO allow control over GET and POST actions but, by default, do not list PUT and DELETE. Following are two procedures for adding the latter actions. When Deploying a New Instance of OpenSSO
  1. Explode opensso.war.
  2. cd WEB-INF/classes
  3. Create AttributeSchema elements for PUT and DELETE in amWebAgent.xml using the already existing AttributeSchema for GET and POST as the prototype.
  4. Add i18n keys and values to amWebAgent.properties for the elements created in the previous step.
  5. Regenerate the WAR.
  6. Deploy the WAR.

When Modifying an Existing Instance of OpenSSO
  1. Explode opensso.war.
  2. cd WEB-INF/classes
  3. Create AttributeSchema elements for PUT and DELETE in amWebAgent.xml using the already existing AttributeSchema for GET and POST as the prototype.
  4. Copy amWebAgent.xml outside the exploded WAR directory.
  5. Add i18n keys and values to amWebAgent.properties for the elements created in the previous step.
  6. Regenerate the WAR.
  7. Redeploy the WAR.
  8. Set up the famadm command line interface.

    • Download and unzip opensso.zip.
    • Change to the opensso/tools directory and unzip famAdminTools.zip.
    • Follow the instructions in README.setup.

  9. Run the following command:

    famadm delete-svc -s iplanetamwebagentservice
  10. Run the following command:

    famadm create-svc --xmlfile /path/amWebAgent.xml
And now enjoy Eddie Money and Ronnie Spector singing Take Me Home Tonight.

Wednesday Jul 16, 2008

Using Sub-Realms in OpenSSO Again & Again

In general, you should use the default root realm (opensso) to configure identity data stores, and manage policies and authentication chains. After deployment, OpenSSO creates a Realm Administrator who can perform all operations in the configured root realm, and a Policy Administrator who can only create and manage policies. The use of sub-realms in OpenSSO should be restricted to the following two scenarios.
  1. Application Policy Delegation The use case for this is when you need to have different Policy Administrators to create policies for a sub-set of resources. For example, let's assume a sub-realm is created and named Paycheck. This sub-realm is configured with a policy referral from the root realm for configuring protection of resources starting with https://paycheck.sun.com/paycheck. Within the Paycheck sub-realm, a Paycheck Administrator role or group is created and assigned Policy Administration privileges. These administrators are now able to login to the sub-realm and create policies for their applications. By default, the sub-realm inherits the same configuration data store and authentication chains configured for its parent; if these configurations change in the parent, a corresponding change would be needed in the sub-realm. Additionally, all users will still log in to the root realm for access to all the applications. The sub-realm is primarily for the Policy Administrator to manage policies for the application. An educated guess on the number of sub-realms that can be supported would be about 100.
  2. ISP/ASP/Silo The use case for this scenario is when each sub-realm is to have its own set of identity data stores, authentication chains, and policies. Ideally the only common thread between the root and the sub-realm would be the referral policy created in the root realm to delegate a set of resources to the sub-realm. Users would not be able to log in to the root realm (unless they are a member) but would have to authenticate to their sub-realm. Also, agents would have to be configured to redirect user authentication to the particular sub-realm. With regards to performance, the most resource consuming component would be when persistent searches created by the data stores connect to the same directory. An educated guess on the number of sub-realms that can be supported would be about 50.
So now you know how to use sub-realms again & again as confirmed by The Bird and the Bee in their song titled (what else) Again & Again.

Friday Jul 11, 2008

Absolutely Fabulous OpenSSO Notification Properties

Currently, OpenSSO uses the following absolutely fabulous properties to define notification URLs.
  • com.sun.identity.client.notification.url
  • defines the URL on the client side that will receive notifications from the Policy Service, the Session Service, and User Management features of OpenSSO. The value is the URL of the agent; for example, http://my.test.domain.com:6948/agentapp. The com.sun.identity.agents.notification.url property must also be set to true.
  • com.sun.identity.agents.notification.url is a server side property that allows you to enable (true) or disable (false) notifications to the agent caches.
  • com.sun.identity.idm.remote.notification.enabled allows you to enable (true) or disable (false) notifications to the am.sdk and IdRepo caches.
  • com.sun.identity.sm.notification.enabled allows you to enable (true) or disable (false) notifications to the service management caches.
NOTE: If com.sun.identity.idm.remote.notification.enabled and com.sun.identity.sm.notification.enabled are not set in the client side AMConfig.properties, their value defaults to true. If they are set to true but no URL is specified as a value for com.iplanet.am.notification.url, notifications will not be received. Finally, if the notification URL is defined but one of these properties is set to false, the cache update defaults to polling.

And here's my notification to you of the absolutely fabulous video for the Pet Shop Boys song Absolutely Fabulous featuring Jennifer Saunders and Joanna Lumley. Ahhhh, those were the days, my friend.

Tuesday Jul 08, 2008

Ma Quale Idea: Review the FAM8 Technical Overview

Ma Quale Idea! Here is a PDF of the first two parts of the Federated Access Manager 8.0 Technical Overview. The two parts are now open for review. Let me know if you have any issues, comments, or errors with the current information.

And here's another idea, Ma Quale Idea, Pino D'Angio's disco hit from 1980.

Friday Jul 04, 2008

2 for the 4th: SuperPat and Dolly Parton

Where else you gonna see those names together?
  • For those who weren't able to attend SuperPat's OpenSSO presentation at JavaOne, here is Marina Sum's summary of it all. Good stuff.
  • Celebrate the Fourth with no fireworks and a cut from Dolly's patriotic long player For God and Country called Welcome Home. Stuff good.

Thursday Jul 03, 2008

Affiliation-based Federation with...ABBA?

An affiliation (referenced by an affiliationID) is a grouping of entity providers configured using OpenSSO and maintained by an affiliation owner who chooses the members without regard to the boundaries of any circles of trust which might also include the entity providers as members. Affiliation-based federation is indicated by a boolean flag at the service provider and uses the affiliationID defined for the remote provider (since a local provider can participate in more than one affiliation). If enabled, the authentication request will be sent with the affiliation flag set to true.

Affiliation data is part of the provider metadata. A service provider request denotes whether the request is being made as part of an affiliation or not. If services are invoked as an affiliation member, a service provider might issue an authentication request for a user on behalf of the affiliation. When authentication is secured, the user can achieve single sign-on with all members of the affiliation.

And for those who don't know - I have an affiliation with ABBA. In honor of the upcoming release of Mamma Mia here's the group's music video for the title tune (mysteriously aped in Muriel's Wedding for Muriel and Rhonda's karaoke performance of...Waterloo?).

And here's the trailer for the film. Meryl Streep (sounding great), Julie Walters and an uncredited (?) Christine Baranski - what a trio!!

Wednesday Jul 02, 2008

Federated Access Manager Supported Data Stores and Operations

THIS INFORMATION IS STILL BEING UPDATED AND MAY CHANGE BEFORE THE FALL 2008 FEDERATED ACCESS MANAGER 8.0 RELEASE.

Federated Access Manager contains a lot of data and supports a number of products in which to store it. The following sections contain information regarding this support and the specific operations that can be performed on the data by each product.
  1. Directory Support
  2. Supported Identity Data Store Operations
  3. Notification Support

Directory Support

The table below lists the directories supported for the different types of data.


Sun Directory Server

Active Directory

IBM Tivoli Directory

LDAP v3 server (other)

User Data Store

Yes

Yes

Yes

No

Configuration Data Store\*

Yes

No

No

No

AM SDK (legacy)

Yes

No

No

No

LDAP Authentication

Yes

Yes

Yes

Yes

Membership Authentication

Yes

No

No

No

AD Authentication

N/A

Yes\*\*

N/A

N/A

Policy Subjects and Policy LDAPFilter Condition

Yes

Yes

Yes

Yes

Password Reset

Yes (with AM SDK only)

No

No

No

Account Lockout

Yes

No

No

No

Certificate Authentication

Yes

Yes`

Yes

Yes

MSISDN Authentication

Yes

Yes

Yes

Yes

Data Store Authentication (through LDAPv3 identity data store)

Yes

Yes

Yes

Yes

\* OpenDS can be configured as the embedded configuration data store during your initial Federated Access Manager configuration. It can not be configured as an external configuration data store as the Sun Directory Server can. OpenDS is not currently supported as a user data store.

\*\* There are some limitations.

As a side note, authentication also supports the JDBC repository through the JDBC authentication module.

Supported Identity Data Store Operations

IDRepo is the interface to provide basic management for user, group, role and agent entities. This interface allows support for any identity data repository with the development of a plug-in. Although currently limited to three directories, it can be expanded to include any LDAPv3 directory (like OpenLDAP or Novell Directory), a Java Database Connectivity (JDBC) directory, flat files, and others.

The matrix below specifies current support through the IDRepo interface. We have a specific implementation for each supported identity repository. The default implementation of this interface can be used and is supported for any LDAPv3 repository.

The following table lists operations supported by each data store type.


Sun DS

LDAP v3

IBM Tivoli

LDAP v3

AD

LDAP v3

LDAP v3

(generic)

AM SDK

(legacy)

User Create

Yes

Yes

Yes\*

No

Yes

User Modify

Yes

Yes

Yes\*

No

Yes

User Delete

Yes

Yes

Yes\*

No

Yes

Role create

Yes

Yes

No

No

Yes

Role Modify

Yes

Yes

No

No

Yes

Role Delete

Yes

Yes

No

No

Yes

Role Assignment

Yes

Yes

No

No

Yes

Role Evaluation for membership

Yes

Yes

No

No

Yes

Group Create

Yes

Yes

No

No

Yes

Group Modify

Yes

Yes

No

No

Yes

Group Delete

Yes

Yes

No

No

Yes

Group Assignment

Yes

Yes

No

No

Yes

Group evaluation for membership

Yes

Yes

Yes

No

Yes

Federation Attributes

Yes

Yes

Yes

No

Yes

\* Needs some fixes.

Notification Support

Data changes in directories need to be propagated to OpenSSO in a timely manner. The data in OpenSSO is updated in two ways:

  1. Polling of the directories
  2. Notifications from the directories

For notification, Federated Access Manager subscribes to persistent search notifications provided by the directories. For polling, it provides configurable parameters to specify the time intervals. When multiple instances of Federated Access Manager are running, the configuration data changes can also be propagated to those instances.

And now watch how the dancers support Goldie Hawn as she sings Star, the title tune from the 1960s film musical biography about Gertrude Lawrence and starring an excellently-cast Julie Andrews.

Thursday Jun 26, 2008

Move Any Mountain to Attend the SSO Summit

It's in the mountains of Colorado and, according to the web site, the SSO Summit is the only conference to arm you with case-studies, war stories, success stories and shared expertise. Click here for more information. But come back to dance with The Shamen as they Move Any Mountain.

Get it? Summit. Mountain.

I'm going, btw.

Wednesday Jun 25, 2008

The Fedlet Cyrkle of Information

I've recently posted a few entries about the Fedlet. Here is a list of them and what they are about...for easy reference.
  1. Besides having the catchiest kid's television show theme this side of MisterRogers, The Fedlet and U (Part 1): Winky Dink and Me introduces the Fedlet and how to create and test one using the Common Task wizard.
  2. The Fedlet and U (Part 2): Pre-Built to Last shows you the procedure I used to create a Fedlet using the pre-built but unconfigured Fedlet bundle.
  3. The Fedlet and U (Part 3): We Built This Application is the procedure I used to integrate the Fedlet by modifying application code in three ways. Unfortunately, I couldn't get them to work. (And I am exhausted from trying.) So I am putting this information out there to see if it works for someone else. Remember I'm not a developer - I only play one on TV (even if I was only using hello.jsp).
  4. Undeploying the Fedlet with Some Light from Jens Lekman is a bonus entry with the titular procedure and Swedish music from the titular pop singer. (Thankfully there was nothing else in the title so I didn't have to use that word again.)
So I'll sign off with the great new look and sound of the Cyrkle - as introduced by Paul Anka?

Tuesday Jun 24, 2008

The Fedlet and U (Part 3): We Built This Application

NOTE : I've been getting errors with the following procedures. I am posting them anyway in hopes that someone can see what I have missed. I'm not an engineer and therefore am thinking my code deletion and additions are incorrect. If you are able to successfully deploy and test the following Fedlet procedures, let me know what you did so I can try it out. Thanks.

Thus far, in previous entries, I explained how to implement the Fedlet using the Common Tasks work flow in the OpenSSO console and using the pre-built but unconfigured fedlet.war. (There's also a bonus entry on how to remove a deployed fedlet.)

In this entry, you'll find the procedures to integrate the fedlet.war code with an existing service provider application. The following diagram illustrates the three ways in which this can be done.

  1. fedletSampleApp.jsp is modified to add the service provider's application logic and, thus, is used as the endpoint for the Fedlet on the service provider side here.
  2. fedletSampleApp.jsp is modified to forward the request to the service provider application URL and, thus, is also used as the endpoint for the Fedlet on the service provider side here.
  3. fedletSampleApp.jsp is replaced by a new JSP (servlet) to create a new endpoint or the Fedlet code in the fedletSampleApp.jsp is copied to the new endpoint code here.

NOTE: The diagram refers to fedletSampleApp.jsp, a sample JSP packaged with the fedlet.war thatprovides a default Assertion Consumer endpoint to process SAMLv2 Assertions from the identity provider. fedletSampleApp.jsp first invokes a util method to complete SAMLv2 protocol processing. A map containing various pieces of data (including a Response, an Assertion, and Attributes) is then returned to the caller for further processing. fedletSampleApp.jsp also provides some sample code to help you to understand how to retrieve data from the returned map.


<%--
   The contents of this file are subject to the terms
   of the Common Development and Distribution License
   (the License). You may not use this file except in
   compliance with the License.

   You can obtain a copy of the License at
   https://opensso.dev.java.net/public/CDDLv1.0.html or
   opensso/legal/CDDLv1.0.txt
   See the License for the specific language governing
   permission and limitations under the License.

   When distributing Covered Code, include this CDDL
   Header Notice in each file and include the License file
   at opensso/legal/CDDLv1.0.txt.
   If applicable, add the following below the CDDL Header,
   with the fields enclosed by brackets [] replaced by
   your own identifying information:
   "Portions Copyrighted [year] [name of copyright owner]"

   $Id: fedletSampleApp.jsp,v 1.2 2008/05/29 00:40:42 veiming Exp $

   Copyright 2008 Sun Microsystems Inc. All Rights Reserved
--%>

<%@page
import="com.sun.identity.saml2.common.SAML2Exception,
com.sun.identity.saml2.common.SAML2Constants,
com.sun.identity.saml2.assertion.Assertion,
com.sun.identity.saml2.assertion.Subject,
com.sun.identity.saml2.profile.SPACSUtils,
com.sun.identity.saml2.protocol.Response,
com.sun.identity.saml2.assertion.NameID,
com.sun.identity.plugin.session.SessionException,
java.io.IOException,
java.util.Iterator,
java.util.List,
java.util.Map"
%>
<%
    String deployuri = request.getRequestURI();
    int slashLoc = deployuri.indexOf("/", 1);
    if (slashLoc != -1) {
        deployuri = deployuri.substring(0, slashLoc);
    }
%>
<html>
<head>
    <title>Fedlet Sample Application</title>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    <link rel="stylesheet" type="text/css" href="<%= deployuri %>/com_sun_web_ui/css/css_ns6up.css" />
</head>

<body>
<div class="MstDiv"><table width="100%" border="0" cellpadding="0" cellspacing="0" class="MstTblTop" title="">
<tbody><tr>
<td nowrap="nowrap"> </td>
<td nowrap="nowrap"> </td>
</tr></tbody></table>

<table width="100%" border="0" cellpadding="0" cellspacing="0" class="MstTblBot" title="">
<tbody><tr>
<td class="MstTdTtl" width="99%">
<div class="MstDivTtl"><img name="ProdName" src="<%= deployuri %>/console/images/PrimaryProductName.png" alt="" /></div></td><td class="MstTdLogo" width="1%"><img name="RMRealm.mhCommon.BrandLogo" src="<%= deployuri %>/com_sun_web_ui/images/other/javalogo.gif" alt="Java(TM) Logo" border="0" height="55" width="31" /></td></tr></tbody></table>
<table class="MstTblEnd" border="0" cellpadding="0" cellspacing="0" width="100%"><tbody><tr><td><img name="RMRealm.mhCommon.EndorserLogo" src="<%= deployuri %>/com_sun_web_ui/images/masthead/masthead-sunname.gif" alt="Sun(TM) Microsystems,
Inc." align="right" border="0" height="10" width="108" /></td></tr></tbody></table></div><div class="SkpMedGry1"><a name="SkipAnchor2089" id="SkipAnchor2089"></a></div>
<div class="SkpMedGry1"><a href="#SkipAnchor4928"><img src="<%= deployuri %>/com_sun_web_ui/images/other/dot.gif" alt="Jump Over Tab Navigation Area. Current Selection is: Access Control" border="0" height="1" width="1" /></a></div>
<%
    // BEGIN : following code is a must for Fedlet (SP) side application
    Map map;
    try {
        // invoke the Fedlet processing logic. this will do all the
        // necessary processing conforming to SAMLv2 specifications,
        // such as XML signature validation, Audience and Recipient
        // validation etc.  
        map = SPACSUtils.processResponseForFedlet(request, response);
    } catch (SAML2Exception sme) {
        response.sendError(response.SC_INTERNAL_SERVER_ERROR, sme.getMessage());
        return;
    } catch (IOException ioe) {
        response.sendError(response.SC_INTERNAL_SERVER_ERROR, ioe.getMessage());
        return;
    } catch (SessionException se) {
        response.sendError(response.SC_INTERNAL_SERVER_ERROR, se.getMessage());
        return;
    } catch (ServletException se) {
        response.sendError(response.SC_BAD_REQUEST, se.getMessage());
        return;
    }
    // END : code is a must for Fedlet (SP) side application
    
    String relayUrl = (String) map.get(SAML2Constants.RELAY_STATE);
    if ((relayUrl != null) && (relayUrl.length() != 0)) {
        // something special for validation to send redirect
        int stringPos  = relayUrl.indexOf("sendRedirectForValidationNow=true");
        if (stringPos != -1) {
            response.sendRedirect(relayUrl);
        }
    } 

    // Following are sample code to show how to retrieve information,
    // such as Reponse/Assertion/Attributes, from the returned map. 
    // You might not need them in your real application code. 
    Response samlResp = (Response) map.get(SAML2Constants.RESPONSE); 
    Assertion assertion = (Assertion) map.get(SAML2Constants.ASSERTION);
    Subject subject = (Subject) map.get(SAML2Constants.SUBJECT);
    String entityID = (String) map.get(SAML2Constants.IDPENTITYID);
    NameID nameId = assertion.getSubject().getNameID();
    String value = nameId.getValue();
    String format = nameId.getFormat();
    out.println("<br><br><b>Single Sign-On successful with IDP " 
        + entityID + ".</b>");
    out.println("<br><br>");
    out.println("<table border=0>");
    if (format != null) {
        out.println("<tr>");
        out.println("<td valign=top><b>Name ID format: </b></td>");
        out.println("<td>" + format + "</td>");
        out.println("</tr>");
    }
    if (value != null) {
        out.println("<tr>");
        out.println("<td valign=top><b>Name ID value: </b></td>");
        out.println("<td>" + value + "</td>");
        out.println("</tr>");
    }    
    Map attrs = (Map) map.get(SAML2Constants.ATTRIBUTE_MAP);
    if (attrs != null) {
        out.println("<tr>");
        out.println("<td valign=top><b>Attributes: </b></td>");
        Iterator iter = attrs.keySet().iterator();
        out.println("<td>");
        while (iter.hasNext()) {
            String attrName = (String) iter.next();
            List attrVals = (List) attrs.get(attrName);
            out.println(attrName + "="
                + attrVals.get(0) + "<br>");
        }
        out.println("</td>");
        out.println("</tr>");
    }
    out.println("</table>");
    out.println("<br><br><b><a href=# onclick=toggleDisp('resinfo')>Click to view SAML2 Response XML</a></b><br>");
    out.println("<span style='display:none;' id=resinfo><textarea rows=40 cols=100>" + samlResp.toXMLString(true, true) + "</textarea></span>");

    out.println("<br><b><a href=# onclick=toggleDisp('assr')>Click to view Assertion XML
<script>
function toggleDisp(id)
{
    var elem = document.getElementById(id);
    if (elem.style.display == 'none')
        elem.style.display = '';
    else
        elem.style.display = 'none';
}
</script>
</body>
</html>


The following procedures assume that you have downloaded the opensso.zip and extracted the contents. The /opensso directory is at the top-level of the machine to which it was downloaded.

Modify fedletSampleApp.jsp with Application Logic
  1. Unzip fedlet.war into a temporal directory; for example, /sp1.
    This directory must be accessible by the user running the web container; for example, if running your web container as root, the user's home directory is / so the sp1 directory should be located at /sp1.

    NOTE: This directory is the default location from which the Fedlet reads its metadata, circle of trust, and configuration properties. To change it, set the value of the JVM run-time property com.sun.identity.fedlet.home to the desired location; for example:

    -Dcom.sun.identity.fedlet.home=/export/fedlet/conf

    % mkdir /sp1
    % cd /sp1
    % jar xvf /opensso/fedlet/fedlet.war
    
  2. In fedletSampleApp.jsp (located at the top-level of the temporal directory) remove all text after the line, // END : code is a must for Fedlet (SP) side application.
  3. Merge the import statements between fedletSampleApp.jsp and the application code, if applicable.
    I'm using a simple hello.jsp (as below) so nothing to merge.


    
    <%--
       The contents of this file are subject to the terms
       of the Common Development and Distribution License
       (the License). You may not use this file except in
       compliance with the License.
    
       You can obtain a copy of the License at
       https://opensso.dev.java.net/public/CDDLv1.0.html or
       opensso/legal/CDDLv1.0.txt
       See the License for the specific language governing
       permission and limitations under the License.
    
       When distributing Covered Code, include this CDDL
       Header Notice in each file and include the License file
       at opensso/legal/CDDLv1.0.txt.
       If applicable, add the following below the CDDL Header,
       with the fields enclosed by brackets [] replaced by
       your own identifying information:
       "Portions Copyrighted [year] [name of copyright owner]"
    
       $Id: fedletDefault.jsp,v 1.2 2008/03/31 19:54:11 qcheng Exp $
    
       Copyright 2008 Sun Microsystems Inc. All Rights Reserved
    --%>
    <html>
    <head>
        <title>My Hello</title>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    </head>
    
    <body>
        <h1>
            Hello World
        </h1>
    </body>
    </html>
    

  4. Add your application logic underneath the line that begins with //END - prepending a %> before it and appending the closing HTML tags after it.

    
    &>
    <h1>
    Hello, World
    </h1>
    </body>
    </html>
    
  5. From inside the sp1 directory, pack up the contents using the jar command.
    jar cvf ./fedlet.war
  6. Deploy the WAR.
  7. Launch the deployed application.

Modify fedletSampleApp.jsp to Forward Request

  1. Unzip fedlet.war into a temporal directory; for example, sp2.
    % mkdir sp2
    % cd sp2
    % jar xvf /opensso/fedlet/fedlet.war
    
  2. In fedletSampleApp.jsp (located at the top-level of the temporal directory) remove all text after the line, // END : code is a must for Fedlet (SP) side application.
  3. Add redirect code underneath the line that begins with //END - prepending a %> before it and appending the closing HTML tags after it.
    
    &>
    response.sendRedirect("hello.jsp"); 
    </body>
    </html>
    
  4. Add the modified fedletSampleApp.jsp and the hello.jsp to the document root of the unpacked WAR directory structure.
  5. Pack up the WAR using the jar command.
    jar cvf ./fedlet.war
  6. Deploy the WAR.
  7. Launch the deployed application.

Replace fedletSampleApp.jsp

  1. Modify web.xml to set the servlet and servlet-mapping for your new servlet or JSP.
    You must map your new servlet/JSP to the url-pattern /fedletapplication since that is the URI set in the Fedlet metadata for the assertion consumer URL. For example:
    
                   yourapplication
                   /Your-Application.jsp
               
               
                   yourapplication
                   /fedletapplication
               
  2. Copy the following code from fedletSampleApp.jsp to your application processing code.
    Be sure to also copy any appropriate import statements.
    Map map;
    try {
        // invoke the Fedlet processing logic. this will do all the
    
    Map map;
    try {
        // invoke the Fedlet processing logic. this will do all the
        // necessary processing conforming to SAMLv2 specifications,
        // such as XML signature validation, Audience and Recipient
        // validation etc.
        map = SPACSUtils.processResponseForFedlet(request, response);
    } catch (SAML2Exception sme) {
        response.sendError(response.SC_INTERNAL_SERVER_ERROR, sme.getMessage());
        return;
    } catch (IOException ioe) {
        response.sendError(response.SC_INTERNAL_SERVER_ERROR, ioe.getMessage());
        return;
    } catch (SessionException se) {
        response.sendError(response.SC_INTERNAL_SERVER_ERROR, se.getMessage());
        return;
    } catch (ServletException se) {
        response.sendError(response.SC_BAD_REQUEST, se.getMessage());
        return;
    }
    After obtaining the returned map object, follow the sample code to retrieve the data needed for your business logics.

Considering how we built these applications, now rock out to the much-maligned but still pleasurable We Built This City, Starship's number 1 hit from the 1980s.

Sunday Jun 22, 2008

Want to Set Up and Test a SAMLv2 Authentication Query? Ask.

A SAMLv2 Authentication Query requests existing authentication assertions about a given subject from an Authentication Authority. This procedure explains how to set up and test an authentication query; I found it internally and recreated it externally for you.

This procedure assumes the entityID of the service provider is ear.red.sun.com, and the entityID of the identity provider is eye.red.sun.com. It also assumes that you have downloaded and deployed the famadm command line interface. You can also accomplish the steps referring to the export and import of metadata using the Federation and Common Tasks portions of the OpenSSO console.

  1. On the service provider machine, generate standard and extended metadata templates and load them as an entity provider using the OpenSSO console. For example,

    /famconfig/famadm/fam/bin/famadm create-metadata-templ -u amadmin -f /tmp/pw -m /tmp/spmd -x /tmp/spxmd -s /sp -a test -r test -y ear.red.sun.com
  2. Login to the OpenSSO console on the identity provider machine to import the service provider metadata files.
  3. On the identity provider machine, generate standard and extended metadata templates, specifying the -C, -D, and -E options. For example,

    /famconfig/famadm/fam/bin/famadm create-metadata-templ -u amadmin -f /tmp/pw -m /tmp/idpmd -x /tmp/idpxmd -i /idp -b test -g test -C /authna -D test2 -E test2 -y eye.red.sun.com
  4. Modify the identity provider extended metadata as follows.

    • Set the value of the idpAuthncontextClassrefMapping attribute to:
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|0||default
      urn:oasis:names:tc:SAML:2.0:ac:classes:Level1|1|module=DataStore1
      urn:oasis:names:tc:SAML:2.0:ac:classes:Level3|3|module=DataStore3
      urn:oasis:names:tc:SAML:2.0:ac:classes:Level5|5|module=DataStore5
      urn:oasis:names:tc:SAML:2.0:ac:classes:Level7|7|module=DataStore7
      urn:oasis:names:tc:SAML:2.0:ac:classes:Level9|9|module=DataStore9
    • Set the value of the assertionCacheEnabled attribute to true.
  5. Login to the OpenSSO console on the service provider machine to import the identity provider metadata files.
  6. Login to the OpenSSO console on the identity provider machine to add the following named authentication modules.

    DataStore1
    DataStore3
    DataStore5
    DataStore7
    DataStore9

    The type of each module should be set to Data Store and the authentication level set to 1, 3, 5, 7, and 9, respectively.
  7. Single sign-on using the following URL:
    http://ear.red.sun.com/fam/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=eye.red.sun.com&reqBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&AuthnContextClassRef=urn:oasis:names:tc:SAML:2.0:ac:classes:Level1
    This will create an assertion with the value of AuthnContextClassRef set as urn:oasis:names:tc:SAML:2.0:ac:classes:Level1.

    ALTERNATIVES: You can single sign-on with different authentication levels by changing Level1 to Level3, Level5, Level7, and Level9. You can also use a different browser which would change the value of sessionIndex. Following this, the user will have had multiple assertions created.
  8. To test your configuration, copy authnQuery.jsp to the service provider deploy root and customize it by changing the following attributes (located between // customization starts here and // customization ends here in the file).
    • sessionIndex
    • RequestedAuthnContext
    • Comparison
  9. Run the JSP by typing the following URL in a browser.
    http://ear.red.sun.com/fam/authnQuery.jsp?spMetaAlias=/sp&authnAuthorityEntityID=eye.red.sun.com
    The results will change based on the different customizations.
See, when you have a query, just ask - like the Smiths said.

Tuesday Jun 17, 2008

Discovering the SAMLv2 IDP Discovery Service and the Discovery LP

All web services are defined by a Web Services Description Language (WSDL) file that describes the type of data the service contains, the available ways said data can be exchanged, the operations that can be performed using the data, a protocol that can be used to perform the operations, and a URL (or endpoint) for access to the service. Additionally, the WSDL file itself is assigned a unique resource identifier (URI) that is used to locate it. The file is then published and the URI is placed in a Universal Description, Discovery and Integration (UDDI) repository so it can be found by potential users. Thus, the web service can now be discovered. Discovery of a web service is the act of locating the WSDL file for it. Typically, there are one or more web services on a network so, a discovery service is required to keep track of the WSDL locations.

The SAML v2 IDP Discovery Service is an implementation of the Identity Provider Discovery Profile as described in the Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 specification. In deployments having more than one identity provider, service providers need to determine which identity provider(s) a principal uses with the Web Browser SSO profile. To allow for this, the SAML v2 IDP Discovery Service relies on a cookie written in a domain that is common to all identity providers and service providers in a circle of trust. This predetermined domain is known as the common domain, and the cookie containing the list of identity providers to chose from is known as the common domain cookie.

The Reader and Writer URLs, used by the SAML v2 IDP Discovery Service, are defined when configuring the circle of trust. When a user requests access from a service provider, and an entity identifier for an identity provider is not received in the request, the service provider redirects the request to the common domain's SAML v2 IDP Discovery Service Reader URL to retrieve the identity provider's entity identifier. If more then one identity provider entity identifier is returned, the last entity identifier in the list is the one to which the request is redirected. Once received, the identity provider redirects to the Discovery Service Writer URL to set the common domain cookie using the value defined in the installation configuration properties file. Here is a procedure for setting up and testing the Identity Provider Discovery Service.
  1. Download opensso.zip file to a location on your server machine.
  2. Unzip opensso.zip into /opensso.
  3. Change to the deployable-war sub-directory.
  4. Follow the instructions in the README to build a specialized WAR for the identity provider discovery service.
    1. Create a new directory as the staging area for the identity provider discovery service WAR (for example, idpwar), and extract the contents of opensso.war into it.
      % mkdir idpwar
      % cd idpwar
      % jar xvf /opensso/deployable-war/opensso.war
    2. Create the identity provider discovery service WAR using the fam-idpdiscovery.list file.
      % cd idpwar
      % jar cvf /opensso/deployable-war/fam-idp.war @/opensso/deployable-war/fam-idpdiscovery.list
    3. Update fam-idp.war with the additional files in the idpdiscovery directory.
      % cd /opensso/deployable-war/idpdiscovery
      % jar uvf /opensso/deployable-war/fam-idp.war \*
    Now the identity provider discovery service WAR is ready to be deployed.
  5. Deploy fam-idp.war to your web container.
  6. Access http://idp-discovery-server-machine:port/idpdiscovery.
    The Federated Access Manager Identity Provider Discovery Service configuration page should be displayed.
  7. Provide values for the identity provider Discovery Service attributes on the configuration page.
    • Debug directory
    • Debug Level
    • Cookie Type - by default, PERSISTENT SESSION
    • Cookie Domain
    • Secure Cookie
    • Encode Cookie
  8. On the service provider host machine, use the console to create a Circle of Trust with the identity provider discovery service URL used as the prefix for the value of the Reader and Writer URL attributes; for example, the value of the SAML2 Writer Service URL would be http://idp-discovery-server-machine:port/idpdiscovery/saml2writer and the value of the SAML2 Reader Service URL would be http://idp-discovery-server-machine:port/idpdiscovery/saml2reader
  9. Now, on the identity provider host machine, use the console to create a Circle of Trust with the value of the prefix attribute also set to the identity provider discovery service URL, http://idp-discovery-server-machine:port/idpdiscovery.
  10. Generate metadata for both the identity provider and the service provider using the command line utility famadm and the create-metadata-templ option.
  11. Load the service provider metadata onto the identity provider machine.
  12. Change the value of host in the identity provider metadata from 0 or remote.
  13. Load the identity provider metadata onto the service provider machine.
    After this configuration, the values of the Writer URL and Reader URL in each circle of trust are the URL of the Identity Provider Discovery Service.
  14. Perform SAMLv2 test cases for service provider-initiated and identity provider-initiated single sign-on and single logout.
    Each time you perform these operations from the service provider side, the Discovery Service logs will show the redirection to the identity provider. Here is an example log:
    root@nude# cat libIDPDiscovery
    \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
    05/05/2008 01:41:18:782 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet Initializing...
    05/05/2008 01:41:18:786 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred Cookie Name is _saml_idp
    05/05/2008 01:41:18:787 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: URL Scheme is null, set to https.
    05/05/2008 01:41:18:789 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred IDP Cookie Not found
    05/05/2008 01:41:18:796 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Cookie Type is PERSISTENT
    05/05/2008 01:41:18:797 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Cookie value is YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=
    05/05/2008 01:41:18:798 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred Cookie Name _saml_idp
    05/05/2008 01:41:18:806 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Redirect to http://amqa-x2100-08.red.iplanet.com:80/openfm/SSORedirect/metaAlias/idp?resInfoID=s2611f93262943905ab083390581b85f05c83d6001
    05/05/2008 01:46:26:786 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred Cookie Name is _saml_idp
    05/05/2008 01:46:26:789 AM PDT: Thread[service-j2ee-6,5,main]
    CookieUtils:cookieValue=YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=, result=YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=
    05/05/2008 01:46:26:790 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Cookie Type is PERSISTENT
    05/05/2008 01:46:26:791 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Cookie value is YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=
    05/05/2008 01:46:26:792 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred Cookie Name _saml_idp
    05/05/2008 01:46:26:793 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Redirect to http://amqa-x2100-08.red.iplanet.com:80/openfm/saml2/jsp/idpSSOInit.jsp?resInfoID=s2110f1c9017525509c5c7c4ae715c0ef6f45ea201
    05/05/2008 01:47:26:656 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred Cookie Name is _saml_idp
    05/05/2008 01:47:26:658 AM PDT: Thread[service-j2ee-6,5,main]
    CookieUtils:cookieValue=YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=, result=YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=
    05/05/2008 01:47:26:659 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Cookie Type is PERSISTENT
    05/05/2008 01:47:26:660 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Cookie value is YW1xYS14MjEwMC0wOC5yZWQuaXBsYW5ldC5jb20=
    05/05/2008 01:47:26:661 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Preferred Cookie Name _saml_idp
    05/05/2008 01:47:26:662 AM PDT: Thread[service-j2ee-6,5,main]
    CookieWriterServlet.doGetPost: Redirect to http://amqa-x2100-08.red.iplanet.com:80/openfm/saml2/jsp/idpSSOInit.jsp?resInfoID=s21501eb5b9656be54878baeb762f5242d1999ad01
    
And now that I've shined a little light on the Identity Provider Discovery Service, discover Electric Light Orchestra's song Shine a Little Love from their excellent 1979 long-player, Discovery.

Sunday Jun 15, 2008

Generating Specialized WARs with Generation X

Here are the instructions in the README found in the /deployable-war directory of the extracted opensso.zip. It describes how to generate a specialized WAR for deployment. I've added some explanations to the procedure.
  1. Create a new directory as the staging area for the WAR you want to generate. For example:
    % mkdir /noconsolewar
  2. Extract the contents of opensso.war into it.
    % cd /noconsolewar
    % jar xvf /opensso/deployable-war/opensso.war
  3. Create the WAR using the appropriate .list file. For example:
    % cd /noconsolewar
    % jar cvf /opensso/deployable-war/fam-nocon.war @/opensso/deployable-war/fam-noconsole.list

    .list files included are:
    • fam-idpdiscovery.list lists the files needed to generate a WAR to deploy the Identity Provider Discovery Service.
    • fam-distauth.list lists the files needed to generate a WAR to deploy the Distributed Authentication User Interface.
    • fam-console.list lists the files needed to generate a WAR to deploy a Federated Access Manager console only.
    • fam-noconsole.list lists the files needed to generate a WAR to deploy a Federated Access Manager server without the console.
  4. Update the generated WAR with the additional files found in the appropriate directory. For example:
    % cd /opensso/deployable-war/noconsole
    % jar uvf /opensso/deployable-war/fam-nocon.war \*

    Directories included are:
    • idpdiscovery contains additional files for the Identity Provider Discovery Service WAR.
    • distauth contains additional files for the Distributed Authentication User Interface WAR.
    • console contains additional files for the console only WAR.
    • noconsole contains additional files for the Federated Access Manager server without a console WAR.
  5. Deploy your specialized WAR.
  6. Access the WAR deployment URL from your browser to configure. For example:
    http://machine-name:port/URI
And now that we are done generatin' WARs, how about Generation X - with a very young and brunette Billy Idol singing New Order at the Marquee Club.

Thursday Jun 12, 2008

What's Up, Doc? Early Access Docs!

We've just added a page to the OpenSSO site that contains links to some of the documentation now being written internally for the productized release of OpenSSO, Sun Federated Access Manager 8.0. These early access documents might contain information and procedures that have not yet been reviewed or tested. In fact, if you find something that doesn't sit right, shoot me an email or comment below and the writing team will look into it.

Click through to the Early Access Documents Page and start federatin'. The page will open in a new window because you know you want to see the credits of Peter Bogdanovich's 1972 film What's Up, Doc? with Barbra Streisand and Ryan O'Neal doing it to Cole Porter's You're the Top.

Monday Jun 09, 2008

Undeploying the Fedlet with Some Light from Jens Lekman

When undeploying fedlet.war (which you might've deployed for demonstration purposes), do the following:

  1. Undeploy the fedlet.war using your web container tools.
  2. Using the command line on the service provider side, delete the fedlet directory that was created during deployment.
  3. Using the OpenSSO console on the identity provider side, remove the entries for the identity provider, service provider, and circle of trust entries that were created under the Federation tab.
  4. Restart the web container on both the identity provider and service provider machines.

And now enjoy some light from Jens Lekman (who canceled his March 27, 2008 concert at the Gothic Theatre in Englewood because of a snowstorm in Seattle - leaving the Mile High City high and Lekman-dry).

Friday Jun 06, 2008

The Fedlet and U (Part 1) and Winky Dink and Me

Fedlet is the catchy name given to fedlet.war. The WAR is a very small archive of a few JARs, a keystore, and metadata (all stored in flat files) that can be embedded into a service provider's Java EE web application to allow for single sign-on (SSO) between an identity provider instance of OpenSSO and the service provider application - WITHOUT installing OpenSSO on the service provider side. The service provider simply downloads the Fedlet, modifies their application to include the Fedlet JARs and, re-archives and redeploys the modified application. The service provider is now able to accept an HTTP POST (that contains a SAML assertion) from the identity provider and retrieve included user attributes to accomplish SSO. (Currently, the Fedlet only supports the HTTP POST Profile.) The flowchart below illustrates how the instance of OpenSSO, configured as the identity provider, determines the user attributes to include in the SAML assertion sent to the service provider.

The Fedlet currently supports identity provider-initiated SSO (push) and service provider-initiated SSO (pull).

Identity Provider-initiated SSO

In identity provider-initiated SSO, the user is authenticated to the identity provider and, thus, able to successfully access a remote service provider. In other words, the user accesses an identity provider (a telco), and clicks on a specialized link to a service provider enabled with the Fedlet (ringtone retailer). The link triggers the creation of a SAML assertion which carries user authentication information to the service provider, allowing the user to gain access via back-end SSO. The following figure illustrates this.

More specific flow information is mapped out in the following diagram.

Service Provider-initiated SSO

In service provider-initiated SSO, the user attempts to access a service provider without a current session and is redirected to the identity provider for authentication. Following successful authentication, the identity provider posts a SAML assertion to the service provider and the user is allowed access. The following figure illustrates this scenario.

More specific flow information is mapped out in the following diagram.

There are two ways to create the Fedlet. You can use the OpenSSO Common Tasks wizard, or you can download the fedlet-unconfigured.zip file and configure it yourself. In this entry, we do the former. When completed the Fedlet contains a JavaServer Pages (JSP) file that we will use to test the configuration.

Creating a Fedlet with the Common Tasks Wizard

If OpenSSO is deployed as the identity provider, the Fedlet.war can be created through a work flow. The identity provider follows the configurations steps on the Common Tasks page of the console to create the Fedlet.zip bundle (that will consist of the Fedlet.war and a README file with instructions on deploying the Fedlet). The Fedlet.war would then be deployed and configured by the service provider.

Before beginning Fedlet creation using the Common Tasks wizard, you must create entity providers and a circle of trust on both the identity provider (IDP) and service provider (SP) instances of OpenSSO. Thus, after using the wizard, the Fedlet will contain pre-configured provider metadata and circle of trust information. See Common Tasks and Common People for the procedure to create the providers and circle of trust. After this is done, follow the steps below to create and test the Fedlet.

  1. Login to the OpenSSO Console on the IDP side.
  2. Navigate through the Access Control - > top-level realm -> Subjects tabs to access the profile of the demo, a default user created during OpenSSO deployment.
  3. Add values to the Email and Employee Number attributes of the demo user profile.
  4. Click Save and navigate back to the Common Tasks tab.
  5. Click Create Fedlet.
  6. Add the following URL to the Name and Destination URL attributes:
    http://fqdn-of-SP-machine:port/fedlet
  7. On the same screen, under Attribute Mapping, add the following mappings:
    employeenumber | employeenumber
    mail | mail
  8. Click Create.
    When the Fedlet has been created, you will see the following message:
    
    Your Fedlet.zip file has been created.
    Your file has been saved to your opensso folder:
    /idpconfig/myfedlets/http:%2F%2Filsdev6.red.iplanet.com:8080%2Ffedlet/Fedlet.zip.
  9. Send the created Fedlet.zip to the SP machine.
  10. Unzip Fedlet.zip on the SP machine.
  11. Login to your web container and deploy the fedlet.war.
  12. Go to http://fqdn-of-SP-machine:port/fedlet/index.jsp.
    The following screen is displayed.

  13. Click the link to create the /fedlet configuration directory.
    After the directory is created, the following screen is displayed.

  14. Click Run Fedlet (SP) Initiated Single Sign-on to validate the first Fedlet setup.
    You will be redirected to the IDP login screen.
  15. Login to the IDP as user demo with password changeit.
    demo will authenticate first with the IDP and then with the SP using SSO. (Watch how the URL changes in your browser.) When the interaction is complete, the screen displayed shows the mapped attributes and links to view the SAMLv2 Response, the Assertion, and the Authentication Statement (Subject) communications used.

  16. Go back to http://fqdn-of-SP-machine:port/fedlet/index.jsp and click Run Identity Provider Initiated Single Sign-on to validate the second Fedlet setup.
    You will be redirected to login to the IDP console. Use demo again. When the interaction is complete, the screen displayed shows the mapped attributes and links to view the SAMLv2 Response, the Assertion, and the Authentication Statement (Subject) communications used.

Coming next is how to use the fedlet-unconfigured.zip with your own application. In the meantime, the title of this entry made me think of the kid's television program, Winky Dink. Here's the opening credits from the 50s version I don't remember mashed with the theme song from the 60s version I do remember. I put this together special - for those who remember the Winkster.

Wednesday Jun 04, 2008

Common Tasks and Common People

Here is how I setup two instances of Federated Access Manager as SAMLv2 providers using the Common Tasks work flow options. I have Glassfish running as the web container on two different machines. On each machine, I deployed the fam.war (the productized version of OpenSSO). The first instance of Federated Access Manager on the machine at dev1.sun.com is now configured as a hosted identity provider using the following procedure.

  1. Launch the FAM console at http://dev1.sun.com:8080/fam/UI/Login and log in as amadmin.
  2. Select Create Hosted Identity Provider under the Common Tasks tab to configure the instance as a SAMLv2 identity provider.
    Select the test key for both signing and encryption, name the circle of trust (for example, idpcot), and keep the default values for the other fields.
  3. Click Configure.
  4. Select Finish to end the task.
    Don't configure anything else on this instance YET.

This instance of Federated Access Manager is now configured as a SAMLv2 identity provider.

The second instance of Federated Access Manager on the machine at dev2.sun.com is now configured as a hosted service provider, and to communicate with the remote identity provider. P>

  1. Launch the FAM console at http://dev2.sun.com:8080/fam/UI/Login and log in as amadmin.
  2. Select Create Hosted Service Provider under the Common Tasks tab to configure the instance as a SAMLv2 service provider.
    Select the test key for both signing and encryption, name the circle of trust (for example, spcot), and keep the default values for the other fields.
  3. Click Configure.
  4. Select the Register Remote Identity Provider task from the resulting window (or from under the Common Tasks tab) to configure the service provider for communication with the previously-configured identity provider.
    Enter http://dev1.sun.com:8888/fam/saml2/jsp/exportmetadata.jsp to dynamically load the identity provider meta data, select the test key for both signing and encryption, and choose the circle of trust previously configured for the hosted service provider.
    See here for an explanation of directories if this URL leads to some confusion.
  5. Click Configure.
  6. Select Finish to end the task.

Finally, to finish the federation configuration, return to the identity provider console (http://dev1.sun.com:8080/fam/UI/Login) and log in as amadmin. Select Register Remote Service Provider and enter http://dev2.sun.com:8888/fam/saml2/jsp/exportmetadata.jsp to dynamically load the remote service provider meta data. Also, select the test key for both signing and encryption, and choose the circle of trust previously configured for the hosted identity provider. After configuration, we can now test the connectivity between the instances.

Using the identity provider console (as we are still logged in), select Test Federation Connectivity. My first attempt at this failed on Account Linking. Not having any idea why, I pinged our trusty engineers and found that, because I was using two instances of Federated Access Manager on different machines in the same domain, iPlanetDirectoryPro (the name of Federated Access Manager cookie that carries the SSOToken) was being overwritten so I had to change the cookie name (on one instance only) under the Configuration -> Sites and Servers tabs. (If you need to do this, restart your web container after making the change.)

  1. Click Inheritance Settings.
  2. Deselect the Cookie Name checkbox and Save.
  3. Modify the Cookie Name value to, for example, idpcookie.
  4. Click Save.

So I ran the test again and this is what I saw. (I used the demo user, configured during deployment of Federated Access Manager.)

  1. Select Test Federation Connectivity.
  2. Select the circle of trust that contains the providers you are testing.
  3. Select the providers you are testing.
  4. Click Start Test.
  5. Click OK to begin.
  6. demo and the password changeit.
  7. demo and the password changeit.
  8. Behind the scenes, the two user accounts will be linked.
  9. Behind the scenes, the user will be logged out of the service provider.
  10. Behind the scenes, the user will be logged in to the service provider without provider credentials.
  11. Behind the scenes, the two user accounts will be unlinked (delinked?).

Now that the federation has been proven successful I'm moving on to the Fedlet. In the meantime, enjoy William Shatner's cover of Common People.

And here's the original from Pulp.

Friday May 30, 2008

A Family of fam Directories

In the midst of deploying, configuring and launching Federated Access Manager to learn about the Fedlet, I got a bit confused about the different directories that are created during the process. The first time I come into contact with a fam directory is when I download fam.zip. When the file is unzipped, everything is put into the /fam directory on the same level on which the ZIP was downloaded. This directory contains fam.war which will be used to deploy Federated Access Manager as well as other adjunct pieces of Federated Access Manager. This directory is not used by Glassfish (my web container of choice) or Federated Access Manager, and should be exploded in a download directory of your choice.

The second fam directory rears it's head when I log into the Glassfish console to deploy fam.war. By default, Glassfish uses the name of the about-to-be-deployed WAR file (without the file extension .war) as the value for its Application Name and Context Root attributes. The context root, which must start with a forward slash (/) and end with a string, identifies a unique, base directory for a web application deployed in a J2EE web container. Glassfish creates this directory in /glassfish/domains/domain_name/applications/j2ee-modules/, and the URL for the deployed web application will include this context root; in this example, http://host_machine:port/fam. The J2EE web container then uses this URL to determine which web application services an incoming request. The context root is stored in sun-web.xml, and the value can be manually modified while deploying the WAR if you want to use another name besides that ubiquitous fam.

The final fam directory is the default value for the configuration directory created after the WAR is deployed and the Federated Access Manager Configurator is launched. This value can be changed to any directory to which the web container can write - and I would do that to remain sane. In the course of configuration, a tree is created under the configuration directory that contains the bootstrap file, a sub config directory, an opends directory, and other files.

So there you have it: three directories with different purposes that make Federated Access Manager family friendly. Now join hands with a different Family, the cast of Dreamgirls.

Thursday May 29, 2008

Altering Technical Overview Images

The following images need to be reviewed. They will be in the Technical Overview for Federated Access Manager 8.0. Please check for accuracy and simplicity. Feel free to remove extraneous boxes, code, etc. Sorry to those external to Sun's intranet; the links are internal only (although if you can find the blog entry where I sent out the Technical Overview for review you can look at the PDF or if you go to the Engineering Documents page on opensso.dev.java.net you can find the originals).

The following image illustrates the internal architecture of Federated Access Manager.
Original

The following image illustrated the authentication and authorization interactions.
Original

The following image illustrates the communication between authentication service components
Original

The following image illustrates the components of the Policy Service.
Original

The following image illustrates the components of the Session Service.
Original

The following image illustrates the components of the Logging Service.
Original

The following image illustrates the components of Federation Services.
Original

The following image illustrates the interactions of Web Services Security.
Original

The following image illustrates the interactions of Identity Services.
Original

And while we are altering images, here is Altered Images and Don't Talk to Me About Love.

Wednesday May 21, 2008

You Gotta Get an Administrative User - and a Gimmick

Following are the four users created by OpenSSO in the embedded data store during an installation/configuration:

  • puser is a proxy user used for all queries made to the embedded data store. It benefits from a configured proxy user ACI and, therefore, can take on any user's privileges (for example, the organization administrator or an end user) and perform actions on behalf of that user when necessary. It maintains an open connection through which all queries are passed (retrieval of service configurations, organization information, etc.). The puser password is always encrypted.
  • dsameuser is used for binding to the embedded data store when the Client SDK performs operations that are not linked to a particular user (for example, retrieving service configuration information). puser performs these operations on behalf of dsameuser, but a bind must first validate the dsameuser credentials. dsameuser should have the permissions to add, delete, modify, and search the data store. secret12 is the default password.
  • amldapuser is used to bind to and search supported LDAP servers during LDAP and Membership authentication. The Authentication Service binds to the server as amldapuser in order to search for a user to match the login identifier passed by the user. It is also used internally for configuring policy. secret123 is the default password.
  • amadmin is the administrative user for OpenSSO. admin123 is the default password.

And here's the gimmick: Faith Dane as Mazeppa, Roxanne Arlen as Electra, Betty Bruce as Tessie, and the luminescent Natalie Wood sitting through it all as Louise in Gypsy.

Monday May 19, 2008

A Secret Agent Property and a Secret Agent Man

Notwithstanding the break neck speed at which the blog on new policy agent properties was posted, I found another new property specific to the J2EE agent.

com.sun.identity.agents.config.client.ip.header

This property is used when the agent is installed behind a proxy or load balancer. Often time the client IP address returned by request.getRemoteAddr() is that of the proxy or load balancer - not the real client IP. The proxy or load balancer may set the real client IP in an X-Forward-IP header so, setting the property com.sun.identity.agents.config.client.ip.header equal to X-Forward-IP will make the agent retrieve the real client IP address from this header to use in the policy evaluation.

And from a secret agent property to a Secret Agent - here's the smash hit theme from the television series Secret Agent called Secret Agent Man as interpreted by Johnny Rivers.

Who knew he played the guitar? UPDATED 5/21/08

Active Directory Attributes and A-HA

Out-of-the-box, OpenSSO defines a set of objectclasses and attributes that are required to be a part of your directory schema if you want to manage the user entries using the OpenSSO console. If the directory you are trying to access does not have the predefined objectclasses and attributes, any attempted access involving the missing properties will fail. For example, when you create a user using the OpenSSO console, the console writes to the directory the predefined objectclasses and attributes for the user. If the directory is not configured with the same set of user objectclasses and attributes, the user create operation will fail.

When configuring Microsoft Active Directory to work with OpenSSO, you have to map the predefined properties to properties defined in your instance of Active Directory; this is attribute mapping. Following are the attributes that need to be defined when adding Active Directory as a data store to a realm. The configuration will allow you to list users and groups. It will also allow you to perform some user operations. The values assume a freshly installed Active Directory to which no attribute or schema changes have yet been made.

Still waiting for some email to verify some of the newer attributes. Will update when I receive them.

  • LDAP Server enter the host machine name and port number of the instance of Active Directory to which you are connecting. For example, myADServer.sun.com:389
  • LDAP Bind DN by default, CN=Administrator,CN=Users,dc=sun,dc=com
  • LDAP Bind Password enter the password for CN=Administrator,CN=Users,dc=sun,dc=com
  • LDAP Bind Password (confirm) confirm the password for CN=Administrator,CN=Users,dc=sun,dc=com
  • LDAP Organization DN enter the distinguished name (DN), defined in Active Directory, of the organization to which this data store will map; this becomes the base DN for all operations performed in this data store
  • LDAP SSL select if the directory is configured in SSL mode
  • LDAP Connection Pool Minimum Size specify the initial number of connections allowed in the connection pool; using the connection pool avoids creating a new connection every time
  • LDAP Connection Pool Maximum Size specify the maximum number of connections allowed
  • Maximum Results Returned from Search specify the maximum number of results to return when searching; this figure should be based on the size of your LDAP organization and cannot exceed the ns size limit configured on the directory side
  • Search Timeout specify the maximum time in seconds to wait for results from a search operation
  • LDAP Follows Referral select to specify whether or not referrals to other LDAP servers are automatically followed
  • LDAPv3 Repository Plug-in Class Name specify the path to the implemented class for Active Directory; by default, com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo
  • Attribute Name Mapping map any OpenSSO attributes to those in Active Directory; by default:

    • employeeNumber=distinguishedName
    • iplanet-am-user-alias-list=objectGUID
    • mail=userPrincipalName
    • portalAddress=sAMAccountName
    • telephonenumber=displayName
    • uid=sAMAccountName
  • LDAPv3 Plug-in Supported Types and Operations no changes needed
  • LDAPv3 Plug-in Search Scope select the range of any plug-in searches
  • LDAP Users Search Attribute specify the attribute used to search; by default, uid
  • LDAP Users Search Filter specify which entries the search will return; by default, only those entries that contain objectclass=person
  • LDAP User Object Class define the objectclasses added to a user's attribute list when the user is created; by default:

    • organizationalPerson
    • person
    • sunFederationManagerDataStore
    • sunFMSAML2NameIdentifier
    • sunIdentityServerLibertyPPService
    • top
    • User

    (objectclasses defined must actually exist in Active Directory or be mapped to one that exists otherwise you will get an objectclass violation)
  • LDAP User Attributes define the definitive list of attributes associated with a user entry; the attribute will not be sent or read if it is not on this list which, by default:

    • employeeNumber
    • objectClass
    • sAMAccountName
    • userpassword
    • mail
    • distinguishedName
    • userPrincipalname
    • objectGUID
    • sAMAccountType
    • name
    • displayName

    (if there is the slightest possibility that the user entry will contain an attribute include it here; on the other hand, if the attribute is not defined in Active Directory, do not enter it)
  • Create User Attribute Mapping
  • Attribute Name of User Status check the defined attribute to see if user is active or inactive; by default, userAccountControl
  • User Status Active Value
  • User Status Inactive Value
  • LDAP Groups Search Attribute by default, cn is the attribute used to construct the group's DN and search filter
  • LDAP Groups Search Filter by default, the search filter will return only those entries that contain objectclass=group
  • LDAP Groups Container Naming Attribute define the naming attribute for a group container if the groups reside in a container; by default, cn
  • LDAP Groups Container Value users (the value for the group container.)
  • LDAP Groups Object Class defines the objectclasses that will be added to a group when it is created; by default:

    • Group
    • top
  • LDAP Groups Attributes defines the definitive list of attributes associated with a groups entry; the attribute will not be sent or read if it is not on this list;

    • cn
    • distinguishedName
    • dn
    • member
    • name
    • objectCategory
    • objectclass
    • sAMAccountName
    • sAMAccountType

    (if there is the slightest possibility that the group entry will contain an attribute include it here; on the other hand, if the attribute is not defined in Active Directory, do not enter it)

  • Attribute Name for Group Membership specify the attribute in the user entry that contains the values that define the groups to which the entry belongs; generally, memberOf
  • Attribute Name of Unique Member specify the attribute in the groups entry that contains the DN of each member; by default, member
  • Attribute Name of Group Member URL specify the attribute in the groups entry whose value is an LDAP URL which resolves to the members belonging to it; by default, memberUrl
  • LDAP People Container Naming Attribute specify the attribute in a user entry of the people container in which the users reside, if applicable; leave blank if they don't reside in a people container
  • LDAP People Container Value by default, users
  • Identity Types That Can Be Authenticated
  • Authentication Naming Attribute by default, uid
  • Persistent Search Base DN specify the base DN to use for persistent searches; this needs to be the root suffix of your Active Directory instance
  • Persistent Search Filter specify which entries the search will return; by default, only those entries that contain objectclass=\*
  • Persistent Search Scope select the range of any persistent searches
  • Persistent Search Maximum Idle Time Before Restart specify the time in minutes before restarting an idle persistent search
  • Maximum Number of Retries After Error Codes specify the maximum number of times that a persistent search can be retried if it encounters the specified error codes; by default, 3
  • The Delay Time Between Retries specify the time in milliseconds to wait before each retry; by default, 1000
  • LDAPException Error Codes to Retry On specify the error codes that will initiate a retry on a persistent search operation; only applicable for persistent searches
  • Caching select enable
  • Maximum Age of Cached Items specify the oldest (in seconds) a cache item can be before it is removed; by default, 600
  • Maximum Size of the Cache specify the maximum size of the cache; by default, 10240

Now let's move on from the Active Directory attributes (ADA) to A-HA and my favoritest song by them. Oh, the nights I danced to this one!

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