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.

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!

Friday May 02, 2008

Policy Agent Configuration with Agent 99

When configuring a 3.0 policy agent, you can choose either Local Configuration or Centralized Configuration. (You can also change from centralized to local after configuration using the console.) If Local Configuration is chosen, the properties will be stored in a properties file on the agent machine. You cannot use the console to edit locally configured properties. With Centralized Configuration, 3.0 policy agent properties can be modified using the console or the famadm command line interface.

To set the configuration on the command line, use famadm to set the new property (see table below) com.sun.identity.agents.config.repository.location with a value equal to local. (The default value is centralized.)

The console uses human-readable property labels rather than the programmatic property names; for example, com.sun.identity.agents.config.login.url is displayed as FAM Login URL in the console. When using famadm for configuration, you need to use the 3.0 property names. For version 3.0 web agents, the property names have been changed; for J2EE agents, the property names for 2.2 and 3.0 are the same. Following is a mapping of the old and new web agent properties.

Old Name New Name
com.sun.am.naming.url com.sun.identity.agents.config.naming.url
com.sun.am.log.level com.sun.identity.agents.config.log.level
com.sun.am.policy.agents.config.local.log.file com.sun.identity.agents.config.local.logfile
com.sun.am.policy.am.username com.sun.identity.agents.config.username
com.sun.am.policy.am.password com.sun.identity.agents.config.password
com.sun.am.sslcert.dir com.sun.identity.agents.config.sslcert.dir
com.sun.am.certdb.prefix com.sun.identity.agents.config.certdb.prefix
com.sun.am.certdb.password com.sun.identity.agents.config.certdb.password
com.sun.am.auth.certificate.alias com.sun.identity.agents.config.certificate.alias
com.sun.am.trust_server_certs com.sun.identity.agents.config.trust.server.certs
com.sun.am.receive_timeout com.sun.identity.agents.config.receive.timeout
com.sun.am.connect_timeout com.sun.identity.agents.config.connect.timeout
com.sun.am.tcp_nodelay.enable com.sun.identity.agents.config.tcp.nodelay.enable
com.sun.am.policy.am.login.url com.sun.identity.agents.config.login.url
com.sun.am.cookie.name com.sun.identity.agents.config.cookie.name
com.sun.am.cookie.secure com.sun.identity.agents.config.cookie.secure
com.sun.am.policy.agents.config.local.log.rotate com.sun.identity.agents.config.local.log.rotate
com.sun.am.policy.agents.config.local.log.size com.sun.identity.agents.config.local.log.size
com.sun.am.policy.agents.config.audit.accesstype com.sun.identity.agents.config.audit.accesstype
com.sun.am.policy.agents.config.remote.log com.sun.identity.agents.config.remote.logfile
com.sun.am.policy.agents.config.deny_on_log_failure com.sun.identity.agents.config.deny.access.log.failure
com.sun.am.notification.enable com.sun.identity.agents.config.notification.enable
com.sun.am.policy.am.url_comparison.case_ignore com.sun.identity.agents.config.url.comparison.case.ignore
com.sun.am.policy.am.polling.interval com.sun.identity.agents.config.policy.cache.polling.interval
com.sun.am.sso.polling.period com.sun.identity.agents.config.sso.cache.polling.interval
com.sun.am.policy.am.userid.param com.sun.identity.agents.config.userid.param
com.sun.am.policy.am.userid.param.type com.sun.identity.agents.config.userid.param.type
com.sun.am.policy.agents.config.profile.attribute.fetch.mode com.sun.identity.agents.config.profile.attribute.fetch.mode
com.sun.am.policy.agents.config.profile.attribute.map com.sun.identity.agents.config.profile.attribute.mapping
com.sun.am.policy.agents.config.session.attribute.fetch.mode com.sun.identity.agents.config.session.attribute.fetch.mode
com.sun.am.policy.agents.config.session.attribute.map com.sun.identity.agents.config.session.attribute.mapping
com.sun.am.policy.agents.config.response.attribute.fetch.mode com.sun.identity.agents.config.response.attribute.fetch.mode
com.sun.am.policy.agents.config.response.attribute.map com.sun.identity.agents.config.response.attribute.mapping
com.sun.am.load_balancer.enable com.sun.identity.agents.config.load.balancer.enable
com.sun.am.policy.agents.config.agenturi.prefix com.sun.identity.agents.config.agenturi.prefix
com.sun.am.policy.agents.config.locale com.sun.identity.agents.config.locale
com.sun.am.policy.agents.config.do_sso_only com.sun.identity.agents.config.sso.only
com.sun.am.policy.agents.config.accessdenied.url com.sun.identity.agents.config.access.denied.url
com.sun.am.policy.agents.config.fqdn.check.enable com.sun.identity.agents.config.fqdn.check.enable
com.sun.am.policy.agents.config.fqdn.default com.sun.identity.agents.config.fqdn.default
com.sun.am.policy.agents.config.fqdn.map com.sun.identity.agents.config.fqdn.mapping
com.sun.am.policy.agents.config.cookie.reset.enable com.sun.identity.agents.config.cookie.reset.enable
com.sun.am.policy.agents.config.cookie.reset.list com.sun.identity.agents.config.cookie.reset
com.sun.am.policy.agents.config.cookie.domain.list com.sun.identity.agents.config.cookie.domain
com.sun.am.policy.agents.config.anonymous_user com.sun.identity.agents.config.anonymous.user.id
com.sun.am.policy.agents.config.anonymous_user.enable com.sun.identity.agents.config.anonymous.user.enable
com.sun.am.policy.agents.config.notenforced_list com.sun.identity.agents.config.notenforced.url
com.sun.am.policy.agents.config.notenforced_list.invert com.sun.identity.agents.config.notenforced.url.invert
com.sun.am.policy.agents.config.notenforced_client_ip_list com.sun.identity.agents.config.notenforced.ip
com.sun.am.policy.agents.config.ignore_policy_evaluation_if_notenforced com.sun.identity.agents.config.notenforced.url.attributes.enable
com.sun.am.policy.agents.config.postdata.preserve.enable com.sun.identity.agents.config.postdata.preserve.enable
com.sun.am.policy.agents.config.postcache.entry.lifetime com.sun.identity.agents.config.postcache.entry.lifetime
com.sun.am.policy.agents.config.client_ip_validation.enable com.sun.identity.agents.config.client.ip.validation.enable
com.sun.am.policy.agents.config.profile.attribute.cookie.prefix com.sun.identity.agents.config.profile.attribute.cookie.prefix
com.sun.am.policy.agents.config.profile.attribute.cookie.maxage com.sun.identity.agents.config.profile.attribute.cookie.maxage
com.sun.am.policy.agents.config.cdsso.enable com.sun.identity.agents.config.cdsso.enable
com.sun.am.policy.agents.config.cdcservlet.url com.sun.identity.agents.config.cdsso.cdcservlet.url
com.sun.am.policy.agents.config.logout.url com.sun.identity.agents.config.logout.url
com.sun.am.policy.agents.config.logout.cookie.reset.list com.sun.identity.agents.config.logout.cookie.reset
com.sun.am.policy.am.fetch_from_root_resource com.sun.identity.agents.config.fetch.from.root.resource
com.sun.am.policy.agents.config.get_client_host_name com.sun.identity.agents.config.get.client.host.name
com.sun.am.policy.agents.config.convert_mbyte.enable com.sun.identity.agents.config.convert.mbyte.enable
com.sun.am.policy.agents.config.encode_url_special_chars.enable com.sun.identity.agents.config.encode.url.special.chars.enable
com.sun.am.policy.agents.config.ignore_path_info com.sun.identity.agents.config.ignore.path.info
com.sun.am.policy.agents.config.override_protocol com.sun.identity.agents.config.override.protocol
com.sun.am.policy.agents.config.override_host com.sun.identity.agents.config.override.host
com.sun.am.policy.agents.config.override_port com.sun.identity.agents.config.override.port
com.sun.am.policy.agents.config.override_notification.url com.sun.identity.agents.config.override.notification.url
com.sun.am.policy.agents.config.connection_timeout com.sun.identity.agents.config.connection.timeout
com.sun.am.ignore_server_check com.sun.identity.agents.config.ignore.server.check
com.sun.am.poll_primary_server com.sun.identity.agents.config.poll.primary.server
com.sun.am.ignore.preferred_naming_url com.sun.identity.agents.config.ignore.preferred.naming.url
com.sun.am.policy.agents.config.proxy.override_host_port com.sun.identity.agents.config.proxy.override.host.port
com.sun.am.policy.agents.config.domino.check_name_database com.sun.identity.agents.config.domino.check.name.database
com.sun.am.policy.agents.config.iis.auth_type com.sun.identity.agents.config.iis.auth.type
com.sun.am.replaypasswd.key com.sun.identity.agents.config.replaypasswd.key
com.sun.am.policy.agents.config.iis.filter_priority com.sun.identity.agents.config.iis.filter.priority
com.sun.am.policy.agents.config.iis.owa_enabled com.sun.identity.agents.config.iis.owa.enable
com.sun.am.policy.agents.config.iis.owa_enabled_change_protocol com.sun.identity.agents.config.iis.owa.enable.change.protocol
com.sun.am.policy.agents.config.iis.owa_enabled_session_timeout_url com.sun.identity.agents.config.iis.owa.enable.session.timeout.url
NEW com.sun.identity.agents.config.repository.location
NEW com.sun.identity.agents.config.freeformproperties
NEW com.sun.identity.agents.config.polling.interval
NEW com.sun.identity.agents.config.cleanup.interval

