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.AuthorizationCodeGrantHandler< > /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? Thanks, Hasanthi Dissanayake Software Engineer | WSO2 E: [email protected] M :0718407133| 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.AuthorizationCodeGrantHandler< > /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 > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
