Identity Patterns with the WSO2 Identity Server
User administrators by the user store

Problem:
  • Define user administrators by user store. For example, a user belongs to the role foo-admin will be able to perform user admin operations on the foo user store, while he/she 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 by user store and user administrators to appropriate roles. Also, make sure each user administrator has the user admin permissions from the permission tree. 
  • Products: WSO2 Identity Server 4.6.0+ 


Identity Patterns with the WSO2 Identity Server
Service provider-specific user stores

Problem:
  • The business users need to access multiple service providers supporting multiple heterogeneous identity federation protocols. 
  • When the user gets redirected to the identity provider, the users only belong to the user stores specified by the corresponding service provider, should be able to login or get an authentication assertion. 
  • In other words, 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 the pattern 18.0 Fine-grained access control for service providers to enforce user store domain requirement in the corresponding XACML policy. 
  • Use a regular expression to match allowed user store domain names with the authenticated user’s user store domain name. 
  • Products: WSO2 Identity Server 5.0.0+ 


Identity Patterns with the WSO2 Identity Server
Home realm discovery

Problem:
  • The business users need to login to multiple service providers via multiple identity providers. 
  • Rather than providing a multi-login option page with all the available identity provider, once redirected from the service provider, the system should find out who the identity provider corresponding to the user and directly redirect the user there.
Solution:
  • 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 redirect 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 by looking at the home realm identifier in the request, without maintaining a direct one-to-one mapping. 
  • Products: WSO2 Identity Server 5.0.0+ 


Identity Patterns with the WSO2 Identity Server
Authenticate the users against one user store but fetch user attributes from multiple other sources

Problem:
  • 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 (SAML 2.0, ODIC, WS-Federation), build the response with user attributes coming from multiple sources.
Solution:
  • Mount the credential store and all the attribute stores as user stores to the WSO2 Identity Server. Follow a naming convention while naming the user stores where the attributes store can be differentiated from the credentials stores just by looking at the user store domain name. 
  • Build a custom user store manager (extending the current user store manager corresponding to the type of the primary user store), which is aware of all the attribute stores in the system and override the method, which returns user attributes. The overridden method will iterate through the attribute stores find the user’s attributes and will return back the aggregated result. 
  • Set the custom user store manager from the previous step as the user store manager corresponding to the primary user store. 
  • Products: WSO2 Identity Server 4.6.0+ 


Identity Patterns with the WSO2 Identity Server
User administration operations from a third-party web app

Problem:
  • A third party web app needs to perform all user management operations such as all CRUD operations on users and roles, user/role assignments and password recovery, without having to deal directly with underlying user stores (LDAP, AD, JDBC).
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 need to talk to these endpoints, without having to deal directly with underlying user stores (LDAP, AD, JDBC). 
  • Products: WSO2 Identity Server 4.0.0+ 


Identity Patterns with the WSO2 Identity Server
Fine-grained access control for SOAP services

Problem:
  • Access to the business services must be done in a fine-grained manner. 
  • Only the users belong to the business-admin role should be able to access foo and bar SOAP services during a weekday from 8 AM to 5 PM.
Solution:
  • 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. 
  • Front the SOAP services with WSO2 ESB and represent each service a proxy service in the ESB. 
  • Engage the Entitlement mediator to the in-sequence of the proxy service, which needs to be protected. The Entitlement mediator will point to the WSO2 Identity Server’s XACML PDP. 
  • All the requests to the SOAP service will be intercepted by the Entitlement mediator and will talk to the WSO2 Identity Server’s XACML PDP to check whether the user is authorized to access the service. 
  • Authentication to the SOAP service should happen at the edge of the WSO2 ESB, prior to Entitlement mediator. 
  • If the request to the SOAP service brings certain attributes in the SOAP message itself, the Entitlement mediator can extract them from the SOAP message and add to the XACML request. 
  • Products: WSO2 Identity Server 4.0.0+, WSO2 ESB, Governance Registry 


Subscribe to: Posts (Atom)