Request Object Support for WSO2 Identity Server

Purpose of Request Object in OIDC

Usually in OIDC the returning claims will be filtered from the requested scopes that is passed to the server as an query param with the authorization request. When it comes to wso2 IS server, it filters the requested claims both from the requested scopes defined with the authorization request and the requested claims that can be configured in service provider configurations. But if Request Object is associated with the authorization request, then the server will return the essential request object claims if those claims are requested from the scope.

This request object can be either
1.  request parameter (Passed by value)
2.  request_uri parameter (Passed by reference)

'request' parameter

As we previously discussed the main purpose of this parameter is for supporting to request some claims other than the default Userinfo and IdToken claim set which is associated with the requested scope. This parameter value can be a pure json object or an encoded json object. 

Lets consider following sample request which contains pure json as the request parameter value.
https://localhost:9443/oauth2/authorize?
    response_type=code%20id_token
    &client_id=XXXXX
    &redirect_uri=http://localhost:8080/playground
    &scope=openid address
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &request={
  "iss": "s6BhdRkqt3",
  "aud": "https://server.example.com",
  "response_type": "code id_token",
  "client_id": "s6BhdRkqt3",
  "redirect_uri": "https://client.example.org/cb",
  "scope": "openid",
  "state": "af0ifjsldkj",
  "nonce": "n-0S6_WzA2Mj",
  "max_age": 86400,
  "claims": {
  "userinfo": {
  "given_name": {
  "essential": true
  },
 "nickname": null,
 "email": {
 "essential": true
  },
 "email_verified": {
 "essential": true
  },
  "picture": null
  },
 "id_token": {
  "gender": null,
  "email": {
  "essential": true
  },
  }
}
}

If we process the above request it requests some claims from both the members user info endpoint and id token. 'given_name' and 'email' are marked as essential claims from user info endpoint and email is requested as an essentila claim from id token. 

From the server side following validations will be done.
1. The client_id and response_type of the request object (if present) should be equal to the client_id and the response_type of the authorization request.
2. The authorization request query params will be overridden from the  request/request_uri parameter values if they are present in the request/request_uri parameter
3. Both the request and request_uri parameters can not be associated with the same authorization request.

IS server will respond as follows for the above sample request.
1. Here the requested scope is considered as 'openid email' as the scope value of the request object is declared. So the server will ignore the scope value which is associated with the authorization request and consider the requested scope as 'openid email'
2.Consider the claims "given_name" and "email" which are marked as 'essential:true' for 'userinfo' member. Even if they are not mapped with the openid or address scope in the registry,  if these claims are requested claims, then 'given_name' and 'email' will be returned from the Userinfo endpoint. So as a summary the claims which have marked as 'essential : true' only get controlled by the requested claims and ignore the requested scopes. If the server can not provide those essential claims there wont be any failure or error message returning from the server.

2. The claims like "nickname" it will act as a default claim and will control by both requested scopes and the requested claims.

3. If the server can not provide the requested essential claims the server will return null for the specific claim and the flow will not break.

4. This behavior is common to the id token as well.


Signature Validation

The request parameter value can be even a JWS or a JWE. If it is a JWS it will consist of three parts which is separated from 2 '.' characters those are JOSE header, JWS payload and JWS signature. So from the JOSE header the server will extract one of the following values to calculate the certificate thumbprint.
 jku,jwk,kid,x5u,x5c,x5t and x5t#s256
If the header does not contain one of the above values we simply reject do the signature validation. Based on the certificate value it will generate the public key and using the nimbus library it will validate the signature.

Decryption

The request parameter value can be a even a JWE. If it is a JWE it will consist of five parts which is separated from 4 '.'  characters those are JOSE header, JWE encrypted key , Initialization vector, Cipher text and Authentication tag. After doing a base64 encoding the values of those five sections can be seen. JOSE header is consists of 'alg' and 'enc' values. Algorithm defined in 'enc' is used to do the content encryption while the algorithm defined in the 'alg' is used to do the key wrapping. Here we have used nimbus library for the decryption by providing the IS private key.

