+ Thilina Farasath Ahamed Software Engineer, WSO2 Inc.; http://wso2.com Mobile: +94777603866 Blog: blog.farazath.com Twitter: @farazath619 <https://twitter.com/farazath619> <http://wso2.com/signature>
On Fri, May 26, 2017 at 12:21 PM, Hasanthi Purnima Dissanayake < [email protected]> wrote: > 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: [email protected] > M :0718407133| http://wso2.com <http://wso2.com/> > > On Fri, May 26, 2017 at 11:41 AM, Isura Karunaratne <[email protected]> > 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 < >> [email protected]> 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: [email protected] >>> M :0718407133| http://wso2.com <http://wso2.com/> >>> >>> On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <[email protected]> >>> 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 < >>>> [email protected]> 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: [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/pushpalanka/ | 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: [email protected] >>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>> Blog : http://isurad.blogspot.com/ >>>> >>>> >>>> >>>> >>> >> >> >> -- >> >> *Isura Dilhara Karunaratne* >> Senior Software Engineer | WSO2 >> Email: [email protected] >> Mob : +94 772 254 810 <+94%2077%20225%204810> >> Blog : http://isurad.blogspot.com/ >> >> >> >> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
