The Fedlet and U (Part 1) and Winky Dink and Me
By docteger on Jun 06, 2008
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.zipfile 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.warcan 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.zipbundle (that will consist of the
Fedlet.warand a README file with instructions on deploying the Fedlet). The
Fedlet.warwould 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.
- Login to the OpenSSO Console on the IDP side.
- Navigate through the Access Control - > top-level realm -> Subjects tabs to access the profile of the demo, a default user created during OpenSSO deployment.
- Add values to the Email and Employee Number attributes of the demo user profile.
- Click Save and navigate back to the Common Tasks tab.
- Click Create Fedlet.
- Add the following URL to the Name and Destination URL attributes:
- On the same screen, under Attribute Mapping, add the following mappings:
employeenumber | employeenumber
mail | mail
- 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.
- Send the created
Fedlet.zipto the SP machine.
Fedlet.zipon the SP machine.
- Login to your web container and deploy the
- Go to
The following screen is displayed.
- Click the link to create the
After the directory is created, the following screen is displayed.
- Click Run Fedlet (SP) Initiated Single Sign-on to validate the first Fedlet setup.
You will be redirected to the IDP login screen.
- 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.
- Go back to
http://fqdn-of-SP-machine:port/fedlet/index.jspand 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.
fedlet-unconfigured.zipwith 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.