With the latest Identity Server 5.0.0 release WSO2 promotes the product as an “Enterprise Identity Bus” hinting at its flag ship product the “Enterprise Service Bus” (WSO2 ESB). The Identity Server (WSO2 IS), whose strength has always been the entitlement engine with decent XACML support and the availability of thrift interfaces together with WSO2′s 100% open source strategy, might be considered as an identity and access management product by companies and internet communities.
In this article we would like to leverage recent project experience with WSO2 IS to discuss how exactly the identity bus feature of WSO2 looks like and how you could use WSO2 to replace an existing web access management (WAM) product and leverage the recently hyped Social Login feature.
From application centric identity silo to the identity bus: The following diagrams visualize the different architectures for two example applications, SHOP and CRM, with edges simulating authentication proofing relations (e.g user submits his credentials to Application which verifies the credentials of the user).
Let us consider the following scenario and requirements: Company X wants to have single sign on between their in-house web applications, employees use cloud based services and appreciate convenient access to applications like Office365 or Zendesk. The company also wanted to provide controlled access to their own services for customers and they are building a growing internet community, which should attract users with easy registration and login processes powered by social login via Google, Facebook and the like.
Sounds like interesting requirements? That’s not all. The company is a modern and innovative technology firm. In identity tech speak that means that applications offer and use APIs protected by OAuth 2.0. But how can all this requirements be composed to an overall picture?
Breaking up the requirements:
A. Single Sign On for in-house applications: A classical WAM discipline involving policy agents installed into application servers, web servers and/or reverse proxies. These agents act as a policy enforcement point (PEP) which check for authentication, redirect to a central login application for authentication, validate sessions and access policies (authorization).
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.
C. Enable community users to register and sign in with their own social login (Google, Facebook …) to internet accessible in-house applications and probably to cloud services integrated into the community environment (e.g. Zendesk for customer services).
Going with the approach described here, we need to look into the integration details. Adhering to standards might be a good way to reduce efforts and integration pain. In today’s identity world the following protocols need to be considered: SAML the de facto standard for SSO in the enterprise as well as for many cloud services and OpenID Connect, based on OAuth 2.0. The latter becoming more and more prevalent in the consumer/social login context. For API access OAuth 2.0 is the first choice.
We broke up the article into different parts, each describing the solution for one of the requirements. If you like a sneak preview, watch the demo video: