I would like to provide some insight into Fedlet in today’s post. I will cover the following fedlet related topics in the near future.

  • Fedlet use cases
  • Setup
  • Signing the SAML response
  • Signing the SAML assertion
  • Encrypting the SAML assertion
  • Logout

To understand the federation concepts such as Identity Provider, Service Provider, Circle of Trust etc., check this post.

What is a Fedlet?

Oracle OpenSSO Fedlet (Fedlet) is a compact, easy to deploy SAMLv2 Service Provider implementation. It includes a small software package and a simple file-based configuration, embeddable into a Service Provider’s Java EE or .NET application.

Where does other vendor federation product defeats Fedlet?

The other vendor federation products such as Tivoli, Oracle etc., defeats Fedlet on some features which is eventually turned out to be tradeoffs for Fedlet and here they are:

  • Fedlet does not support session management at SP end. Therefore the application where fedlet is deployed is responsible for session management.
  • Fedlet supports only SAML 2.0 but not other protocols such as Liberty ID-FF, WS-Federation and SAML 1.x.
  • Fedlet does not support Account Linking, Advanced Attribute mapping, logging, reporting etc.,

What are the key features covered in Fedlet?

Deployment Architecture:

Fedlet typically is deployed as a Service Provider in common scenarios. Each service provider requires a fedlet instance. Fedlet acting as service provider can communicate with Single IDP or multiple identity providers. A simple diagram is provided in below screenshot where Fedlet communicates with multiple identity providers.

Fedlet can be deployed in 3 ways:

  1. Fedlet application can be embedded into existing Service Provider Application.
  2. Service Provider application can be embedded into fedlet.
  3. Fedlet and Service Provider applications can be isolated.