Wednesday Nov 11, 2009

A Wonderful Use of Fedlet with Access Manager 7.1

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

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

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

Wednesday Jul 29, 2009

OpenSSO ASP.NET Fedlet, Multiple Identity Providers and An Angel's Kiss in Spring

I was reading the latest scoop on The Whalpin Chronicles when I found a comment from someone requesting information on how to configure the ASP.NET Fedlet with multiple identity providers. Sure there's a README now but in a week or so this will be official. As Whalpin said, check out the nightly.

This procedure can be followed to enable the ASP.NET Fedlet to communicate with multiple identity providers. It assumes that you have already followed the instructions in Using the ASP.NET Fedlet with OpenSSO Enterprise 8.0 Update 1 to configure and test the ASP.NET Fedlet with an initial identity provider.
  1. Get the standard metadata file for the new identity provider and name it idp2.xml.
    If using OpenSSO, create the identity provider using the Common Tasks work flow and export the identity provider's standard metadata by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp.
  2. Copy idp2.xml to the directory created during initial configuration of the ASP.NET Fedlet.
    During initial configuration, move the /SampleApp directory from the Fedlet-unconfigured.zip file to a directory outside of the decompressed archive. For this article, we will use /tmp/asp.net/SampleApp/App_Data/. See Using the ASP.NET Fedlet with OpenSSO Enterprise 8.0 Update 1 for more information.
  3. Add the identity provider to the appropriate circle of trust by modifying the Fedlet's .COT file.
    1. To add to an existing circle of trust, append the entity ID of the new identity provider (specified by the entityID attribute in the idp2.xml metadata) to the value of the sun-fm-trusted-providers attribute in the appropriate .COT file (for example, fedlet.cot) within the /tmp/asp.net/SampleApp/App_Data/ directory.
      Use a comma (,) as the separator.
    2. To add to a new circle of trust follow this procedure.
      1. Create a new .COT file named (for example, fedlet2.cot) using the existing fedlet.cot as a template.
      2. Change the value of the cot-name attribute in the new .COT file to the name of the new circle of trust.
      3. Add both the new identity provider entity ID and the Fedlet entity ID as the value for the sun-fm-trusted-providers attribute in the new .COT file.
        Use a comma (,) as the separator.
      4. Put fedlet2.cot in the /tmp/asp.net/SampleApp/App_Data/ directory.
      5. Add the new circle of trust name to the value of the cotlist attribute in the ASP.NET Fedlet/service provider extended metadata file, sp-extended.xml.
        For example:
        <Attribute name="cotlist">
        <Value>saml2cot</Value>
        <Value>cot2</Value>
        </Attribute>
        sp-extended.xml is in the /tmp/asp.net/SampleApp/App_Data/ directory.
  4. Create a new file named (for example, idp2-extended.xml) to define the extended metadata for the new identity provider using the existing idp-extended.xml as a template.
    1. Change the value of the entityID attribute to the entityID of the new identity provider.
    2. IF APPLICABLE, change the value of the cotlist attribute to the name of the new circle of trust.
    3. IF APPLICABLE, change the setting of the hosted attribute in the EntityConfig element to false to define it as a remote identity provider.
  5. Send the ASP.NET Fedlet/service provider standard metadata (for example, sp.xml) found in the /tmp/asp.net/SampleApp/App_Data/ folder to the second identity provider.
  6. Import the ASP.NET Fedlet/service provider standard metadata to the appropriate circle of trust on the identity provider side.
    If using OpenSSO, use Register Remote Service Provider under the Common Tasks tab.
  7. Repeat these steps for any number of identity providers using the circle of trust and file-naming formats as discussed.
  8. Using the Internet Information Services (IIS) Manager, restart the Application Pool associated with the ASP.NET application.
    Each ASP.NET web application hosted on IIS is associated with an Application Pool that controls the application's runtime behavior (for example, session properties, memory allocation and garbage collection).
If you use the Sample Application return to the default page for a list of identity providers from which to choose. See To Configure the Sample Application and Test the ASP.NET Fedlet.

Now relax with a glass of Summer Wine as made by Nancy Sinatra and Lee Hazlewood. Strawberries, cherries, and an...oh, you know the rest.

Friday May 08, 2009

An ASP.NET OpenSSO Fedlet? Sign of the Times

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

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

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

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

To Configure the Identity Provider

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

    You will need the name of the circle of trust in To Configure the Service Provider and the ASP.NET Fedlet.
  2. Export the identity provider's standard metadata file.

    idp.xml can be exported by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp
  3. Register the remote service provider using the modified standard metadata file sp.xml and the Register Remote Service Provider work flow in the OpenSSO Enterprise console.

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