I'll see if I can find mappings between the new names and the console labels and let you know when I do. They ain't always easy to figure out. But, wait, we're not done with agents yet. Here's, what I assume is, Barbara Feldon's only foray into song. It's called 99 and was released when she was on top of her game as Agent 99 in the 1960s television series, Get Smart.

Monday Apr 28, 2008

Sticky Cookies and Sticky Fingers

A load balancer deployed with OpenSSO must support sticky sessions. A sticky session specifies that once a session is created by a specific OpenSSO instance subsequent requests from the user will be routed to that same instance to preserve session information. If you have a deployment with a load balancer between 2 instances of OpenSSO, you can configure the load balancer for cookie stickiness by defining the value of the com.iplanet.am.lbcookie property to the name of the cookie; amlbcookie is the default name of the sticky cookie. When cookie stickiness is enabled, you will get better performance from OpenSSO by avoiding back channel communications, and the OpenSSO console will work properly behind the load balancer. More information on cookies and sticky sessions can be found in the official Access Manager 7.1 documentation. And since sticky cookies give you sticky fingers, here's a live video of The Rolling Stones singing a song (which shall remain nameless in this entry) from their 1971 LP, Sticky Fingers.

Thursday Apr 24, 2008

Centralized Agent Configuration and Eurovision

Policy agents function based on a set of configuration properties. Previously, these properties were stored in the AMAgent.properties file that resides on the same machine as the agent. With centralized agent configuration, OpenSSO moves most of the agent configuration properties to the configuration data store.

