Hi All, We have suggested a new property <IdTokenAllowed> for the parent <SupportedGrantTypes> along with the <ScopeValidators> segment to on/off the functionality of issuing the id token for grant types. For oauthorization_code grant type we ignore this property and issue id token by default for the 'openid' scope.
Thanks, Hasanthi Dissanayake Software Engineer | WSO2 E: [email protected] M :0718407133| http://wso2.com <http://wso2.com/> On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[email protected]> wrote: > Hi, > > On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake < > [email protected]> wrote: > >> Hi Farasath, Lanka >>> >>> 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. >> >> >> IMO using "openid" scope to issue id_tokens like SAML2Bearer ,etc is not >> required. >> >> If our current implementation allows id_token generation for all types >>> wouldn't this break existing clients? >> >> >> This is an optional configuration, so we don't break any existing clients >> here. >> >> @Lanka, >> >>> >>> <SupportedGrantTypes> >>> <SupportedGrantType> >>> <GrantTypeName>authorization_code</GrantTypeName> >>> <GrantTypeHandlerImplClass>org >>> .wso2.carbon.identity.oauth2.token.handlers.grant.Authorizat >>> ionCodeGrantHandler</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. >>> >> >> We already have below configuration for the APIM for JDBC Scope >> validation. >> >> <OAuthScopeValidatorclass="org.wso2.carbon.identity.oauth2.v >> alidators.JDBCScopeValidator"/> >> >> This is backward compatible so none of the existing scenarios break. >> Customers can even plug their own validators here. As this is bit simple >> shall we proceed with the above configurations? >> > Yes, above configuration '*<isIdTokenAllowed>' *was suggested just as > the location to read whether that grant type allow issuing ID tokens. With > this configuration it allows flexibility to control IDtoken issuing for > each grant(when the specs don't enforce anything. ex. when a custom grant > is registered.) without writing more custom code. > Enforcing this property can be done through the new ' > org.wso2.carbon.identity.oauth2.validators.OIDCScopeValidator' class. > >> >> Thanks, >> >> >> >> >> >> Hasanthi Dissanayake >> >> Software Engineer | WSO2 >> >> E: [email protected] >> M :0718407133 <071%20840%207133>| http://wso2.com <http://wso2.com/> >> >> On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[email protected] >> > wrote: >> >>> 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.Authorizat >>> ionCodeGrantHandler</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/p >>> ushpalanka/ | Twitter: @pushpalanka >>> >>> >> > > > -- > 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
