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

Previously, I wrote an entry on how to create the (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 and can also be used to create the Fedlet. A service provider can download, unzip the, 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. is located in the fedlet directory of the When unzipped, contains the following:

  • 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:

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

The fedlet.war contained within does not contain provider metadata and circle of trust information (as does the one created using the Common Tasks wizard). The following procedure explains how to create the Fedlet and configure it with the appropriate metadata and circle of trust information.

How to Create the Fedlet

  1. Extract the 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, (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,
    • 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, (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:


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

Now relax and enjoy the song stylings of Melee with this unabashed pop tune, Built to Last - just like the Fedlet.


I am not able to find this unconfigured fedlet in

Please advice where can i download


Posted by Bhupinder on June 17, 2008 at 12:26 AM PDT #

Unzip and in the /opensso directory it creates there is a subdirectory named Fedlet. Everything is in there. I just downloaded the June 14 periodic build from here and all worked fine:

Posted by DocTeger on June 17, 2008 at 01:01 AM PDT #

Bhupinder, there is no documentation yet for the Fedlet. That's what the three entries (of which this is one) I have written on the Fedlet are for. (Check the left margin for links to them.) I am writing the final entry now - which is why these haven't yet been announced to the list. You're too quick. ;>

Posted by DocTeger on June 17, 2008 at 02:01 AM PDT #

i have configured fedlet to work with opensso as idp... can i configure fedlet to work with any other saml2 compliant IDP ?
like shibboleth etc.. are there any special clauses to be taken care ?

Posted by bhupinder on June 26, 2008 at 07:24 PM PDT #

The Fedlet should work with any SAMLv2 compliant IDP. Be aware though that it only supports a subset of the SAMLv2 profiles.

Posted by DocTeger on June 27, 2008 at 06:17 AM PDT #

getting error for pre-configured fedlet deployment created using opensso common-task on centos 5.1 and tomcat 5.5.17 saying missing resourcebundle amUtilMsgs and fedlet jsp are not able to compile. Can you give some pointer whats wrong ? While same setup works properly on windows vista and tomcat 5.5.17

Posted by bhupinder on June 29, 2008 at 07:56 PM PDT #

I did not use Tomcat so I can't answer to the errors that you are receiving. You can send your question to the alias and see if anyone there has had this issue.

Posted by DocTeger on June 29, 2008 at 10:51 PM PDT #

Is the Fedlet supposed to work with a NameID in urn:oasis:names:tc:SAML:2.0:nameid-format:persistent format?

I have embedded Fedlet into an existing J2EE application. It appears that the Fedlet refuses to work when an identity provider (in my case, it is OpenSSO) returns NameID in urn:oasis:names:tc:SAML:2.0:nameid-format:persistent format. In this case, I get an error message stating that Single Sing-On Failed.

I have configured the service provider's configuration files to use urn:oasis:names:tc:SAML:2.0:nameid-format:persistent format, updated the service provider's configuration in OpenSSO, and modified the index.jsp file to request a name id in the persistent format. The log file (SAML2.access) shows that the IdP has sent a name id in the persistent format. But, the index.jsp still fails:
<< map = SPACSUtils.processResponseForFedlet(request, response); >> throws SAML2Exception.

Any help will be appreciated. Thank you.

Posted by alexeip on January 16, 2009 at 08:26 AM PST #

Yes, it supposed to work with all Name-id formats. But the Pre-Built Fedlet only handles one case for Name-Id i.e. urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Try configure IDP & fedlet work for transient Format. It should work, also you can configure Attributes such as email or name etc to be passed b/w IDP & fedlet.

If any other Name-ID format support is required from fedlet, then modify to handle other formats and built your own fedlet from opensso source. Error in fedlet logs suggest that assertion is not processed for persistent format.

I hope that will work for you.

Posted by bhupinder Saini on January 17, 2009 at 06:19 AM PST #

Thanks for the help, Bhupinder. Also be aware that persistent name identifiers require a data store on the SP end. Did you look at autofederation?

If you have additional questions or maybe a more specific use case, Alex, email You're question has gotten the team talking. ; >

Posted by DocTeger on January 20, 2009 at 12:40 AM PST #

I implemented customised to handle
unspecified NameId format. Along with Certificate Encryption and Signing for Assertion which current Fedlet don't support. Didn't check Auto-Federation
as my Use Case was simple. I integrated custom fedlet on Tomcat/Centos 5.0 platform with RSA FIM server[IDP].

Posted by bhupinder on January 20, 2009 at 12:54 AM PST #

I am getting these 2 error

1)ERROR: Error sending AuthnRequest
com.sun.identity.saml2.common.SAML2Exception: Identity provider does not support name identifier format urn:oasis:names:tc:SAML:2.0:nameid-format:transient.
2) ERROR: mapPk2Cert.JKSKeyProvider:

keystore.jks (The system cannot find the file specified)
at Method)

How do i fix these


Posted by jaya saluja on March 25, 2009 at 04:29 AM PDT #

Jaya, you should send this question to the alias. If you are not on the alias you can join at the opensso web site, or be sure to mention reply all in your query. hth.

Posted by DocTeger on March 25, 2009 at 05:03 AM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016