Agent profiles can be configured to store properties locally (on the machine to which the agent was deployed) or centrally (in the configuration data store), making this new function compatible with both older 2.x agents and newer 3.0 agents. Agent configuration data is now relegated to the following:

  1. FAMAgentBootstrap.properties\* contains bootstrap data and is stored on the agent machine. This file indicates the location from where the configuration properties need to be retrieved. It is used by agents profiles configured locally or centrally.
  2. FAMAgentConfiguration.properties\* contains local configuration data and is stored on the agent machine. It is only used by agent profiles configured locally.
  3. The configuration data store holds the remainder of the agent configuration data.

With agent configuration centralized, an administrator is able to manage multiple agent configurations from the OpenSSO console. Most of the agent properties are hot swappable. (Properties can be modified without rebooting the underlying agent web container.) Additionally, notification of the agent when configuration data changes and polling by the agent for configuration changes is enabled. Agents can also receive notifications of session and policy changes.

NOTE: The configuration change notification does not contain the new data; it is just a ping that, when received, tells the agent to make a call to OpenSSO and reload the latest. Session and policy notifications, on the other hand, contain the actual data changes. Also, when using a load balancer, the notification is sent directly to the agent whose configuration has been changed. It does not go through the load balancer.

The figure below illustrates how an agent retrieves bootstrapping and local configuration data, and configuration data from the configuration data store.

Now that you've got an idea about centralized agent configuration in OpenSSO, how about checking out the Icelandic entry in Eurovision 2008. Here's Euroband singing This Is My Life.

\*UPDATE: Thanks to Sean for the properties files update.

Monday Apr 21, 2008

