Wednesday, November 27, 2013

Chained Collaborative Federation (CCF) with WSO2 Identity Server

Chained Collaborative Federation (CCF) pattern implemented with WSO2 Identity Server provides following features/benefits.

1. Build a single sign-on solution across multiple web applications supporting heterogenous standards/protocols.

You may have a Liferay portal which supports OpenID based login, a Drupal server which requires SAML 2 Web SSO, a web application which relies on OpenID Connect. With WSO2 Identity Server,  all these heterogenous standards/protocols can be integrated together to build a unified SSO platform. Once you login to Liferay with OpenID, you will not require to re-authenticate when accessing Drupal or the web application. This can be further extended to build a unified SSO platform between on-premise and SaaS applications (GoogleApps, Salesforce).

2. Collaborative identity federation between multiple heterogenous identity providers.

I have a web application that only supports OpenID based login. To enable users from partner companies, out side my domain, to access this - they have to use an OpenID. In other words, each partner company should have an OpenID Provider deployed over their respective enterprise user store. In a realistic scenario, this is not a perfectly valid requirement. We can't expect all our partners to have an OpenID Provider, deployed in their respective domain. One may have an OpenID Provider, another may have a SAML2 IdP, and a CAS server, an OpenID Connect authorization server.. likewise..

With CCF pattern, WSO2 Identity Server provides a platform to integrate all these heterogenous identity providers.

The web application that supports OpenID login, can redirect any unauthenticated users to the WSO2 Identity Server via OpenID Directed Identity. Then Identity Server will give the user an option to pick the Identity Provider he wants to authenticate against. This identity provider may support SAML, OpenID, OpenID Connect, CAS or even a proprietary protocol. The Identity Server will take care of bridging the requested protocol (OpenID in this case) with the user selected one and initiate the flow. User will be redirected to his own Identity Provider and comes back to the Identity Server with the response. Identity Server will then build an OpenID response from it and send back to the web application.

Currently Identity Server can integrate clients and identity providers, who support OpenID, OpenID Connect, OAuth, SAML2 and WS - Federation (Passive). We are planning to add support for CAS in the future.

Some of the benefits of this approach.
  • Client application only needs to trust its own Identity Provider - not aware of any external Identity Providers.
  • Authentication protocol at the client side is completely decoupled from the Identity Provider. Each entity can select its own, independantly
  • The trust relationships between connected partners are maintained centrally.
3 . Home realm discovery.

In previous case, when an external user being redirected to the internal IdP (Identity Server) - he has to pick his Identity Provider from there. With the support for home realm discovery - Identity Server is capable of deriving user's home IdP from the request. So - the complete redirection flow will be transparent to the end user.

4 . Integrated Windows Authentication (IWA).

WSO2 Identity Server supports IWA. With this, we can faciliate Zero-login for your web applications that rely on OpenID, SAML, OpenID Connect and WS - Federation (Passive).

5 comments:

Unknown said...
This comment has been removed by the author.
Unknown said...
This comment has been removed by the author.
Unknown said...

Hi Prabath!

Nice blog post. When you say CAS support is planned for the future, do you have any insight into how soon or the targeted version # for such capabilities? I would love to extend our SSO capabilities internationally but not limit our service providers to just our CAS services.

Will this further pursuit of Chained Collaborative Federation also further extend on your multiple userstore capabilities in your various applications, including API Manager? I for one am looking for a solution that lets me assign roles to Service Providers (e.g. users in RoleA+RoleB can login to SP1, users in RoleC can login to SP2, and only RoleB can login to SP3). Do-able?

Say hi to Azeez and the crew for me =]

Cheers,
Damian

Ismail Seyfi said...

Where I can find more about "Home Realm Discovery" do you know? I can't seem to find any information in the official documents.

chenmeinv0 said...

ugg boots
canada goose online
moncler jackets
rolex watches clearance
giuseppe zanotti sneakers
canada goose jackets
ugg outlet online
coach factory outlet
steelers jerseys
timberland boots outlet
2016.12.27xukaimin