WSO2 Identity Server - Extension Points - Part 2 - OAuth

OAuth2 is widely used in the enterprise today for authorization aspects of APIs. This is the second post on the extension points available in WSO2 Identity Server after WSO2 Identity Server - Extension Points - Part 1 - SAML

All the implementation using following extension point needs to be configured at <IS_HOME>/repository/conf/identity/identity.xml file under the element OAuth.

1. Custom OAuth grant handler

Usage:

When we need to support an OAuth flow that is different from standard grant types. Validates the grant, scopes, and access delegation.

Sample:

https://docs.wso2.com/display/IS510/Writing+a+Custom+OAuth+2.0+Grant+Type

Interface:

org.wso2.carbon.identity.oauth2.token.handlers.grant.AuthorizationGrantHandler

2. Client Auth Handler


Usage:

When the client credential authentication needs to be customized. By default we validate the client id and secret.

Interface:

org.wso2.carbon.identity.oauth2.token.handlers.clientauth.ClientAuthenticationHandler

3. OAuthCallbackHandler

An extension point provided to verify whether the authenticated user is the rightful owner of the resource. There can be multiple active OAuthCallbackHandler implementations at a given time. There are registered through the identity.xml. In run-time, each and every authorization callback handler is invoked to see whether it can handle the given callback. Then the callback with the highest priority will be chosen. After handling the callback, it can set whether the given callback is authorized or not.

Interface:

org.wso2.carbon.identity.oauth.callback.OAuthCallbackHandler

Abstract Class / Default Implementation:

org.wso2.carbon.identity.oauth.callback.DefaultCallbackHandler

4. TokenPersistenceProcessor

Implementations are used to process keys and secrets just before storing them in the database. E.g. to encrypt tokens before storing them in the database. Implementations of this interface can be configured through the identity.xml.

Interface:

org.wso2.carbon.identity.oauth.tokenprocessor.TokenPersistenceProcessor

Abstract Class / Default Implementation:


  • org.wso2.carbon.identity.oauth.tokenprocessor.EncryptionDecryptionPersistenceProcessor
  • org.wso2.carbon.identity.oauth.tokenprocessor.PlainTextPersistenceProcessor

5. CustomClaimsCallbackHandler

This is an extension point provided to include any claims that need to go into the id_token in addition to the standard OIDC mandatory claims and user claims retrieved by WSO2 Identity Server.

An example would be add a tenant specific claim that is retrieved from an external API/Source could be included in an id_token using this extensions point. This extension point can also be used to set claims to the id_token without having to configure requested claims / oidc scopes using the management console.

Interface:

org.wso2.carbon.identity.openidconnect.CustomClaimsCallbackHandler

Abstract Class / Default Implementation:

org.wso2.carbon.identity.openidconnect.SAMLAssertionClaimsCallback

6. UserInfoAccessTokenValidator

Validates the access token and returns the token info. Default behavior is validating the access token with WSO2 IS token validation OSGI service(Scope is also checked to have openid scope). If this needs to be modified this can be used.

Interface:

org.wso2.carbon.identity.oauth.user.UserInfoAccessTokenValidator

Default Implementation:

org.wso2.carbon.identity.oauth.endpoint.user.impl.UserInfoISAccessTokenValidator

7. UserInfoClaimRetriever

Default behavior is creating claim URI and claim value pairs according to the claim mappings received. Any modifications to this default behavior can be done here.

Interface:

org.wso2.carbon.identity.oauth.user.UserInfoClaimRetriever

Default Implementation:

org.wso2.carbon.identity.oauth.endpoint.user.impl.UserInfoUserStoreClaimRetriever

8. UserInfoRequestValidator


