Security Patterns with WSO2 Identity Server
By Prabath Siriwardena
Looking to solve enterprise-level security and identity management related problems? These thirty solutions patterns are sure to help you on
your journey.
Designed by Freepik
1. Single sign-on (SSO) between multiple heterogeneous identity federation protocols (slide 5)
2. Multiple login options by service provider (slide 8)3. Provision federated users by the identity provider (slide 12)4. Just-in-Time (JIT) provision users to cloud service providers (slide 15)5. Multi-factor authentication (MFA) for WSO2 Identity Server
management console (slide 19)6. Provision federated users to a tenant (slide 22)7. Login to multiple service providers with the current Windows login
session (slide 25)8. Rule-based user provisioning (slide 28)9. User management upon multi-layer approval (slide 31)10.SSO with delegated access control (slide 34)11.Identity federation between service providers and identity providers
with incompatible identity federation protocols (slide 38)12.Claim mapper (slide 41)13.Fine-grained access control for APIs (slide 44)14.Enforce password reset for expired passwords during the
authentication flow (slide 47)15.Federation proxy (slide 50)
Table of Contents
16.Mobile identity provider proxy (slide 54)17.Single page application (SPA) proxy (slide 59)18.Fine-grained access control for service providers (slide 63)19.Self-sign up during the authentication flow with service provider
specific claim dialects (slide 67)20.Accessing a SOAP service secured with WS-Trust from a Web app on
behalf of the logged-in user (SAML 2.0) (slide 71)21.Enforce users to provide missing attributes while getting JIT
provisioned to the local system (slide 75)22.Access a microservice from a Web app protected with SAML 2.0 or
OpenID Connect (slide 78)23.SSO between a legacy Web app (which can’t change the user
interface) and service providers (which support standard SSO protocols) (slide 82)
24.Render menu items in a Web app based on the logged-in user’s fine-grained permissions (slide 86)
25.Fine-grained access control for SOAP services (slide 90)26.User administration operations from a third-party Web app (slide 94)27.Authenticate the users against one user store but fetch user
attributes from multiple other sources (slide 97)28.Home realm discovery (slide 100)29.Service provider specific user stores (slide 104)30.User administrators by the user store (slide 107)
1.Single sign-on (SSO) between multiple
heterogeneous identity federation protocols
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to access multiple service providers that support
multiple heterogeneous identity federation protocols, on-premise and in the cloud.
● A user who logs into any of the service providers should be automatically logged into the rest of them.
Solution● Deploy WSO2 Identity Server over the enterprise user store.
● Represent each service provider in it and configure the corresponding inbound authenticators.
● Configure WSO2 Identity Server as a trusted identity provider.
2. Multiple login options by service provider
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to access multiple service providers, where each service
provider requires different login options.
● Multi-factor authentication for some service providers.
● Deploy WSO2 Identity Server over the enterprise user store.
● Represent each service providers in it and configure local and outbound authentication options under each one. ○ Multiple login: define an authentication step with the
required authenticators.○ Multi-factor authentication (MFA): define multiple
authentication steps with supporting authenticators in each step.
○ Federated authentication: represent all federated identity providers as identity providers and engage them with appropriate service providers under the relevant authentication step.
● In each service provider, configure WSO2 Identity Server as a trusted identity provider.
Solution
3. Provision federated users by the identity provider
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to login to multiple service providers via multiple
identity providers.
● Ability to group federated users by the identity provider and store all the user attributes locally, irrespective of the service provider.
Solution● Deploy WSO2 Identity Server over multiple user stores and
name each user store after the name of the corresponding identity provider.
● Represent each federated identity provider in WSO2 Identity Server.
● Enable Just-in-Time (JIT) provisioning for each identity provider, and pick the user store domain to provision users.
4. Just-in-Time (JIT) provision users to cloud service providers
WSO2 Identity Server 5.0.0 and above
Requirements● The company foo has an account with the bar cloud service
provider (it can be Google Apps, Salesforce, Workday).
● The company foo trusts employees from the company zee to login into the bar cloud service provider, under the foo account and needs to allow this.
● Introduce bar as a service provider (bar-sp) to the WSO2 Identity Server running at foo.
● Introduce bar as a provisioning identity provider (bar-idp) to the WSO2 Identity Server, and configure the provisioning protocol.
● Introduce zee as an identity provider to the WSO2 Identity Server, and enable JIT provisioning.
● Under the bar-sp service provider configuration, ○ Under local and outbound authentication configuration,
select zee as a federated identity provider. ○ Under outbound provisioning configuration, select bar-idp
as a provisioning identity provider.
● Introduce the WSO2 Identity Server running at foo as a trusted identity provider to the zee cloud service provider.
Solution
5. Multi-factor authentication (MFA) for WSO2 Identity Server management
console
WSO2 Identity Server 5.0.0 and above
Requirement● Ability to protect the WSO2 Identity Server’s management
console with multi-factor authentication (MFA).
Solution● Introduce WSO2 Identity Server as a service provider to itself.
● Under the service provider configuration, configure multi-step authentication with authenticators that support MFA in each step.
● Enable the SAML SSO (Security Assertion Markup Language Single Sign-On) carbon authenticator through the corresponding configuration file.
● To learn how to do this click here.
6. Provision federated users to a tenant
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to login to multiple service providers via multiple
identity providers.
● Ability to provision federated users to an individual tenant, irrespective of the service provider.
Solution● Define a user store with CarbonRemoteUserStoreManager in
the WSO2 Identity Server pointing to the individual tenant.
● Represent each federated identity provider in WSO2 Identity Server.
● Enable JIT provisioning for each identity provider, and pick the user store domain (CarbonRemoteUserStoreManager) to provision users.
7. Login to multiple service providers with the current Windows login session
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to login to multiple service providers that support
multiple heterogeneous identity federation protocols, on-premise or in the cloud.
● A user logged into their Windows machine should be able to access any service provider without further authentication.
Solution● Deploy WSO2 Identity Server over the enterprise active
directory as the user store.
● Represent all the service providers in it and configure the corresponding inbound authenticators.
● For each service provider○ Under local and outbound authentication configuration,
enable Integrated Windows Authentication (IWA) local authenticator.
○ Configure WSO2 Identity Server as the trusted identity provider.
8. Rule-based user provisioning
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to provision all the employees to Google Apps at the
time they join the company and provision only the employees belonging to the sales-team to Salesforce.
Solution● Represent Salesforce and Google Apps as provisioning identity
providers in the WSO2 Identity Server.
● Under ‘Salesforce Provisioning Identity Provider’ configuration, under the ‘Role Configuration’, set sales-team as the role for outbound provisioning.
● Under the ‘Resident Service Provider’ configuration, set both Salesforce and Google Apps as provisioning identity providers for outbound provisioning.
9. User management upon multi-layer approval
WSO2 Identity Server 5.1.0 and above
Requirement● All user management operations must be approved by multiple
administrators in the enterprise in a hierarchical manner.
Solution● Create a workflow with multiple steps. In each step specify who
should provide the approval.
● Define a workflow engagement for user management operations and associate the above workflow with it.
● When defining the workflow, define the criteria for its execution.
10. SSO with delegated access control
WSO2 Identity Server 5.0.0 and above
WSO2 API ManagerWSO2 Application Server
Requirements● Ability to login into multiple service providers with SSO via an
identity provider.
● Some service providers may require the ability to access back-end APIs on behalf of the logged in user.
● Represent all the service providers in the WSO2 Identity Server and configure inbound authentication with either SAML 2.0 or OpenID Connect.
● For each service provider that needs to access back-end APIs, configure OAuth 2.0 as an inbound authenticator, in addition to the SSO protocol.
● Once a user logs in to the service provider, use the appropriate grant type (SAML or JSON Web Token (JWT) grant type for OAuth 2.0) to exchange the SAML token or JWT for an access token, by talking to the token endpoint of the WSO2 Identity Server
● Other products used: WSO2 API Manager and WSO2 Application Server.
Solution
11. Identity federation between service providers and identity
providers with incompatible identity federation protocols
WSO2 Identity Server 5.0.0 and above
Requirement● Ability to login into a SAML service provider with an assertion
coming from an OpenID Connect identity provider.
Solution● Represent all the service providers in the WSO2 Identity Server
and configure the corresponding inbound authenticators.
● Represent all the identity providers in the WSO2 Identity Server and configure the corresponding federated authenticators.
● Associate identity providers with service providers, under the ‘Service Provider’ configuration, under the ‘Local and Outbound Authentication’ configuration, irrespective of the protocols they support.
12. Claim mapper
WSO2 Identity Server 5.0.0 and above
Requirement● Ability to map claims with incompatible claim dialects between
the service provider, federated (external) identity provider and WSO2 Identity Server.
Solution● Represent all the service providers in the WSO2 Identity Server
and configure the corresponding inbound authenticators.
● Represent all the identity providers in the WSO2 Identity Server and configure the corresponding federated authenticators.
● For each service provider and identity provider define custom claims and map them to the WSO2 default claim dialect.
13. Fine-grained access control for APIs
WSO2 Identity Server 5.0.0 and above
WSO2 API ManagerWSO2 Governance Registry
Requirement● Access to business APIs must be done in a fine-grained manner
where only certain users can access certain APIs at a certain time.
Solution
● Setup the WSO2 Identity Server as the key manager of the WSO2 API Manager.
● Write a scope handler and deploy it in the WSO2 Identity Server to talk to it’s eXtensible Access Control Markup Language (XACML) engine during the token validation phase.
● Create XACML policies using the WSO2 Identity Server XACML policy wizard to address the business needs.
● Other products used: WSO2 API Manager and WSO2 Governance Registry.
14. Enforce password reset for expired passwords during the authentication
flow
WSO2 Identity Server 5.0.0 and above
Requirement● Ability to check whether end-user password has expired during
the authentication flow. If it has the user should be prompted to change the password.
Solution● Configure multi-step authentication for the corresponding
service provider.
● Engage basic authenticator for the first step to accept the username/password from the end-user.
● Write a handler (a local authenticator) and engage it in the second step to check the validity of the user’s password. If it’s expired then prompt the user to reset the password.
● Sample implementation can be found here.
15. Federation proxy
WSO2 Identity Server 5.0.0 and above WSO2 App Manager
Requirements● All inbound requests for all service providers in the corporate
domain must be intercepted centrally and authenticated via an identity hub.
● Users can be authenticated through the hub via different identity providers. These users must be provisioned locally.
● One user can have multiple accounts with multiple identity providers connected to the hub.
● When provisioned into the local system, the user should be given the option to map or link all his/her accounts and then pick under which account he/she needs to login into the service provider.
● Deploy WSO2 App Manager to front all the service providers inside the corporate domain.
● Configure WSO2 Identity Server as the trusted identity provider of WSO2 App Manager. The setup of these two combined is called the federation proxy.
● Introduce the identity provider running at the hub (it can be another WSO2 Identity Server as well) as a trusted identity provider to the WSO2 Identity Server running as the proxy.
● Configure git provisioning against the hub identity provider.
● For all service providers, the initial authentication will happen via the hub identity provider. Then, configure a connector to the second step to perform account linking.
● Other products used: WSO2 App Manager
Solution
16. Mobile identity provider proxy
WSO2 Identity Server 5.2.0 and above
Requirements● A company builds a set of native mobile apps and deploys
them into a company owned set of devices for their employees.
● When a user logs into one native mobile app, they should automatically login to all the other native apps, without having to provide his/her credentials again.
● No system browser is in the device.
● Build a native mobile app (identity provider [IdP] proxy) and deploy it in each device along with all the other native apps.
● This IdP proxy must be registered with the WSO2 Identity Server, as a service provider, with OAuth 2.0 as the inbound authenticator.
● Under the IdP proxy service provider configuration in WSO2 Identity Server, enable only the resource owner password grant type.
● Each native app must be registered with the WSO2 Identity Server as a service provider, having OAuth 2.0 as the inbound authenticator and only the implicit grant type enabled.
● Under the Local and Outbound Authentication configuration in WSO2 Identity Server, make sure to have oauth-bearer as a request-path authenticator.
● The IdP proxy has to provide a native API for all other native apps.
Solution
● When a user wants to login into an app, the app has to talk to the login API of the IdP proxy by passing its OAuth 2.0 client_id.
● The IdP proxy should first check whether it has a master access token. If not it should prompt the user to enter the credentials, then use the password grant type to talk to the WSO2 Identity Server’s /token API to get the master access token. The IdP proxy must securely store it and users who already have it don’t have to be authenticated again.
● Now, using the master access token, the IdP proxy should talk to the /authorize endpoint of the WSO2 Identity Server, following the implicit grant type with the client_id provided by the native app.
● Once the access token and the ID token are returned from the WSO2 Identity Server, the IdP proxy will return them back to the native app that first performed the login API call.
Solution cont.
17. Single page application (SPA) proxy
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to authenticate users to a single page application (SPA)
in a secure manner, via OAuth 2.0.
● The access token must be made invisible to the end-user when an SPA accesses an OAuth-secure API.
● The client (or the SPA) must be authenticated in a legitimate manner when an SPA access an OAuth-secured API.
● There are multiple ways to secure an SPA and this presentation covers some options.
● In the SPA proxy pattern, a proxy is introduced, and the calls from the SPA will be routed through the proxy.
● Build an SPA proxy and deploy it in WSO2 Identity Server. A sample proxy app is available here.
● The SPA proxy must be registered in the WSO2 Identity Server as a service provider, with an OAuth inbound authenticator.
● To make the SPA proxy stateless, the access_token and the id_token obtained from the WSO2 Identity Server (after the OAuth flow) are encrypted and set as a cookie.
Solution
18. Fine-grained access control for service providers
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to access multiple service providers supporting multiple
heterogeneous identity federation protocols.
● Each service provider needs to define an authorization policy at the identity provider, to decide whether a given user is eligible to log into the corresponding service provider.
● Deploy WSO2 Identity Server as the identity provider and register all the service providers.
● Build a connector, for the WSO2 Identity Server’s XACML engine to perform authorization.
● For each service provider, that needs to enforce access control during the login flow, ○ Engage the XACML connector to the second authentication
step, under the ‘Local and Outbound Authentication’ configuration.
○ Create its own XACML policies in the WSO2 Identity Server PAP (Policy Administration Point).
● To optimize the XACML policy evaluation, follow a convention to define a target element under each XACML policy that can uniquely identify the corresponding service provider.
Solution
19. Self-sign up during the authentication flow with service provider specific claim dialects
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to access multiple service providers that support
multiple heterogeneous identity federation protocols.
● When the user gets redirected to the identity provider for authentication, a page with the login options and an option to sign up should be shown.
● If the user picks the sign-up option, the required set of fields must be specific to the service provider who redirected the user to the identity provider.
● Upon registration, the user must be in a locked status, and a confirmation mail has to be sent to their email address.
● Upon confirmation, the user should be prompted for authentication again and redirected back to the initial service provider.
● Deploy WSO2 Identity Server as the identity provider and register all the service providers.
● Customize the login web app (authenticationendpoints) deployed inside WSO2 Identity Server to give the sign up option
● Follow a convention and define a claim dialect for each service provider with the required set of user attributes it needs during the registration.
● Build a custom /signup API, which retrieves the required attributes for user registration, by passing the service provider name.
● Upon registration, the /signup API will use the email confirmation feature in the WSO2 Identity Server to send the confirmation mail. Additionally it also maintains the login status of the user.
Solution
20. Accessing a SOAP service secured with WS-Trust from a Web app on
behalf of the logged-in user (SAML 2.0)
WSO2 Identity Server 3.0.0 and above WSO2 Application Server
Requirements● Ability to access multiple service providers that support SAML
2.0 web SSO-based authentication.
● Once the user logs into the Web app, it needs to access a SOAP service secured with WS-Trust on behalf of the logged-in user.
● Deploy WSO2 Identity Server as an identity provider, and register all the service providers. Deploy the SOAP service in WSO2 App Manager and secure it with WS-Security Policy. Deploy the Web app in WSO2 App Manager.
● Write a filter and deploy it in WSO2 Application Server, which will accept a SAML token coming from the Web SSO flow and build a SOAP message embedded with it.
● Communication channels that carry SAML tokens must be over TLS.
● Once the web app gets the SAML token, it will build a SOAP message with its security headers and talk to the security token service endpoint to get a new SAML token to act as the logged-in user.
● WSO2 App Server will validate the security of the SOAP message. It has to trust the WSO2 Identity Server, who is the token issuer.
Solution
21. Enforce users to provide missing attributes while getting JIT provisioned
to the local system
WSO2 Identity Server 5.0.0 and above
Requirement● Ability to access multiple service providers via federated
identity provider.
● Ability to JIT provision all users coming from federated identity providers with a predefined set of attributes. If any attributes are missing, the system should prompt the user for them.
Solution● Deploy WSO2 Identity Server as the identity provider and
register all the service providers and federated identity providers.
● Enable JIT provisioning for each federated identity provider.
● Build a connector to validate the attributes in the authentication.
● Engage this connector to an authentication step after the step which includes the federated authenticator.
22. Access a microservice from a Web app protected with SAML 2.0 or OpenID
Connect
WSO2 Identity Server 5.1.0 and above
WSO2 Microservices Framework for Java
Requirements● Ability to access multiple service providers, supporting SAML
2.0 and OIDC-based authentication.
● Once the user logs into the web app, it needs to access a microservice on behalf of the logged in user.
● Deploy WSO2 Identity Server as the identity provider and register all service providers with OIDC/SAML 2.0 as the inbound authenticator.
● Enable JWT-based access token generator.
● Develop and deploy all the microservices with WSO2 Microservices Framework for Java (WSO2 MSF4J).
● Once the user logs into the Web app, exchange the SAML token or ID token to an OAuth access token by talking to the /token endpoint of the WSO2 Identity Server, while following the SAML 2.0 grant type or JWT grant type respectively for the OAuth 2.0 profile. This access token itself is a self-contained JWT.
● To access the microservice, pass the JWT in the HTTP Authorization Bearer header over the transport layer security.
● WSO2 MSF4J will validate the JWT and it will be passed across all the downstream microservices. Learn more about microservice security.
Solution
23. SSO between a legacy Web app (which can’t change the user interface) and service providers (which support
standard SSO protocols)
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to access a service provider that cannot change its user
interface (UI). The users need to provide their user credentials to the current login form of the service provider.
● Once the user logs into the above service provider, and clicks on a link to another service (which follows a standard SSO protocol), the user should be automatically logged in. The vice-versa is not true.
● Deploy WSO2 Identity Server as the identity provider and register all the service providers with standard inbound authenticators (including the legacy app).
● For the legacy Web app, enable basic auth request path authenticator, under the ‘Local and Outbound Authentication’ configuration.
● Once the legacy app accepts the user credentials from its login form, post them along with the SSO request (SAML 2.0/OIDC) to the WSO2 Identity Server.
● The WSO2 Identity Server will validate the credentials embedded in the SSO request. If valid, it will issue an SSO response and the user will be redirected back to the legacy application.
● When the same user tries to log in to another service provider, the user will be automatically authenticated, as a web session was created earlier, under the WSO2 Identity Server domain.
Solution
24. Render menu items in a Web app based on the logged-in user’s fine-
grained permissions
WSO2 Identity Server 4.0.0 and above
Requirements● Ability to render menu items in a Web app dynamically based
on user’s permissions when they login.
● The permission is user based and time- and location-sensitive.
● Deploy WSO2 Identity Server as a XACML PDP (Policy Decision Point).
● Define XACML policies via the XACML PAP (Policy Administration Point) of the WSO2 Identity Server.
● When a user logs into the Web app, it will talk to the WSO2 Identity Server’s XACML PDP endpoint with a XACML request using XACML multiple decision profile and XACML multiple resource profile.
● After evaluating the XACML policies against the provided request, the WSO2 Identity Server returns the response, including the level permissions the user has on each resource. Each menu item is represented as a resource in the XACML policy.
● The app caches the decision to avoid further calls to XACML PDP.
● Whenever some event happens at the XACML PDP side, which requires expiring the cache, the WSO2 Identity Server will notify a registered endpoint of the Web app.
Solution
25. Fine-grained access control for SOAP services
WSO2 Identity Server 4.0.0 and above WSO2 Enterprise Service Bus
WSO2 Governance Registry
Requirements● Ability to access business services in a fine-grained manner.
● Only users belonging to the business-admin role should be able to access foo and bar SOAP services during a certain time period.
● Deploy WSO2 Identity Server as a XACML PDP.
● Define XACML policies via the XACML PAP of WSO2 Identity Server.
● Front the SOAP services with WSO2 ESB and represent each service a proxy service in it.
● Engage the entitlement mediator to the protected in-sequence of the proxy service. It will point to the WSO2 Identity Server’s XACML PDP.
● All requests to the SOAP service will be intercepted by the mediator and will talk to the WSO2 Identity Server’s XACML PDP to check whether the user is authorized to access the service.
● Authentication should happen at the edge of the WSO2 ESB.
● If the request to the SOAP service brings certain attributes in the SOAP message itself, the mediator can extract them and add to the XACML request.
Solution
26. User administration operations from a third-party Web app
WSO2 Identity Server 4.0.0 and above
Requirement● A third-party Web app needs to perform all user management
operations without having to deal directly with underlying user stores.
Solution● Deploy the WSO2 Identity Server over the required set of user
stores.
● The WSO2 Identity Server exposes a set of REST endpoints as well as SOAP-based services for user management.
● The Web app just needs to talk to these endpoints, without having to deal directly with underlying user stores.
27. Authenticate the users against one user store but fetch user attributes
from multiple other sources
WSO2 Identity Server 4.6.0 and above
Requirement● User credentials are maintained in a one user store while user
attributes are maintained in multiple sources. When the user logs into the system via any SSO protocol, the response should be built with the user attributes coming from multiple sources.
Solution● Mount the credential and attribute stores as user stores to the
WSO2 Identity Server. The attributes store can be differentiated from the credential stores just by looking at domain name.
● Build a custom user store manager, which is aware of all the attribute stores in the system and overrides the method that returns user attributes. The overridden method will iterate through the attribute stores, find the user’s attributes and return the aggregated result.
● Set the custom user store manager from the previous step as the user store manager corresponding to the primary user store.
28. Home realm discovery
WSO2 Identity Server 5.0.0 and above
Requirements● Ability to log into multiple service providers via multiple
identity providers.
● Rather than providing a multi-login option page with all the available identity providers, once redirected from the service provider, the system should find out who the identity provider corresponding to the user is and redirect the user there.
● Deploy WSO2 Identity Server as an identity provider and register all the service providers and identity providers.
● For each identity provider, specify a home realm identifier.
● The service provider prior to redirecting the user to the WSO2 Identity Server must find out the home realm identifier corresponding to the user and send it as a query parameter.
● Looking at the home realm identifier in the request, the WSO2 Identity Server redirects the user to the corresponding identity provider.
● In this case, there is a direct one-to-one mapping between the home realm identifier in the request and the home realm identifier value set under the identity provider configuration. This pattern can be extended by writing a custom home realm discovery connector, which knows how to relate and find the corresponding identity provider without maintaining a direct one-to-one mapping.
Solution
29. Service provider specific user stores
WSO2 Identity Server 5.0.0 and above
Requirement● Ability to access multiple service providers supporting multiple
heterogeneous identity federation protocols.
● Each service provider should be able to specify from which user store it accepts users.
Solution● Deploy the WSO2 Identity Server as an identity provider over
multiple user stores and register all the service providers.
● Extend pattern 18. Fine-grained access control for service providers to enforce user store domain requirement in the corresponding XACML policy.
● Use a regular expression to match the allowed user store domain names with the authenticated user’s user store domain name.
30. User administrators by the user store
WSO2 Identity Server 4.6.0 and above
Requirement● Ability to define user administrators by user store. For example,
a user belonging to the role foo-admin will be able to perform user admin operations on the foo user store but they won’t be able to perform user admin operations on the bar user store.
Solution● Deploy the WSO2 Identity Server as an identity provider over
multiple user stores.
● Define a XACML policy, which specified who should be able to do which operation on user stores.
● Create a user store operation listener and talk to the XACML PDP during user admin operations.
● Create roles for the user store and user administrators. Also, make sure each user administrator has the user admin permissions from the permission tree.