To Configure the Service Provider and the ASP.NET Fedlet

  1. Download the OpenSSO Enterprise ZIP archive to the service provider machine and unzip it.
  2. Unzip the Fedlet-unconfigured.zip in the /opensso/fedlet/ folder.
  3. Move the /opensso/fedlet/asp.net/ folder to a temporary directory.
  4. Change to the /tmp/asp.net/conf directory.
  5. Make copies of the template files.
    • Copy sp.xml-template to sp.xml.
    • Copy sp-extended.xml-template to sp-extended.xml.
    • Copy idp-extended.xml-template to idp-extended.xml.
    • Copy fedlet.cot-template to fedlet.cot.

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

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

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

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

  1. Navigate to the /tmp/asp.net/conf folder on the service provider machine.
  2. Copy the modified metadata files idp-extended.xml, sp.xml, sp-extended.xml, and fedlet.cot) to /tmp/asp.net/SampleApp/App_Data/.
  3. Copy the remote identity provider's standard metadata file to the service provider machine.

    Be sure the file is named idp.xml.
  4. Place idp.xml in /tmp/asp.net/SampleApp/App_Data/.
  5. Confirm that the Fedlet.dll is in the Sample Application's /tmp/asp.net/SampleApp/bin/ folder.
  6. Within Internet Information Server (IIS), create a virtual directory using the /tmp/asp.net/SampleApp/ directory.

    • IIS 6 (Windows 2003) has Add Virtual Directory. Be sure to have Read and Script permissions set for the application.
    • IIS 7 (Windows 2008 and Vista) has Add Application with no additional options required to be set.
  7. Open the Sample Application in your browser using the URL, http://sp-machine.domain/SampleApp
  8. Click the IDP Initiated SSO link to perform identity provider-initiated single sign-on.
  9. Enter the appropriate user credentials.

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

To Integrate the ASP.NET Fedlet with an Existing Application

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

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

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

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

Tuesday Mar 17, 2009

Don't Ask Me Why XML Signing and Encryption in a Fedlet is Not Here

This is the first blog entry in which I will be using links to articles I've posted on wikis.sun.com. Moving forward the OpenSSO writers are going to be collecting documentation, articles and the like over there. I will though continue to blog these links because I know there must be one or two of you out there who would miss the music lessons.

The first article I've published is titled Enabling XML Signing and Encryption in a Fedlet and explains the titular procedure.

The first musical interlude in this new way of working is Don't Ask Me Why performed by Eurythmics. From 1980 through 1991 I saw Eurythmics in concert five times and there was not a bad performance in the bunch. Live vicariously now through this live version.

Tuesday Jan 20, 2009

Fedlet or Policy Agent? AND BARACK!

Rajeev Angal wrote an interesting answer in an email when asked the question What is the advantage of using the Fedlet versus installing a policy agent on the partner website? I thought the information was worth double-dipping.

A Fedlet allows you to:
  • Use SAMLv2 standards to accomplish single sign-on - keeping the partner domains separate.
  • Add privacy and security characteristics to the deployment involving loose coupling between the partner domains.
  • Integrate with an existing application that already has session management.

A policy agent is a better option if:
  • The two domains are owned by the same business.
  • You want session and related services (user profile, configuration etc) to be accessible from the partner domain.
  • Access between the agent in one domain and the OpenSSO server on the other is secure.
NOTE: If you also have the option to install an instance of OpenSSO in the partner domain, the two servers connect using SAMLv2 (just like the Fedlet/OpenSSO case) except that the domain can make full use of the session and other facilities (isolated from OpenSSO in the other domain) although at the cost of a slightly more complex deployment at the partner end.

Today, in honor of the 56th Presidential inauguration and the ascension of Barack Obama and Joseph Biden to the offices of President and Vice President respectively, here is a music video I created during the campaign. The song is A Change in the Wind and is sung by Face to Face. The images speak for themselves.

Tuesday Dec 02, 2008

Fedlet Logging and Loggins' Footloose

The Fedlet is a small footprint SAMLv2 JAR that can be deployed with a service provider application. It handles only SAMLv2 identity provider initiated POST profiles. The application in which it is embedded can then consume a SAML assertion to identify the user and identity attributes. The Fedlet uses your installed JDK to log its authentication access and errors (single sign-on successes, single log outs, etc.). By default, it uses the configuration defined at JAVA_HOME/jre/lib/logging.properties. You can set the logging level to FINEST to see more details. For additional logging information, you can modify fedletSampleApp.jsp. More information on that modification can be found here. For debugging, the location of the file is defined in the OpenSSO file, FederationConfig.properties.

And when done logging, check out Kenny Loggins singing (and Kevin Bacon foot-syncing) in the music video for Footloose.

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.

Monday Jun 09, 2008

Undeploying the Fedlet with Some Light from Jens Lekman

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

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

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

Friday Jun 06, 2008

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

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

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

Identity Provider-initiated SSO

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

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

Service Provider-initiated SSO

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

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

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

Creating a Fedlet with the Common Tasks Wizard

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

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

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

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

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

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

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

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