Default behavior is validating the schema and authorization header according to the specification(http://openid.net/specs/openid-connect-basic-1_0-22.html#anchor6). Any further additional validations or modification to this validation on user info request can be done using this extension.
Interface:
org.wso2.carbon.identity.oauth.user.UserInfoRequestValidator

Default Implementation:

org.wso2.carbon.identity.oauth.endpoint.user.impl.UserInforRequestDefaultValidator

9. UserInfoResponseBuilder

Creates the UserInfoResponse. By default the response can be a JSON or a JWT. When a different format is required this extension can be used to support it.
Interface:
org.wso2.carbon.identity.oauth.user.UserInfoResponseBuilder

Default Implementations:


  • org.wso2.carbon.identity.oauth.endpoint.user.impl.UserInfoJSONResponseBuilder
  • org.wso2.carbon.identity.oauth.endpoint.user.impl.UserInfoJWTResponse

10. AuthorizationContextTokenGenerator

Generates the token relevant to the authorization context. By default JWT token generation is supported with the following properties encoded to each authenticated API request:
  • subscriber, applicationName, apiContext, version, tier, and endUserName
  • Additional properties can be encoded by engaging the below extension.
  • The JWT header and body are base64 encoded separately and concatenated with a dot.
  • Finally the token is signed using SHA256 with RSA algorithm.

Any deviations can be made via this extension and configured in identity.xml

Default Implementations:

org.wso2.carbon.identity.oauth2.authcontext.AuthorizationContextTokenGenerator

11. ClaimsRetriever

The default implementation class of this ClaimsRetriever reads user claim values from the default carbon user store. The user claims are encoded to the token in the natural order of the claimURIs by the previous token generator. To engage this class, its fully qualified class name should be mentioned under identity.xml -> OAuth -> TokenGeneration -> ClaimsRetrieverImplClass

Any deviation can be done using this extension.

Default Implementations:

org.wso2.carbon.identity.oauth2.authcontext.AuthorizationContextTokenGenerator

12. ResponseTypeHandler

This is intended to validate access delegation and oauth scope validation. Then issue codes or tokens. In this flow needs to be customized this extension can be used. 


Interface:

org.wso2.carbon.identity.oauth2.authz.handlers.ResponseTypeHandler

13. OAuth2TokenValidator

This when a token is sent back for validation purposes to validate on scopes, validity of access token and access delegation.

Interface:

org.wso2.carbon.identity.oauth2.validators.OAuth2TokenValidator

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

Image
Digital signing is a widely used mechanism to make digital contents authentic. By producing a digital signature for some content, we can let another party capable of validating that content. It can provide a guarantee that, is not altered after we signed it, with this validation. With this sample I am to share how to generate the a signature for SOAP envelope. But of course this is valid for any other content signing as well. Here, I will sign The SOAP envelope itself An attachment  Place the signature inside SOAP header  With the placement of signature inside the SOAP header which is also signed by the signature, this becomes a demonstration of enveloped signature. I am using Apache Santuario library for signing. Following is the code segment I used. I have shared the complete sample here to to be downloaded . public static void main(String unused[]) throws Exception {         String keystoreType = "JKS";         Stri...
Read more

Tomcat JDBC Pool - Connection Leak - Catch the Culprit

Database connection leaks are something that can stay hidden unless paid specific attention and would come to the surface at the most critical stages at a peak time of the system. We would manually check if all the open connections have been closed properly. Then we have various code quality plugins that would scan and check for that. Still when the connections are passed through a complex structure of program both of these can miss a possible connection leak. Then at unit test or integration test levels, we can have checks to validate the counts in the connection pool to avoid this unfortunate situation, that would keep engineers busy at year-end, black Friday, etc. :) In the unfortunate case of hitting with a performance degrade or a total crash of the system which can be propagated via a JDBC connection leak, when we suspect a connection leak, how easily and quickly isolate the culprit. In the Tomcat connection pool, we can do this using 3 properties. removeAbandoned If a...
Read more

How to convert WSDL to Java

Image
Background Basically WSDL (Web Services Development Language) is an XML document used to describe or locate web services. WSDL stands for Web Services Description Language. The document describes a Web service. It specifies the location of the service and the operations that can be taken.  WSDL2Java is distributed with Axis2 package of Apache and need to set-up Axis2 to use this service. A  guide to set-up Axis2  can be found in apache organization documents .WSDL 2.0 is the currently using version. Obviously JDK should be properly installed too. Note: For the 3rd method you are not needed to set these things by yourself. The WSDL document includes server Java programs for Web services and generated classes using WSDL2Java feature includes client stubs, server skeletons and data types that can help in writing client side. The generated stub classes play a great role in distributed computing and if you are interested can read on  what are...
Read more