SSOCircle

The second step: Account federations with cloud services and identity providers run by customers

In the first article we introduced the project requirements to get rid of an application identity silo environment and to introduce an identity hub infrastructure. The second part dealt with building a Single Sign On infrastructure leveraging WSO2 Identity Server and OpenID Connect apache agents. In this blog we describe the approach for requirement B:

B. Account federation to cloud services and to identity providers provided by the companies customers allowing SSO to cloud services like Office365 or the in-house applications.

Interoperating with cloud services and especially with services provided by customers is different from handling in-house applications: You barely have a choice and need to work with what the services offers or the customer wishes. As a result you will need to cope with different standard protocols or derivatives of it. In our scenario we had to integrate mainly leveraging SAML 2.0 with varying details: different attributes exchanged, signed elements, etc – facets SAML 2.0 generously allows.

That point of the story turned out to be quite easy to do. SAML is a well-established protocol and obviously old enough so that involved identity providers and service providers are compatible. The challenge arises if you want to dynamically (just-in-time) provision users into your system or establish dynamic account linking on profile attributes. Fortunately WSO2 IS 5.0.0 introduced flexibility with several configuration options.

Making attributes available via OpenID Connect UserInfo endpoint requires some puzzling with claim mappings but at the end it worked.

Requirement B accomplished. Read part 4 of the story for solving requirement C.