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

http://www.freepik.com/free-vector/online-application-vector-design_723923.htm

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

http://wso2.com/products/identity-server/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16


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.

http://blog.facilelogin.com/2016/03/enabling-mult-factor-authentication-for.html

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 ManagerWSO2 Application Server



http://wso2.com/products/api-manager/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

http://wso2.com/products/application-server/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

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




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 API ManagerWSO2 Governance Registry



http://wso2.com/products/api-manager/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

http://wso2.com/products/governance-registry/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

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.

http://blog.facilelogin.com/2016/02/enforce-password-reset-for-expired.html

15. Federation proxy

WSO2 Identity Server 5.0.0 and above WSO2 App Manager



http://wso2.com/products/app-manager/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

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

http://www.slideshare.net/prabathsiriwardena/securing-singlepage-applications-with-oauth-20

https://github.com/facilelogin/aratuwa/tree/master/oauth2.0-apps

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



http://wso2.com/products/application-server/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

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● 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 Microservices Framework for Java



http://wso2.com/products/microservices-framework-for-java/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

http://wso2.com/products/microservices-framework-for-java/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

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

https://medium.com/@prabath/securing-microservices-with-oauth-2-0-jwt-and-xacml-d03770a9a838

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.

● 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




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



http://wso2.com/products/enterprise-service-bus/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

http://wso2.com/products/governance-registry/?utm_source=slideshare&utm_medium=slidedeck&utm_campaign=security_patterns_slidedeck_may16

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

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




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.

Technology

Security Patterns with WSO2 Identity Server