Architecture

A Service Provider (SP) is an entity that provides Web services. A service provider relies on a trusted Identity Provider (IdP) for authentication and authorization. In this case, the Identity Server acts as the IdP and does the task of authenticating and authorizing the user of the service provider.

Salesforce and Google Apps are examples of service providers and are used as such in this case.

A user of the service provider attempts to log into the SPs application. The service provider sends an authentication request to the Identity Server. This request is met by the Inbound Authentication component of the Identity Server and comes in one of the following forms.

• SAML SSO
• OAuth/OpenID Connect
• Passive STS
• OpenID

The service provider receives the authentication confirmation from the Identity Server once it follows all the specified processes required in order to authenticate the SP's user.

Additionally, if a user registers in the service provider's application, a SOAP or SCIM request can be sent to the Identity Server. The request is met by the Inbound Provisioning component of the Identity Server.

The Inbound Authentication component of the Identity Server can handle any of the following requests.

• SAML SSO: Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identity and authentication data between parties. SAML provides the web-based Single-Sign-On capability. 
• OAuth/OpenID Connect: OAuth 2.0 has three main phases. They are; requesting an Authorization Grant, exchanging the Authorization Grant for an Access Token and accessing the resources using this Access Token. OpenID Connect is another identity layer on top of OAuth 2.0. OAuth applications can get authentication event information over the IDToken and can get the extra claims of the authenticated user from the OpenID Connect UserInfo endpoint.
• Passive STS: A Security Token Service (STS) is a software based identity provider responsible for issuing security tokens, especially software tokens, as part of a claims-based identity system.
• OpenID: OpenID is a URL or an XRI issued by an OpenID Provider. This OpenID Provider also maintains a user profile and this OpenID is used as a means of authentication.

The inbound authentication component of the Identity Server receives the authentication request from the service provider. You can configure the Identity Server to receive either SAML SSO, OAuth/OpenID Connect, Passive STS or OpenID requests. Your configuration depends on the service provider in question.

Once the conditions are met in the inbound authentication component, the request is sent on to the authentication framework.

Once the request is acted upon, a response from the OUT channel of the authentication framework is received by the inbound authentication component.

This response is sent back to the service provider.

Claim management is a key aspect of the Identity Server, which helps to map local claims to service provider claims and vise versa. It also enables you to map local claims to identity provider claims and vise versa.

Just-in-Time provisioning allows you to create users on the fly without having to create user accounts in advance. For example, if you recently added a user to your application, you don't need to manually create the user in the Identity Server. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort related to creating the account. Just-in-Time provisioning works with your identity provider to pass the correct user information to the Identity Server.

The inbound authentication component sends the authentication request to the IN channel of the authentication framework.

Here claim mapping is checked based on the configurations. Once this is done, the authentication request is sent onwards to either the local authenticators, the federated authenticators or both.

Once the authentication is complete, a response is sent from the local and/or federated authenticators to the OUT channel of the authentication framework.

The JIT provisioning component within the authentication framework will send this on to the provisioning framework.

Once the request is acted upon, a response is sent from the OUT channel of the authentication framework back to the inbound authentication.

Local authenticators are authentication processes available within the Identity Server itself. The Username/Password authentication happens by authenticating the credentials entered against the values in the user store connected to the Identity Server.

The IN channel of the authentication framework sends the authentication request to the local authenticators component.

The local authenticator does the authentication by checking the username and password or by using Windows-based authentication (IWA). Once this is authentication is done, it provides the authentication response to the OUT channel of the authentication framework.

Federated authenticators are authentication processes that are not available within the Identity Server. These need to be configured to reach out to external applications to do the authentication process and send the response back to the Identity Server.

The IN channel of the authentication framework sends the authentication request to the federated authenticators component.

The federated authenticators do the authentication by checking the authentication request in the specified authenticator. For example, if Facebook is configured, the authentication process will reflect that. Once this authentication is done, it provides the authentication response to the OUT channel of the authentication framework.

Currently, the Identity Server only supports the following external applications.

• OpenID
• SAML2 Web SSO
• OAuth2/OpenID Connect
• Passive STS
• Facebook
• Yahoo
• Google
• Microsoft (Hotmail, MSN, Live)

In the case of OpenID, SAML2 Web SSO, OAuth2, OpenID Connect and Passive STS; these are not standalone applications but rather applications that use these features for their authentication purposes. Hence configurations need to be done at the external application's side as well to receive authentication requests from the Identity Server. These applications are known as identity providers who perform the authentication.

The authentication request comes in from the federated authenticators component and is distributed to the relevant external application. The user is authenticated and logged in to the external application in question.

A single authentication request can require authentication from multiple external applications.

The provisioning framework is responsible for all provisioning work done by the Identity Server. This framework integrates with the User Store Manager component and also receives provisioning requests from the authentication framework.

The JIT provisioning component of the OUT channel in the authentication framework sends on the request to the provisioning framework. This occurs if the user is not added into the user store and needs to be added in on-the-fly.

The provisioning framework sends the user details to the user store manager and the user is added. Once the user is added, the user store manager contacts the provisioning framework with the response.

