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/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: [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 Blog : http://isurad.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
