The previous talks about basic concepts of fedlet and deployment architecture. In this post I would like to explain the use cases for implementing the fedlet. See the below list where I have expanded the pros for using fedlet.

  • Use fedlet when the service provider is a small organization and has limited set of applications.
  • Use fedlet when the service provider wants a minimal cost federation solution.
  • Use fedlet when the organization does not want to install a full pledged federation solution to avoid hardware cost, maintenance cost and human effort etc.,
  • Use feldet when organizations needs to develop a federation solution in short span.
  • Use fedlet when Identity Provider sends some attributes and Service Provider want to just display the attributes.

Let’s discuss the basic use case for fedlet:

Consider a SmartPhone, a telecom giant has Identity Provider as OIF/Tivoli Federation. Subscribers of Smartphone Telecom use a custom user portal to receive personalized content, which is delivered by business partners of SmartPhones Telecom: StockService.com and Weather.com.

StockService.com and Weather.com has federation already in place. A new partner Oncast.com is engaged with SmartPhone company for delivering services say caller tunes. Oncast.com does not have a federation product in place and they can leverage fedlet as another Service Provider. Oncast.com needs to do following things to setup federation:

  • Fetch the identity provider metadata from SmartPhone company.
  • Unpack the fedlet package.
  • Provide the service provider metadata to SmartPhone.
  • Load the identity provider metadata in Oncast.com.
  • Embed the fedlet application in Oncast.com application/
  • Deploy and test.

Fedlet is available in both Java/.Net technologies.