JSON Web Token (JWT) defines a container to transport data between interested parties. It became an IETF standard in May 2015 with the RFC 7519. There are multiple applications of JWT. The OpenID Connect is one of them. In OpenID Connect the id_token is represented as a JWT. Both in securing APIs and Microservices, the JWT is used as a way to propagate and verify end-user identity.
This article on medium explains in detail JWT, JWS and JWE with their applications.
Mobile Connect is an initiative by GSMA. The GSMA represents the interests of mobile operators worldwide, uniting nearly 800 operators with more than 250 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and internet companies, as well as organizations in adjacent industry sectors. The Mobile Connect initiative by GSMA focuses on building a standard for user authentication and identity services between mobile network operators (MNO) and service providers.
This article on medium explains the GSMA Mobile Connect API and see how it differentiates from the OpenID Connect core specification.
WSO2 offers a comprehensive open source product stack to cater to all needs of a connected business. With the single code base structure, WSO2 products are weaved together to solve many enterprise-level complex identity management and security problems. By believing in open standards and supporting most of the industry leading protocols, the WSO2 Identity Server is capable of providing seamless integration with a wide array of vendors in the identity management domain. The WSO2 Identity Server is one of the most powerful open source Identity and Entitlement Management server, released under the most business friendly Apache 2.0 license.
This article on medium explains thirty solution patterns, built with the WSO2 Identity Server and other WSO2 products to solve enterprise-level security and identity management related problems.
Microservices is one of the most trending buzzword, along with the Internet of Things (IoT). Everyone talks about microservices and everyone wants to have microservices implemented. The term ‘microservice’ was first discussed at a software architects workshop in Venice, in May 2011. It’s being used to explain a common architectural style they’ve been witnessing for some time. With the granularity of the services and the frequent interactions between them, securing microservices is challenging. This post, which I published on medium presents a security model based on OAuth 2.0, JWT and XACML to overcome such challenges.
Identity Patterns with the WSO2 Identity Server User administrators by the user store
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.
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.
Identity Patterns with the WSO2 Identity Server Service provider-specific user stores
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.
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.
Identity Patterns with the WSO2 Identity Server Home realm discovery
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.
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.
Identity Patterns with the WSO2 Identity Server Authenticate the users against one user store but fetch user attributes from multiple other sources
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.
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.
Identity Patterns with the WSO2 Identity Server User administration operations from a third-party web app
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).
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).
Identity Patterns with the WSO2 Identity Server Fine-grained access control for SOAP services
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.
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