Hi Isura, As we discussed, client credential grant type should not return an ID > token. So, we have to change the identity.xml file to enable scope > validator by default and make IdTokenAllowed=true in implicit and > password grant handlers. >
+1 Thanks, Hasanthi Dissanayake Software Engineer | WSO2 E: hasan...@wso2.com M :0718407133| http://wso2.com <http://wso2.com/> On Fri, May 26, 2017 at 11:41 AM, Isura Karunaratne <is...@wso2.com> wrote: > Hi Hasanthi, > > As we discussed, client credential grant type should not return an ID > token. So, we have to change the identity.xml file to enable scope > validator by default and make IdTokenAllowed=true in implicit and > password grant handlers. > > Thanks > Isura. > > > On Fri, May 26, 2017 at 7:18 AM, Hasanthi Purnima Dissanayake < > hasan...@wso2.com> wrote: > >> Hi Isura, >> >> If the scope validator is enabled and IdTokenAllowed is not defined for >> a grant type, other than authorization_code grant it wont return any id >> token. >> >> Thanks, >> >> Hasanthi Dissanayake >> >> Software Engineer | WSO2 >> >> E: hasan...@wso2.com >> M :0718407133| http://wso2.com <http://wso2.com/> >> >> On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <is...@wso2.com> >> wrote: >> >>> Hi Hasanthi, >>> >>> If the property IdTokenAllowed is not defined for a grant type, what is >>> the default behavior? >>> >>> Thanks >>> Isura. >>> >>> On Wed, May 17, 2017 at 3:29 PM, Hasanthi Purnima Dissanayake < >>> hasan...@wso2.com> wrote: >>> >>>> 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: hasan...@wso2.com >>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>> >>>> On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana < >>>> la...@wso2.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake < >>>>> hasan...@wso2.com> 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: hasan...@wso2.com >>>>>> M :0718407133 <071%20840%207133>| http://wso2.com <http://wso2.com/> >>>>>> >>>>>> On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana < >>>>>> la...@wso2.com> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna < >>>>>>> isha...@wso2.com> 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 < >>>>>>>> farasa...@wso2.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake < >>>>>>>>> hasan...@wso2.com> 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: hasan...@wso2.com >>>>>>>>>> M :0718407133 <071%20840%207133>| http://wso2.com >>>>>>>>>> <http://wso2.com/> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ishara Karunarathna >>>>>>>> Associate Technical Lead >>>>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>>> >>>>>>>> email: isha...@wso2.com, 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/p >>>>> ushpalanka/ | Twitter: @pushpalanka >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> *Isura Dilhara Karunaratne* >>> Senior Software Engineer | WSO2 >>> Email: is...@wso2.com >>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>> Blog : http://isurad.blogspot.com/ >>> >>> >>> >>> >> > > > -- > > *Isura Dilhara Karunaratne* > Senior Software Engineer | WSO2 > Email: is...@wso2.com > Mob : +94 772 254 810 <+94%2077%20225%204810> > Blog : http://isurad.blogspot.com/ > > > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
