Security Patterns with WSO2 Identity Server

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

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

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

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

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

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

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

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

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 API Manager
WSO2 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

Requirement
● Ability to login into a SAML service provider with an assertion coming
from an OpenID Connect identity provider.
Solution
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

Requirement
● Ability to map claims with incompatible claim dialects between the
service provider, federated (external) identity provider and WSO2
Identity Server.
Solution
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 API Manager
WSO2 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

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

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

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

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

Requirements
● Ability to access multiple service providers that support multiple
● 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.

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

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
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 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)

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.

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

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

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

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

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

Requirement
● Ability to access multiple service providers supporting multiple
● 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

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.

Security Patterns with WSO2 Identity Server

Security Patterns with WSO2 Identity Server

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

More from WSO2

More from WSO2 (20)

Recently uploaded

Recently uploaded (20)

Security Patterns with WSO2 Identity Server