Source: https://medium.com/@mshazninazeer/configuring-single-sign-on-sso-in-wso2-api-manager-with-shibboleth-idp-125782edc71c

Identity Federation for WSO2 API Manager

Demystifying the Need of WSO2 Identity Server for Identity Federation for WSO2 API Manager

6 min readFeb 4, 2020

There are two common types of IAM integrations for WSO2 API Manager.

Integration with a 3rd party OAuth2 authorization server
Integration with a 3rd party identity provider for identity federation

In this post I am going to discuss on second type of integration above. For a detailed discussion on the first type of integration, you can read my post on “Architecture for 3rd Party Authorization Server Integration”.

In this post I will analyze WSO2 API Manager versions 2.x.x and 3.x.x separately, as there are some significant differences in their integration capabilities.

When we talk about the identity federation capabilities in WSO2 API Manager, we are actually talking about 5 different service providers/relying parties. They are:

API Publisher
API Store/Developer Portal
Admin Portal
Management/Carbon Console
OAuth2/OIDC applications/service providers using the OAuth2 authorization endpoint of the Key Manager component to authorize the access delegation requests

Supporting identity federation for the last kind of applications mentioned above is straight forward. Once the authorization request is received at the Key Manager, based on the configured authentication policy in the Key Manager, the user may use identity federation to login. This capability is common to both WSO2 API Manager versions 2.x.x and 3.x.x.

Therefore in this post my focus is going to be on the first 4 service providers listed above. These 4 service providers collectively are going to be known as
“portals” within the context of this post.

Service Provider Capabilities of the Portals

As the first step of this analysis, let’s take a look at the service provider/relying party capabilities that are available with the portals.

The most relevant and important capability to understand is, the protocols that are supported for identity federation. The following table summarizes this capability.

Table 1: Identity federation protocols supported by the portals

The API Publisher and the Dev Portal in 3.x.x don’t support standard identity federation protocols, as they implement a proprietary OIDC protocol with the WSO2 Key Manager and are tightly coupled to it. Any inbound identity federation to these portals needs to be configured in the WSO2 Key Manager as a proxy.

New protocols can be supported in the API Publisher and the API Store in 2.x.x versions, as well the Admin Portal and Management Console in both 2.x.x versions and 3.x.x versions. To support a new protocol, in either the API Publisher, or API Store/Dev Portal or Admin Portal, an extension is required to the respective jaggery applications, where as for the management console a custom “CarbonAuthenticator” is required.

In APIM 3.x.x. the default login to the API Publisher and DevPortal is configured to be federated using OIDC to the WSO2 Key Manager.

Service Provider Limitations of the Portals

Now that we’ve looked at the capabilities of the portals, as the second step of this analysis, let’s take a look at the service provider/relying party limitations that are there with these portals.

The first limitation related to identity federation in these portals is, none of the portals can function purely by relying on the user roles that are found in the assertion. For many functions after logging into the portals, the portals connect directly to the local user store to read groups of the user and the user management database to read “Internal” roles of the user. If the permissions to operate the portals are managed only via “Internal” roles then it is sufficient to connect only to the user management database and not required to connect the portals to the user store at all. Further, if the permissions to operate the portals are managed via “Internal/everyone” role, then it is neither required to connect the user store nor the user management database to the portals. The latter two are often the cases when an external facing API Store is deployed in the DMZ, which cannot open connections to the user stores in the secured network zone. This is true for both WSO2 API Manager versions 2.x.x and 3.x.x.

The second limitation in these portals which is somewhat related to the first is, their inability to support claim/role transformation and JIT provisioning in the identity federation process out-of-the-box. In order to support them extensions are required to the respective portals.

The simplest solution to overcome both the limitations is to share the user stores (store that contains the user accounts and groups) with the portals. However, some organizations may have a strict security policy that does not allow to expose their user stores to the portals directly. In fact this could be one of the requirements for identity federation for the portals in the first place.

If you want to go the extra mile in order to avoid sharing the user stores with the portals, you could opt for an extension in the portals to do claim/role mapping and/or JIT provisioning. If the federated identity provider has the capability to do service provider specific role mappings, then you can limit the customizations to JIT provisioning only.

Identity Provider and Relying Party Capabilities of the WSO2 Key Manager

The built-in WSO2 Key Manager has a set of identity provider and relying party capabilities which forms an alternate path to identity federation of portals via the WSO2 Key Manager as a proxy. So as the third step of this analysis let’s look at what are these capabilities.

The first capability is to function as an OIDC compliant identity provider. Note that the WSO2 Key Manager does not have the capability to function as a SAML2 compliant identity provider like the WSO2 Identity Server.

The second capability is to federate identities as a relying party with other identity providers using protocols such as SAML2, OIDC, WS-Federation and CAS.

The third capability is to perform claim/role transformations as a relying party, on the claims and roles that are asserted and provided by the federated party into claims and roles that are managed and understood locally.

The fourth capability is to perform JIT provisioning as a relying party, to create users with corresponding roles on the fly.

All the above capabilities are available in WSO2 API Manager versions 2.x.x and 3.x.x.

Solutions for Identity Federation

Based on the above analysis, we can derive the following solutions to solve the identity federation requirements of WSO2 API Manager. Table 2 summarizes the options only with out-of-the-box capabilities, and Table 3 summarizes the options with extensions.