The SCIM and SOAP requests that arrive from the service provider are added to the user store manager. This information is also sent on the the provisioning framework. The provisioning framework send this along to the outbound provisioning component.

WSO2 Identity Server contains an advanced entitlement auditing and management. It provides entitlement management for any REST or SOAP calls. WSO2 Identity Server provides attribute and claim-based access control via XACML, WS-Trust, OpenID, OpenID Connect and claim management. WSO2 Identity Server also provides role-based access control (RBAC) and fine-grained policy-based access control via XACML.

WSO2 Identity Server provides a friendly user interface for policy editing. It also supports multiple Policy Information Point (PIP) and policy distribution to various Policy Decision Points (PDPs). It provides a high performance network protocol (over Thrift) for PEP/PDP interaction, and policy decision and attribute caching. Notifications are provided for policy updates. Moreover, the WSO2 Carbon TryIt tool that comes bundled with the Identity Server lets the user explore the policy impact.

The identity provider and service provider configurations provide the basis for all actions that happen within the authentication framework and provisioning framework.

The identity provider and service provider configurations go to both the authentication framework and provisioning framework.

Inbound provisioning requests can come in the form of SCIM or SOAP.

The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in the WSO2 Identity Server easier. Identity provisioning is a key aspect of any Identity Management Solution. In simple terms, it is to create, maintain and delete user accounts and related identities in one or more systems or applications in response to business processes which are initiated either by humans directly or by automated tasks.

Simple Object Access Protocol (SOAP) is a protocol for exchanging XML-based messages over a network, normally using HTTP. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on. SOAP services are defined using Web Services Definition Language (WSDL) and are accessible using a URL that is known as a SOAP endpoint. Here, a SOAP API is used to provision users to the Identity Server.

The SCIM or SOAP request comes into the inbound provisioning component from the service provider.

The inbound provisioning component receives this request, processes it based on the configurations and sends the request on to the user store manager.

WSO2 Identity Server implements flexible user store via built-in LDAP (powered by ApacheDS), external LDAP, Microsoft Active Directory or any JDBC database. It provides an API for integrating identity management to any application. WSO2 Identity Server allows tenants/organizations to configure their user stores through the admin console. WSO2 Identity Server supports multiple profiles per user using its flexible profile management feature.

The user store manager receives provisioning requests from the provisioning framework. These provisioning requests are handled and the relevant user store is updated. The request can affect multiple user stores if the configuration is such. Once this request has been handled, an update is sent back to the provisioning framework.

The inbound provisioning component sends SCIM and SOAP provisioning requests on to the user store manager.

The user store manager receives the provisioning request, acts on it and sends it on to the provisioning framework where it has to be sent on for outbound provisioning.

A claim is a piece of information about a particular subject. It can be anything that the subject is owned by or associated with, such as name, group, preferences, etc. A claim provides a single and general notion to define the identity information related to the subject. Claim-based identity is a common way for any application to acquire the identity information. It provides a consistent approach for all applications by hiding the lower level implementation. Claims are also used in identity propagation, by packaging the claims into one or more tokens (such as SAML). These tokens are then issued by an issuer; commonly known as a security token service (STS).

Claim management does not play a direct role in the process flow but as a component, it integrates with various other components in the Identity Server. Primarily, it integrates with the following four components.

• Authentication framework
• Authorization manager
• Provisioning framework
• User store manager

XACML is ideally a part of the authorization manager component but it is depicted separately due to its unique role in the Identity Server architecture. XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. XACML is popular as a fine grain authorization method among the community. However, there are aspects of XACML that enable it to surpass being just a fine grain authorization mechanism. XACML describes access control policy language, request/response language and reference architecture. The policy language is used to express access control policies (who can do what when). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries(responses).

WSO2 Identity Server provides a comprehensive management console with enterprise-level security. It also comes with a built-in collection and monitoring of standard access and performance statistics. Operational audit and KPI monitoring and management is achieved by integrating with the WSO2 Business Activity Monitor. Further key metrics monitoring and management is achieved with JMX MBeans. WSO2 Identity Server offers a flexible logging support with integration to enterprise logging systems. WSO2 provides a centralized configuration management across different deployment environments with lifecycles and versioning, with integration to WSO2 Governance Registry.

Auditing does not play a direct role in the process flow but as a component, it integrates with various other components in the Identity Server. IS can be configured to produce audit logs for all of its components but the following components are most commonly used for logging details.

• Authentication framework
• Provisioning framework
• User store manager

Enterprise IT Systems are constantly changing; their perimeters are expanding and their policies keep changing. Therefore, in such a rapidly evolving world, security solutions need to be forward thinking and innovative. They need to be configurable in order to keep pace and adapt to rapid changes. This can be achieved by the identity manager component because it caters to security requirements at hand as well as looking toward the future. It has a very customizable user interface and can be easily implemented in order to ensure maximum security for your system.

The Outbound Provisioning component of the Identity Server can send provisioning requests to applications that support the following connectors.

• SCIM
• SPML
• Google
• Salesforce

These connectors reach out to identity providers who perform the provisioning.

The provisioning request comes into the outbound provisioning component from the provisioning framework. This request will go to the relevant connector.