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.