CommunityOne, Second LIfe and Three Dog Night

Just a few reminders to start your Monday morning:
  1. CommunityOne is coming on May 5, 2008. This FREE open-source conference is piggy-fronted on the Monday before JavaOne begins. There are many, many workshops and sessions to choose from. Those that might interest users of OpenSSO include:

    A PDF of the full CommunityOne schedule can be downloaded here.
  2. Second Life is a three-dimensional virtual world. Sun Microsystems now has a few islands in Second Life and are planning a big employee party on April 29. (Sorry non-Sun employees. The party though is only on one of Sun's islands; the other islands are open to all.) I'm not a gamer so I don't usually play around with these types of things but I am attending the employee party. I've already created my avatar - which took forever to finish and looks as much like me as a cartoon character can. Sun employees only can check out the internal web site but everyone can follow along at the external virtual worlds blog.
  3. And to turn this couplet into a triumverate, here's a video of Three Dog Night singing Out in the Country. Sad how relevant this song is today, almost forty years after it was initially written.

Wednesday Apr 16, 2008

Using the amunixd Daemon and Me

The current Access Manager 7.1 and the future Federated Access Manager (FAM) 8.0 (not OpenSSO as it does not bundle native platform binaries) can be configured to process authentication requests against Unix user IDs and passwords known to the Solaris or Linux system on which it is installed. The Unix Authentication module makes use of an authentication helper daemon, amunixd, which opens a socket to localhost:58946 in order to listen for Unix authentication requests. It is a separate process from the FAM process. At startup, this daemon listens on a port for configuration information.

Previously documented for Access Manager 7.1 incorrectly, this entry takes the information from the filed bug to rectify that faux-pas. The correct syntax for amunixd is:

amunixd -i #-of-addrs -a ipaddr-1 -a ipaddr-2 ... -a ipaddr-N

In an instance of Federated Access Manager deployed in a web container, amunixd can be found in any of the following directories:
  • /fam/tools/helpers/bin
  • /fam/tools/helpers/sparc
  • /fam/tools/helpers/x86
And now that you see the correct usage, you can use amunixd or, if you'd like to, use something else - as Bill Withers so eloquently sings in the video below.

Thursday Apr 10, 2008

The Policy Condition Timeout Value Makes Time for Spike Jones

The Timeout Value attribute of the Policy condition Authentication by Module Instance defines when the application (defined as the value of the Application Name attribute of the Policy condition Authentication by Module Instance) should force re-authentication.

CAUTION : The application name (app_name in session below) is a grouping of resources being protected. For example, all resources that constitute the paycheck application can be defined as paycheck. So, if the same app_name (in this case, paycheck) is used in two different policies with different Timeout Value values, the result is randomly picked up.

An authenticated user can lose access to a protected resource after a defined amount of time has passed (from the time of authentication). If the user attempts access after the time is up, the policy agent will force authentication again using the scheme configured in the Authentication by Module Instance condition. After successful authentication, the user will again be allowed access to the resource. Re-authentication will be required to access the protected resource, if idle, regardless of the session time limits. (If the Timeout Value is longer than the maximum session time, the user will not be affected by it but, if the session's idle timeout is reached, the session will timeout.)

For example, assume Application A and Application B are configured for single sign-on. Additionally:

  • Application A has a Timeout Value equal to 10 minutes
  • Application B has a Timeout Value equal to 60 minutes

A user successfully logs in to Application A and receives a session token. When the same user accesses Application B, no additional authentication is needed. But, after ten minutes of idle time, Application A requires re-authentication. A use cases for this attribute might be when user jdoe logs in to a protected application configured for re-authentication after 10 minutes of idle time (from the time of authentication set in the session). jdoe leaves the public computer with out closing the browser, and user jsmith arrives ten minutes after and attempts to access the resource again. The login page is displayed and jsmith must authenticate before access is permitted.

One thing to keep in mind is that this attribute value does not depend on the session time limit. For every time authentication is forced, the moduleAuthTime property in the session token is checked against the value of the Timeout Value condition in the policy. A typical session might look like this:

<Session sid="AQIC5wM2LY4Sfcy6UFgE25jdHKzJwphzxFrvqL1suAk/8aU=@AAJTSQACMDE=#" stype="user" cid="uid=amAdmin,ou=People,O=SUN\\\\ MICROSYSTEMS INC." cdomain="o=sun microsystems inc." maxtime="120" maxidle="30" maxcaching="3" timeidle="10" timeleft="6694" state="valid">
<Property name="CharSet" value="UTF-8"></Property>
<Property name="UserId" value="amAdmin"></Property>
<Property name="successURL" value="/amserver/console"></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="am.protected.policy.AppIdleTimesoutAt.app_name" value="1172883917924"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4SfczFsOZaE5/uQQtygnlHv1mJuFlOY3K4uUg=@AAJTSQACMDE=#"></Property>
<Property name="UserToken" value="amAdmin"></Property>
<Property name="loginURL" value="/amserver/UI/Login"></Property>
<Property name="IndexType" value="module_instance"></Property>
<Property name="Principals" value="uid=amAdmin,ou=People,O=SUN MICROSYSTEMS INC."></Property>
<Property name="moduleAuthTime" value="LDAP+2007-03-03T01:04:17Z|mem+2007-03-03T01:06:39Z"></Property>
<Property name="sun.am.UniversalIdentifier" value="id=amadmin,ou=user,o=sun microsystems inc.,amsdkdn=uid=amadmin,ou=people,o=sun microsystems inc."></Property>
<Property name="amlbcookie" value="01"></Property>
<Property name="Organization" value="o=sun microsystems inc."></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="HostName" value="129.145.155.166"></Property>
<Property name="Host" value="129.145.155.166"></Property>
<Property name="UserProfile" value="Required"></Property>
<Property name="AMCtxId" value="4b21c5d982164fbe01"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="authInstant" value="2007-03-03T01:06:39Z"></Property>
<Property name="Principal" value="uid=amAdmin,ou=People,O=SUN MICROSYSTEMS INC."></Property>
</Session></GetSession>
The following properties in the session are relevant.
  • am.protected.policy.AppIdleTimesoutAt.app_name
  • moduleAuthTime

NOTE : The protecting policy agent should run in self policy decision cache mode and the com.sun.am.policy.am.fetch_from_root_resource property should be set to false.

I'm taking tomorrow off to spend the weekend in Yosemite. 65 years ago, Spike Jones and his City Slickers made a soundie that neatly sums up how I feel having three days off.

Monday Apr 07, 2008

Conquering LDAP Redeploy Errors By Using Them Up and Wearing 'Em Out

The lab machines reserved for us writers are none-too-current: hard drive size and RAM are not the correct specifications for deploying Glassfish, OpenSSO, and other agents/web services. Because of this I always have issues re-deploying a new OpenSSO WAR file successfully...until today (actually Friday but I'm writing this today).

When I undeploy the OpenSSO WAR, it leaves some processes running on Glassfish which don't allow for a new WAR to be deployed. (I've seen mainly LDAP and OpenDS errors.) I figured out that I can redeploy a new OpenSSO WAR if I have a new install of Glassfish - which puts the step where I have to jumpstart and wait for a new OS to be installed (and therefore wait for the lab guy to restart the DNS) in the trash. So follow this procedure to find the processes, kill them, uninstall Glassfish, and get it back up.

  1. Run jps at the command line.
    This is the command for discovering running Java processes.
  2. Kill any PELaunch processes you see using the kill -9 process-number command on the command line.
    See http://forums.java.net/jive/message.jspa?messageID=244886.
  3. Remove the glassfish directory.
  4. Start all over again using this blog entry.

Voila, I got the whole shebang up and running again. Not too pretty but it works.

And here is something else that works: a cover of (the late 70s dance group) Odyssey's excellent tune Use It Up and Wear It Out by early 90s disc jockeys Pat & Mick - as produced by PWL. Shake your body down!

Thursday Apr 03, 2008

Reviewing Implementing Federation and Watching I'm Gonna Be Strong

Between blog entries, I am writing the Sun Java System Federated Access Manager 8.0 Technical Overview. Aside from writing about new features, this book also includes updated material first written for Access Manager 7.1, the SAMLv2 Plugin for Federation Services and Federation Manager 7.0. Towards that lofty goal, I have finished a draft for the chapter entitled Implementing Federation. This chapter collects information regarding the federation protocol available in Federated Access Manager 8.0.

I've sent the chapter to internal Sun engineers for review but I also want to hear from the OpenSSO community. A PDF of this chapter is available for your perusal here. If you have any ideas on what might be missing, or comments on what is currently included please feel free to leave a comment or email me.

Since I'm gonna be strong when I read all these comments, here's Gene Pitney singing I'm Gonna Be Strong. This man has one of the best voices; I never tire of hearing the old records (yes, records) that I have of his.

Cyndi Lauper, one of the best female voices, covered I'm Gonna Be Strong when she was the lead singer of Blue Angel in 1980 (and then again on a solo album). Here's a clip of Cyndi singing the Barry Mann and Cynthia Weil classic with Blue Angel.

I also covered I'm Gonna Be Strong (a cappella, mind you) when I was performing songs and pithy comedy eons ago. I shall find that video tape and one day make this couplet a triplet. That should be scary!

Wednesday Apr 02, 2008

How to Configure PAL Portal and OpenSSO

In my travails around the 'net, I came upon this blog entry that explains how to configure PAL Portal for use with OpenSSO. Great that someone wrote this up but I had no idea what PAL Portal was so I found this blog entry (from the same Portal Application Laboratory blog) that explains what PAL Portal is and where to download it. Oh, cool. An open-source portal server. But what's Jetspeed2? Oh, cool. An open-source portal enterprise server.

Uh, can we get a few more layers on this architecture, please!

Thanks.

If you're not interested in getting OpenSSO to work with PAL Portal, you might be interested in this video by Grace Potter and the Nocturnals. It's the song Ah Mary.

Tuesday Apr 01, 2008

Setting Up Web Services Security, the Security Token Service and the Tokens

This procedure assumes that you already have an instance of the Glassfish Application Server installed. The following sections must be completed.

  1. Creating Glassfish Domains and Deploying OpenSSO WAR
  2. Deploying the Web Service Provider on Glassfish
  3. Configuring the WSP to Use the Security Token Service
  4. Configuring the Web Service Client (WSC) and the WSP to Use the Security Token Service
  5. Configuring the WSC to Use the Security Token Service

Creating Glassfish Domains and Deploying OpenSSO WAR
  1. Using Glassfish, create two domains - one named wsc and the other wsp.

    1. Create /tmp/passfile with following content:

      AS_ADMIN_ADMINPASSWORD=adminadmin
      AS_ADMIN_MASTERPASSWORD=changeit
    2. Create the domains using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

      ./asadmin create-domain --adminuser admin --passwordfile /tmp/passfile --portbase 7000 wsc

      ./asadmin create-domain --adminuser admin --passwordfile /tmp/passfile --portbase 9000 wsp
  2. Change to the GLASSFISH_INSTALL_DIR/domains/wsc/config/ directory and make the following changes to the domain.xml file.

    1. Change jvm-options from -client to -server.
    2. Change jvm-options from -Xmx512m to -Xmx1G.
  3. OPTIONAL: If OpenSSO has already been deployed and configured, remove the deployed WAR as follows:

    1. Undeploy the application using the Glassfish console.
    2. Delete the /opensso configuration directory.

      rm -rf /opensso
    3. Delete the /AccessManager directory.

      rm -rf /AccessManager
  4. Start the two domains using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

    ./asadmin start-domain wsc
    ./asadmin start-domain wsp
  5. (Re)deploy the OpenSSO WAR in the wsc domain using the Glassfish console.

    Keep the default values and click OK.
  6. Launch the deployed OpenSSO web application from the Glassfish console and, when the configuration wizard is displayed, under Custom Configuration, select Create New Configuration.
  7. Use the following values to create the new configuration and click Create Configuration when finished.

    1. Enter a password for amadmin under the General settings, confirm it and click Next.
    2. Keep the default Server Settings values (or modify as necessary) and click Next.

      • Server URL - for example, http://sid.opensso.com:8080
      • Cookie Domain - for example, .opensso.com
      • Platform Locale - for example, en_US
      • Configuration Directory - for example, /openssoconfig
    3. Keep the default Configuration Store values (or modify as necessary) and click Next.

      • Data Store Type - for example, Embedded (Open DS)
      • Port - for example, 50389
      • Encryption Key - as populated by configurator
      • Root Suffix - for example, dc=opensso,dc=java,dc=net
    4. Ensure that the Embedded radio button is selected as the default User Store Settings value and click Next.
    5. Ensure that the No radio button is selected as the default Site Configuration value for the question Will this instance be deployed behind a load balancer as part of a site configuration? and click Next.
    6. Enter a password for amldapuser under the Agent Information settings, confirm it and click Next.

      This password must be different from the one previously entered for amadmin.
    7. Ensure the Summary is correct and click Create Configuration.
    8. After the configuration is complete, click Proceed to Login.

  8. Login to the OpenSSO console as the default amadmin administrator using the corresponding password.

Deploying the Web Service Provider on Glassfish

  1. Download openssowssproviders.zip using the WSS Agent Download link on the OpenSSO Download page.
  2. Make a directory named wss_bits and unzip the contents of the openssowssproviders.zip into it.
  3. Deploy a web service provider (WSP) into the wsp Glassfish domain.

    Use the StockService sample included with the provider download. Information on deploying the Stock Service can be found in the README located in the samples/glassfish directory of the exploded openssowssproviders.zip.
  4. Stop the wsp domain using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

    ./asadmin stop-domain wsp
  5. Change to the GLASSFISH_INSTALL_DIR/domains/wsp/config/ directory and make the following modifications to the domain.xml file.

    1. Add the following code fragment under the <message-security-config auth-layer="HttpServlet"> tag.

      NOTE : Create the <message-security-config auth-layer="HttpServlet"> tag if it is not already present.

      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMHttpAuthModule"
      provider-id="FAMHttpProvider" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMHttpAuthModule"
      provider-id="FAMAuthHttpProvider" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="wsc"/>
      </provider-config>
      
    2. Add the following code fragments under the <message-security-config auth-layer="SOAP"> tag.

      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-SAML-HolderOfKey" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="SAML-HolderOfKey"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-SAML-SenderVouches" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="SAML-SenderVouches"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-X509Token" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="X509Token"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-LibertySAMLToken" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="LibertySAMLToken"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMClientAuthModule"
      provider-id="FAMClientProvider" provider-type="client">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="wsc"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-UserNameToken" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="UserNameToken"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-UserNameToken-Plain" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="UserNameToken-Plain"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-LibertyX509Token" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="LibertyX509Token"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-LibertyBearerToken" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="LibertyBearerToken"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="wsp"/>
      </provider-config>
      
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-Anonymous" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="Anonymous"/>
      </provider-config>
      
      
    3. Start the wsp domain using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

      ./asadmin start-domain wsp

  6. Log in to the Glassfish console as administrator.

Configuring the WSP to Use the Security Token Service

These configurations are done using the Glassfish console and on the machine to which the StockService WSP has been deployed.
  1. From the navigation bar on the left of the Glassfish console, click Configuration > Security > Message Security > SOAP.
  2. Click on the Message Security tab under SOAP.
  3. From the drop down menu, select the providers previously added, FAMServerProvider and FAMClientProvider, as the Default Provider and Default Client Provider, respectively.
  4. Copy /openssowssproviders/resources/AMConfig.properties to the GLASSFISH_INSTALL_DIR/domains/wsp/config directory and update the copied properties file to reflect your environment.

    Refer to AMConfigWSP.properties.
  5. OPTIONAL: Create a GLASSFISH_INSTALL_DIR/addons/accessmanager directory if not already present.
  6. Copy all the JAR files from the /wss_bits/openssowssproviders/lib directory to the GLASSFISH_INSTALL_DIR/addons/accessmanager directory.
  7. Put GLASSFISH_INSTALL_DIR/addons/accessmanager/openssowssproviders.jar and GLASSFISH_INSTALL_DIR/domains/wsp/config in the classpath of the machine on which the WSP is deployed.
  8. To change the logging level, from the navigation bar on the left of the Glassfish console, click Application Server.
  9. Click the Logging tab on the right of the console.
  10. Click the Log Levels tab.
  11. Select FINEST from the drop down list next to Security.
  12. Click Save.
  13. Copy /wss_bits/openssowssproviders/resources/wsit-client.xml and /wss_bits/openssowssproviders/resources/famsts-client.wsdl to GLASSFISH_INSTALL_DIR/domains/wsp/config.
  14. Update GLASSFISH_INSTALL_DIR/domains/wsp/config/famsts-client.wsdl to reflect the actual path to the keystore.jks file.

    Trade out @KEYSTORE_LOCATION@ with the actual value.
  15. Restart the wsp domain using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

    ./asadmin stop-domain wsp
    ./asadmin start-domain wsp

Configuring the Web Service Client (WSC) and the WSP to Use the Security Token Service

These configurations are done using the OpenSSO console.

  1. Log in to the OpenSSO console as the administrator and click through the Configuration > Agents > Web Service Client tabs.
  2. Under Agent, click wsc.
  3. Under Security, select STSSecurity as the Security Mechanism.
  4. For STS Configuration, select SecurityTokenService from the drop down.
  5. Under Signing and Encryption, check the Is Request Signed and Is Response Signature Verified options.
  6. Select the following under Key Store:

    Public Key Alias of Web Service Provider - test
    Private Key Alias - test
    Key Store Usage - Default
  7. Enter the end point of the web service.

    For example, http://sid.opensso.com:9080/StockQuoteService-war/StockService.
  8. Click OK.
  9. Back on the home page of the OpenSSO console, click through Configuration > Agents > Web Service Provider.
  10. This time, under Agent, click wsp.
  11. Under Security, select Anonymous, SAML2-HolderOfKey, SAML2-SenderVouches, and UserName Token as the Security Mechanism.
  12. For STS Configuration, select SecurityTokenService from the drop down.
  13. Under Signing and Encryption, check the Is Response Signed and Is Request Signature Verified options.
  14. Select the following under Key Store:

    Public Key Alias of Web Service Provider - test
    Private Key Alias - test
    Key Store Usage - choose Default and uncheck the box next to the Preserve Security Headers in the Message option.
  15. Click OK.

Configuring the WSC to Use the Security Token Service

Use the StandAloneStockClient sample included with the provider download. Information on deploying this sample can be found in the README located in the samples/glassfish directory of the exploded openssowssproviders.zip.

  1. Put the following JAR files in the classpath of the machine on which the WSC is deployed.

    • appserv-rt.jar
    • j2ee.jar
    • javaee.jar
    • webservices-rt.jar
    • webservices-tools.jar
    • openssoclientsdk.jar
  2. Copy /openssowssproviders/resources/AMConfig.properties to the GLASSFISH_INSTALL_DIR/domains/wsp/config directory and update the copied properties file to reflect your environment.

    Refer to AMConfigWSC.properties. Ensure the values for the following properties are correct.

    • com.iplanet.services.debug.level
    • com.iplanet.services.debug.directory
    • com.sun.identity.agents.app.username
    • com.iplanet.am.service.password
    • com.sun.identity.saml.xmlsig.keystore
    • com.sun.identity.saml.xmlsig.storepass
    • com.sun.identity.saml.xmlsig.keypass
    • com.sun.identity.saml.xmlsig.certalias
    • com.sun.identity.classloader.client.jarsPath
  3. Put the directories containing the following files in the classpath.

    • AMConfig.properties
    • wsit-client.xml
    • famsts-client.wsdl
  4. wsit-client.xml and famsts-client.wsdl are in the /osso_bits/openssowssproviders/resources/ directory.

  5. Update GLASSFISH_INSTALL_DIR/domains/wsp/config/famsts-client.wsdl to reflect the actual path to the keystore.jks file.

    Trade out @KEYSTORE_LOCATION@ with the actual value.

Now all communications between the configured WSP and WSC will be secured by the WSS provider and the Security Token Service. And speaking of tokens, how about The Lion Sleeps Tonight as performed by The Tokens, Pat (the hippo), and Stanley (the dog).

Friday Mar 28, 2008

When Peace Guides the planets.sun.com

You might find it interesting to check out the beta site planets.sun.com. Sun employees create planets (feed aggregators based on keywords, features, or other criteria) and their created collection of blogs.sun.com links can be viewed by clicking the planet name. There is a planet specifically for OpenSSO but you might find other planets that might be useful also.

At this time, non-Sun employees can not create planets but, if you have an idea for one that might be beneficial, let me know and I can create it.

In honor of the planets.sun.com aligning, here's the 5th Dimension singing their huuuuggggeee hit Aquarius/Let the Sunshine In (The Flesh Failures). These two songs are NOT a medley in the Broadway musical Hair for which they were both written - separately. The aggregation was most likely a genius idea from the head of producer Bones Howe.

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