DocTeger

Technical Information

And a Spoonful of Music

To Make the Medicine Go Down

2 for the 4th: SuperPat and Dolly Parton

Where else you gonna see those names together?

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

Posted at 07:27AM Jul 04, 2008 by Michael Teger in Sun  |  Comments[0]

Affiliation-based Federation with...ABBA?

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

Posted at 07:51AM Jul 03, 2008 by Michael Teger in Sun  |  Comments[0]

Federated Access Manager Supported Data Stores and Operations

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

1. Directory Support
2. Supported Identity Data Store Operations
3. Notification Support

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

Posted at 10:52AM Jul 02, 2008 by Michael Teger in Sun  |  Comments[0]

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.

Posted at 11:51AM Jun 26, 2008 by Michael Teger in Sun  |  Comments[2]

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.)

Posted at 07:43AM Jun 25, 2008 by Michael Teger in Sun  |  Comments[0]

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.

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.

<%--
   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>

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.

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.

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.

Posted at 07:55AM Jun 24, 2008 by Michael Teger in Sun  |  Comments[0]

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.

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.

Posted at 06:54AM Jun 23, 2008 by Michael Teger in Sun  |  Comments[2]

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.

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
    

Posted at 08:35AM Jun 17, 2008 by Michael Teger in Sun  |  Comments[2]

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

Posted at 12:00AM Jun 16, 2008 by Michael Teger in Sun  |  Comments[0]

My Most Recent IT Fantasy and ipsec-punchin-interest Reality

I work on a Toshiba Tecra laptop from home. In 2004, Sun Microsystems gave me this machine and onto it loaded their proprietary iWork (now referred to as OpenWork) Client. They also gave me a brand new, shrink-wrapped and all, installation disk (which I put away so I wouldn't lose). I've been happily punching in (using IPsec Punchin VPN) with this computer using the Java Desktop System version of Solaris 10 and a GNOME environment for four years now.

Unexpected failure, Password database unchanged
Permission denied.

Posted at 09:00AM Jun 15, 2008 by Michael Teger in Sun  |  Comments[0]

The Fedlet and U (Part 2): Pre-Built to Last

Previously, I wrote an entry on how to create the Fedlet.zip (to be deployed by a service provider) using the Create Fedlet Common Task in the OpenSSO console on the identity provider side. There is a second option also. A pre-built yet unconfigured Fedlet bundle is packaged in opensso.zip and can also be used to create the Fedlet. A service provider can download opensso.zip, unzip the Fedlet-unconfigured.zip, and follow the instructions to configure and deploy the Fedlet. A sample JavaServer Pages (JSP) is packaged with the Fedlet.war to emulate the service provider's web application, and show how the service provider receives the SAMLv2 POST from the identity provider.

• fedlet.war is a ready-to-deploy web archive (WAR) that contains all the bits needed to enable a service provider to receive SAMLv2 communications.
• conf is a directory containing the following configuration files:
  • FederationConfig.properties
  • fedlet.cot-template
  • idp-extended.xml-template
  • sp-extended.xml-template
  • sp.xml-template

• README is a file that explains how to setup a Fedlet without a pre-configured identity provider and Fedlet metadata, and deploy the resulting WAR.

1. Extract the Fedlet-unconfigued.zip to a temporal directory on the service provider machine.
2. Change to the conf directory.
3. Make copies of the following template files:
   • Copy sp.xml-template to sp.xml.
   • Copy sp-extended.xml-template to sp-extended.xml.
   • Copy idp-extended.xml-template to idp-extended.xml.
   • Copy fedlet.cot-template to fedlet.cot.
4. Swap out the following tags in sp.xml, sp-extended.xml, idp-extended.xml, and fedlet.cot with the appropriate values:
   • FEDLET_ENTITY_ID: replace with the unique identifier used to locate the Fedlet; for example, http://dev6.red.sun.com:8080/fedlet. (The EntityID is an attribute under the EntityDescriptor element that is passed to the identity provider as part of the XML exchange. The Name attribute of the entity provider in the OpenSSO console is the EntityID.
   • FEDLET_PROTOCOL: replace with the protocol of the web container to which the fedlet.war will be deployed; for example, http
   • FEDLET_HOST: replace with the host name of the web container to which the fedlet.war will be deployed; for example, dev6.red.sun.com
   • FEDLET_PORT: replace with the port number on the web container to which the fedlet.war will be deployed; for example, 8080
   • FEDLET_DEPLOY_URI: replace with the deployment URI of the fedlet.war; for example, fedlet
   • IDP_ENTITY_ID: replace with the unique identifier used to locate the remote identity provider; for example, http://dev2.red.sun.com:8080/fam. (The EntityID is an attribute under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of the entity provider in the OpenSSO console is the EntityID
   NOTE: If either of the *_ENTITY_ID values contain % or ,, you need to escape them as follows before replacing in fedlet.cot-template:
   • Change % to %25
   • Change , to %2C
5. Create a home directory for Fedlet on the service provider machine.
   The fedlet directory, any directory that is accessible by the user running the web container, is the location from which the Fedlet reads its metadata, circle of trust, and configuration properties. For example, /fedlet.
   NOTE: To change this default location after it has been configured, 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
   This points the Fedlet to the /export/fedlet/conf directory for configuration data.
6. Copy the configuration files previously modified (sp.xml, sp-extended.xml, idp-extended.xml, and fedlet.cot) to the /fedlet home directory.
7. Copy FederationConfig.properties to the /fedlet home directory.
8. Generate a standard metadata XML file from the identity provider using http://IDP_machine:IDP_port/fam/saml2/jsp/exportmetadata.jsp.
9. Save the metadata as idp.xml and copy it to the /fedlet directory on the service provider machine.
10. Copy the previously modified Fedlet service provider metadata, sp.xml, to the identity provider machine and import the metadata using the OpenSSO console.
11. Add the service provider entity to the same circle of trust that has the identity provider entity as a member using the OpenSSO console.
12. Deploy the fedlet.war into your web container.
13. Launch the Fedlet demo application; for example, SP_PROTOCOL://SP_HOST:SP_PORT/SP_DEPLOY_URI/
14. If the Fedlet configuration was done properly, a page with links to begin Fedlet (SP) Initiated Single Sign-on and Identity Provider Initiated Single Sign-on are displayed.
    
    Click the SP link and you will be redirected to the IDP for login, followed by single sign-on to the Fedlet (SP) demo. Upon successful completion, a JSP will be displayed with links to view the SAMLv2 Response, Assertion and Subject XML.

Posted at 01:25PM Jun 13, 2008 by Michael Teger in Sun  |  Comments[7]

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.

Posted at 08:19PM Jun 12, 2008 by Michael Teger in Sun  |  Comments[0]

Sun, OpenWork, and Don Quichotte

I've been on Sun's OpenWork program for over five years and the press is just now getting wind of the fact that, hey, this is a good idea. Here's a news story on OpenWork and what it does for Sun, me, and you.

Posted at 07:09AM Jun 10, 2008 by Michael Teger in Sun  |  Comments[2]

Undeploying the Fedlet with Some Light from Jens Lekman

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

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

Posted at 10:13AM Jun 09, 2008 by Michael Teger in Sun  |  Comments[2]

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.