Implemeting Scope Validator

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Implemeting Scope Validator

Hasanthi Purnima Dissanayake
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
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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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.

Thanks,

Hasanthi Dissanayake

Software Engineer | WSO2

E: [hidden email]

M :0718407133| http://wso2.com

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Farasath Ahamed

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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.

WDYT?


Thanks,

Hasanthi Dissanayake

Software Engineer | WSO2

E: [hidden email]

M :0718407133| http://wso2.com


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Ishara Karunarathna
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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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

-Ishara 
WDYT?


Thanks,

Hasanthi Dissanayake

Software Engineer | WSO2

E: [hidden email]

M :0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: +94717996791



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Pushpalanka Jayawardhana
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Hasanthi Purnima Dissanayake
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.validators.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: [hidden email]

M :0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Pushpalanka Jayawardhana
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Hasanthi Purnima Dissanayake
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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Isura Karunaratne
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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 





--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : +94 772 254 810




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Hasanthi Purnima Dissanayake
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: [hidden email]

M :0718407133| http://wso2.com

On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 





--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810





_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Isura Karunaratne
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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 





--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810







--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : +94 772 254 810




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Hasanthi Purnima Dissanayake
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: [hidden email]

M :0718407133| http://wso2.com

On Fri, May 26, 2017 at 11:41 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 





--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810







--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810





_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Farasath Ahamed
+ Thilina

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: <a href="tel:%2B94777603866" value="+94713149860" style="font-size:12.8px;color:rgb(17,85,204)" target="_blank">+94777603866
Twitter: @farazath619




On Fri, May 26, 2017 at 12:21 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Fri, May 26, 2017 at 11:41 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 





--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810







--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Implemeting Scope Validator

Thilina Madumal
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 <[hidden email]> wrote:
+ Thilina

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: <a href="tel:%2B94777603866" value="+94713149860" style="font-size:12.8px;color:rgb(17,85,204)" target="_blank">+94777603866
Twitter: @farazath619




On Fri, May 26, 2017 at 12:21 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Fri, May 26, 2017 at 11:41 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Thu, May 25, 2017 at 11:46 AM, Isura Karunaratne <[hidden email]> 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 <[hidden email]> 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: [hidden email]

M :0718407133| http://wso2.com

On Wed, May 17, 2017 at 7:52 AM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi,

On Tue, May 16, 2017 at 10:56 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.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.validators.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com

On Tue, May 16, 2017 at 9:24 PM, Pushpalanka Jayawardhana <[hidden email]> wrote:
Hi All,

On Tue, May 16, 2017 at 8:15 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 16, 2017 at 7:38 PM, Hasanthi Purnima Dissanayake <[hidden email]> 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.validators.JDBCScopeValidator"/>
<OIDCScopeValidator class="org.wso2.carbon.identity.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: [hidden email]

M :<a href="tel:071%20840%207133" value="+94718407133" target="_blank">0718407133| http://wso2.com




--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
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/pushpalanka/ Twitter: @pushpalanka 





--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810







--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810








--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev