Try WSO2 Cloud for Free
Sign in

All docs This doc
Skip to end of metadata
Go to start of metadata

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.

Architecture components

The WSO2 Identity Cloud architecture consist of following key components.

These are explained as follows.

Admin Portal

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 SSODescription
Predefined Applications

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 ApplicationsThis 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 ApplicationsThese 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 ApplicationsProxy-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 TypeThis 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.

User Portal

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.

Identity Provider

The Identity Provider is the key component that handles all security related operations.

Identity Gateway

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.

ProcessDescription 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.

Creating applications

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.

  • Service provider initialized SSO - The client invokes the application URL. The application has the logic to initiate a single sign-on request to the identity provider.
  • Identity provider initialized SSO - The client invokes a URL given by the identity provider instead of the web application URL. So, the identity provider itself initializes the single sign-on request on behalf of the application.
  • Proxy application - The client invokes a proxy URL given by the Identity Gateway instead of a real web application URL. The proxy (gateway) initializes the single sign-on request to the identity provider on behalf of application.

This is depicted in the following section of the architecture.

Figure: Authentication request handling

  • No labels