Sidharth's blog

Paul wasn't quite convinced, of the power of Fedlet, as I mentioned in my previous post, I thought. Pat weighed in and as Paul clarified later, it was all to do with a missing punctuation in his post.

Here's some more details on the options that SP has in procuring and deploying the Fedlet (and I mentioned this briefly as part of a screencast few days back). There are two ways a Fedlet can be procured and deployed by a Service Provider, in order to be quickly SAML enabled.

I - IDP Workflow generated Fedlet

1. IDP installs and configures FAM / OpenSSO.
2. IDP follows a simple set of FAM workflows to create Fedlet.zip for the Service Provider. The Fedlet.zip contains

• fedlet.war - A ready to deploy war file, for use by SP.
• A README file - A text file with instructions on how the SP can integrate a Fedlet with an existing application.

3. IDP sends the generated zip file (fedlet.zip) to the SP.
4. SP deploys the war file. 5. SP tests the Fedlet deployment by accessing the index.jsp for the two common scenarios

• IDP initiated SSO.
• Fedlet/SP initiated SSO.

(And yes, the SP can edit the metadata in this case to federate with another IDP. However, SP also has the following option - i.e. of using the Pre-packaged Fedlet, available as part of the FAM/OpenSSO distribution in order to do so.)

II - The Pre-built Fedlet

1. SP downloads/procures the unconfigured/pre-built fedlet zip(Fedlet-unconfigured.zip) file via OpenSSO/FAM, which has the following;

• fedlet.war - Fedlet war file.
• conf -  A directory with metadata templates, Circle Of Trust (COT) templates and configuration files.
• README - A file that shows use of conf files with configuration info for setting up the Fedlet.

2. SP edits the conf  files, as appropriate(values for metadata).
3. SP sends it's metadata details to the IDP and requests for IDP metadata info. 4. Tests the deployment for the 2 scenarios

• IDP initiated SSO
• Fedlet initiated SSO

Tags: OpenSSO, FAM, Fedlet