WSO2 Identity Cloud is deployed on top of WSO2 Identity Server. The following diagram depicts the overall architecture of WSO2 Identity Cloud.
Figure: WSO2 Identity Cloud architecture
The following sections expand on the above architecture diagram.
The WSO2 Identity Cloud architecture consist of following key components.
These are explained as follows.
The Admin Portal is the place where organization admins can log in and configure security and single sign-on for their applications with authentication standards, such as SAML, OpenID Connect, and WS-Federation. Applications configured here get listed in User Portal, so that other users in the organization can discover the applications. In addition to configuring security for applications, admin portal allows to define which users can view which applications in User Portal depending on the user roles. There are multiple options provided in simplified UI to configure security for applications depending on your application nature and how you want to handle security. Following are the list of options provided to configure SSO.
|Option to configure SSO||Description|
The WSO2 Identity Cloud has a selected set of popular cloud applications and has identified the minimum configurations that a user must provide to configure SSO for these applications. The configurations differ from application to application depending on the service provider. This is done to simplify the process for users so that they need to provide only the minimum configurations necessary.
Currently, the Identity Cloud has identified and supports Salesforce, Concur, AWS, NetSuite, Zuora, and GotoMeeting applications as predefined applications. This list will keep growing in future. If you can see the application that you are going to configure SSO for under the predefined application list, it makes the process easier for you to select the application from there and provide the required configuration details. If the application that you are trying to configure is not listed in predefined application list, you can configure it as a "Custom Application".
|Custom Applications||This option can be used when the application that you need to configure is not listed in the predefined applications list or if there are any additional configurations that you need to do other than the minimum set of configurations provided in the predefined applications. Custom applications are divided into three types based on how SSO is handled in the application. These are listed out in the following sections of this table.|
|Agent Type Applications||These applications must handle the SSO logic. For example, when an application initiates SSO (using a SAML request) and processes the SAML response sent by the identity provider.|
|Proxy Type Applications||Proxy-type applications do not need to handle the SSO logic. There is a central gateway provided that acts as a proxy for the application, handles SSO requests/responses on behalf of the application, and sends a signed JWT token to the application where it can process it and identify the authenticated user.|
|Shortcut Type||This is the only application listing in the user portal. This type can be used when you have websites or applications having their own authentication. However, these applications must be listed in a central place along with all the other applications.|
The User Portal provides a central location for the users of an organization to log in and discover applications in a central place, while applications can be accessed with single sign-on.
The Identity Provider is the key component that handles all security related operations.
The Identity Gateway is a runtime, backend component developed using the WSO2 ESB. The Identity Gateway is a simple application proxy that intercepts application requests and applies policies such as throttling and security checks.
User Store Agent
The User Store Agent is a microservice developed with WSO2 MSF4J to connect the on-premise LDAP of an organization to the WSO2 Identity Cloud. This allows organizations to provide access to applications with single sign-on, provided that their credentials are stored in the organization's LDAP. This can be done without sharing the credentials of LDAP with the WSO2 Identity Cloud.
Architecture and the business scenario of the Identity Cloud
The following table expands on the business scenario of the WSO2 Identity Cloud and how this involves the architecture.
|Process||Description of how this works from an architectural perspective|
|Configuring on-premise user store|
The User Store Agent must be downloaded to an on-premise location and configured to connect to your local LDAP server. This is represented by the following section of the architecture diagram.
Figure: On-premise User Store Agent and LDAP server
The identities of the users are stored in the LDAP and these credentials are used to access the WSO2 Identity Cloud and the various other applications that the user needs to interact with.
In the architecture diagram, the integral part of the flow involves the admin user creating applications in the Admin Portal. These are saved into the database in the WSO2 Identity Cloud.
Figure: Admin user creating apps using the Admin Portal in the Identity Cloud
These can be any custom application or a common SaaS application. The Identity Cloud can support applications that use SAML 2.0, OpenID Connect, and WS-Federation protocols.
|Accessing applications using SSO|
The user can access the applications created in the Admin Portal through the User Portal, which obtains the configured application list from the database. More significantly, the users can access these applications in a single sign-on manner.
Figure: User views the applications in the User Portal and accesses them using SSO
|Authentication request handling|
The WSO2 Identity Cloud is able to handle different authentication requests.
There are three possible ways an authentication request can come to the identity provider from the client.
This is depicted in the following section of the architecture.
Figure: Authentication request handling