Hi, Can someone please clarify, What would be the behavior for the following case.
1. Obtain an access token by providing a SAML2-Bearer Grant Type and scope is openid 2. Then call the userInfo endpoint with that access token Thanks, On Thu, Jun 15, 2017 at 4:43 PM, Farasath Ahamed <[email protected]> wrote: > + 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/ >>> >>> >>> >>> >> > -- *Thilina Madumal* *Software Engineer | **WSO2* Email: [email protected] Mobile: *+ <+94%2077%20767%201807>94 774553167* Web: <http://goog_716986954>http://wso2.com <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