If the jwt is a nested one then the payload (Cipher Text) of the jwt is a signed one. So the server will decrypt the string first and then check the payload for signature validation.

All the validations and the request object builder are extensible so a third party user can build the request object and do any validations in their own way. At the moment IS server does not have a default implementation for request_uri parameter and instead we do extract the request_uri parameter from the request object and pass it. So externally a user can write a builder to build the request_uri parameter and do their customizations.

Following configuration changes should be done in identity.xml when writing extension points for this feature.

  <OpenIDConnect>
  <RequestObjectBuilder>
  <BuilderName>request_param_value_builder</BuilderName>
  <RequestObjectBuilderImplClass>org.wso2.carbon.identity.openidconnect.RequestParamRequestObjectBuilder</RequestObjectBuilderImplClass>
  </RequestObjectBuilder>
  <RequestObjectValidator>org.wso2.carbon.identity.openidconnect.RequestObjectValidatorImpl</RequestObjectValidator>
  </OpenIDConnect>

 If the configuration is not present the default classes will be executed.

Comments

Post a Comment

Popular posts from this blog

Applying CORS Filter to wso2 Identity Server

When we are invoking an endpoint in oauth2 war from a javascript of a web app which is located in a different domain than identity server domain we are getting "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://XXXXXXX is therefore not allowed access." The issue is occurring as the script on your page is running from a specifc domain and would try to request the resource via an XmlHttpRequest or XDomainRequst from a different domain as this is a cross -origin request. In order to get rid of this we need to enable this by sending below header using a custom filter.  Access-Control-Allow-Origin: http: //example.com   (Here  http://example.com is the domain name of where page with that script is hosted) Invoking UserInfo endpoint of wso2 Identity Server from JavaScript We have two possible solutions to apply the CORS header.  1. Customizing OpenIDConnectUserEndpoint.java as below and replacing the oauth
Read more

JWKS endpoint of wso2 IS

What is JWKS endpoint? The JSON Web Key Set (JWKS) endpoint is a read-only endpoint. This url returns the Identity Server's public key set in Json web key set format. This contains the signing key(s) the RP uses to validate signatures from the Identity Server. This endpoint is defined loosely by the OpenID Connect Discovery specification . Try JWKS endpoint with Identity Server The endpoint url for the super tenant: https://localhost:9443/oauth2/jwks The jwks for the super tenant will be as follows: { "keys" : [ { "alg" : "RS256" , "kty" : "RSA" , "use" : "sig" , "n" : " AJSn-hXW9Zzz9ORBKIC9Oi6wzM4zhqwHaKW2vZAqjOeLlpUW7zXwyk4tkivwsydPNaWUm-9oDlEAB2lsQJv7jwWNsF7SGx5R03kenC-cf8Nbxlxwa-Tncjo6uruEsK_Vke244KiSCHP8BOuHI-r5CS0x9edFLgesoYlPPFoJxTs5 " , "e" : "AQAB" , "kid" : " d0ec514a32b6f88c0abd12a2840699bdd3deba9d "
Read more

DCR VS DCRM with WSO2 Identity server

Image
What is DCR (Dynamic Client Registration) Dynamic Client registration is a protocol which allows OAuth clients to register applications in an authorization server. Before this mechanism which is introduced from the spec [1] the client registration happened manually. With this implementation the client registration could be done in two ways.  - A client can be registered dynamically with the authorization server itself  - A programmer can register a client programmatically. Following is the protocol flow of DCR 1. A client sends a registration request with as follows. This should be a post request. 2. Server sends information response with 201 created. Request : POST   https://localhost:9443/api/identity/oauth2/dcr/v1.0/register HTTP/1.1 Authorization : Basic   YWRtaW46YWRtaW4= Content-Type :   application/json Content -Length :   114 Host: localhost :9443 {    "redirect_uris" : [      " http://localhost"    ],   
Read more