Hi Farasath,

Thanks for the response. I was further playing around and it looks that there is a tight coupling between the OAuth2TokenEndpoint, PasswordGrantHandler and the definition in the identity.xml as grant type = "password". although I have just tried the PasswordGrantHandler, not the others.

1. OAuth2TokenEndpoint don't copy the parameters if it is one of the 5 known grant types. This is something I dont understand because if I want to disable the requester to provide additional parameters, I could use a custom validator.

2. If I want to the use the PasswordGrantHandler as a basis for an own implementation as below with a custom grant (e.h. granttype "mypassword"), this wont work because the resourceOwnerUsername and resourceOwnerPassword is not set ==> leads to an NullPointerException in the own implemenation.

[2] can be solved in setting the parameters manually, but [1] is not easy to solve. This would involve a change in the OAuth2TokenEndpoint. Could this be solved to make future development of custom grants easier?

Br,
  Gottfried

I think your observation is correct. It is happening due to the following 
check[1] which sets the username and
password params coming in grant request only to the OAuth2AccessTokenReqDTO 
object.

For the custom grant types, all the request parameters are set to the 
OAuth2AccessTokenReqDTO as seen in [2].


[1] 
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/e9813da4110b819cfe563cdbd88d6a70064f45e0/components/org.wso2.carbon.identity.oauth.endpoint/src/main/java/org/wso2/carbon/identity/oauth/endpoint/token/OAuth2TokenEndpoint.java#L273-L273

[2] 
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/e9813da4110b819cfe563cdbd88d6a70064f45e0/components/org.wso2.carbon.identity.oauth.endpoint/src/main/java/org/wso2/carbon/identity/oauth/endpoint/token/OAuth2TokenEndpoint.java#L284


Thanks,
Farasath

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com <http://wso2.com/>
Mobile: +94777603866 <tel:%2B94777603866>
Blog: blog.farazath.com <http://blog.farazath.com>
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>

<http:///>

On Thu, Mar 23, 2017 at 1:46 AM, Gottfried Szing <gottfr...@szing.eu 
<mailto:gottfr...@szing.eu>> wrote:

    Hi

    Target WSO2 product is the WSO2 IS 5.3 and/or API manager 2.1

    I am currently implementing a set of custom grant types and one grant type 
is based on the the existing
    PasswordGrantHandler. The goal is to check in addition to the username, 
password and scope an additional,
    optional request parameter. If this parameter exists, a special response 
header should be added. So far,
    so good.

    But it does not work. I have extended the PasswordGrantHandler and check 
the requestParamers in the DTO
    like here:

    public class MyPasswordGrantHandler extends PasswordGrantHandler {

        @Override
        public boolean validateGrant(OAuthTokenReqMessageContext 
oAuthTokenReqMessageContext)
                    throws IdentityOAuth2Exception {
            // this returns null
            
oAuthTokenReqMessageContext.getOauth2AccessTokenReqDTO().getRequestParameters()

            final boolean authStatus = 
super.validateGrant(oAuthTokenReqMessageContext);

            if (authStatus) {
                    // ....
            }

            return authStatus;
        }
    }

    This works perfectly for other, self-implemented grant handlers, but not 
for this one as long as it is
    registered it in the identity.xml under the GrantTypeName = password. If I 
choose a different name, the
    same implementation works as expected.

    Any ideas, whats going on under the hood? In the sources I havent found any 
hints.

    Br & Thanks
    _______________________________________________
    Dev mailing list
    Dev@wso2.org <mailto:Dev@wso2.org>
    http://wso2.org/cgi-bin/mailman/listinfo/dev 
<http://wso2.org/cgi-bin/mailman/listinfo/dev>


_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to