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