Hi All, On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[email protected]> wrote:
> intension of using scope validate is to handle OIDC support in a single > place. > > > On Tue, May 16, 2017 at 7:52 PM, Farasath Ahamed <[email protected]> > wrote: > >> >> On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake < >> [email protected]> wrote: >> >>> Hi All, >>> In our current OIDC implementation we support below four grant types and >>> issue id tokens and user info claims for all the below grant type. >>> >>> - authorization_code >>> - implicit >>> - client_credential >>> - password >>> >>> What about extension grant types like SAML2BearerGrant, JWTBearer or any >> other custom grant type we write? >> AFAIR we do issue id_tokens to any grant type when "openid" scope is >> present. >> >> >>> Among those 4 grant types that we have implemented, OIDC spec discusses >>> about only implict and authorization_code grant types. According to the >>> spec "openid" scope value is a must to Inform the Authorization Server >>> that the client is making an OpenID Connect request. So we have introduced >>> a new property in identity.xml as below and we have implemented a scope >>> validator to validate whether the grant types are authorization_code , >>> implicit or password if the scope is openid. >>> >> >>> <ScopeValidators> >>> <OAuthScopeValidatorclass="org.wso2.carbon.identity.oauth2.v >>> alidators.JDBCScopeValidator"/> >>> <OIDCScopeValidator class="org.wso2.carbon.identit >>> y.oauth2.validators.OIDCScopeValidator"/> >>> </ScopeValidators> >>> >>> So with the above property and the implementation OIDC grant types that >>> we are supporting will be authorization_code , implicit and password >>> grant types. >>> >> >> If our current implementation allows id_token generation for all types >> wouldn't this break existing clients? >> >> If our motive is to stop issuing id_token for client_credential grant >> type (which makes sense since id_token for client_credentials lacks a >> semantic value), I feel we should use a blacklisting approach in the >> OIDCScopeValidator and not issue id_token by checking if the request comes >> from the grant_type client_credentials. >> >> To keep the backward compatibility and cater customer requirements better > to get OIDC supported information from property > +1 for this > In that isn't it better to keep that property along with the grant type registration, like below. <SupportedGrantTypes> <SupportedGrantType> <GrantTypeName>authorization_code</GrantTypeName> <GrantTypeHandlerImplClass>org.wso2.carbon.identity.oauth2.token.handlers.grant.AuthorizationCodeGrantHandler</GrantTypeHandlerImplClass> *<isIdTokenAllowed>true<isIdTokenAllowed>* </SupportedGrantType> .. <SupportedGrantTypes> We can ship default configuration as the behavior we currently have, so none of the existing scenarios break. OIDC scope validator can consume this information from here. > -Ishara > >> WDYT? >> >> >>> Thanks, >>> >>> Hasanthi Dissanayake >>> >>> Software Engineer | WSO2 >>> >>> E: [email protected] >>> M :0718407133 <071%20840%207133>| http://wso2.com <http://wso2.com/> >>> >> >> > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: [email protected], blog: isharaaruna.blogspot.com, mobile: > +94717996791 <071%20799%206791> > > > -- Pushpalanka. -- Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ Mobile: +94779716248 Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
