Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-05-01 Thread Farasath Ahamed 
On Tue, May 2, 2017 at 9:55 AM, Manoj Gunawardena  wrote:

> If permission check not provided, is it allow to all?
> Any reason for token and user info end points hasn't check permissions?
>


OAuth token endpoint, client has to authenticate using client_id ,
client_secret.
As for the userinfo endpoint it's open AFAIK.



>
>
> On Tue, May 2, 2017 at 3:02 AM, Farasath Ahamed 
> wrote:
>
>>
>>
>>
>> On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena 
>> wrote:
>>
>>> +1 for handle authorization in consistent way for all end points.
>>> Such as
>>> "/oauth2/introspect"
>>> "oauth2/userinfo"
>>>
>>> According to IS 5.3 Authentication and Authorization of REST APIS
>>> mechanism [1], what are the permission strings assign for following end
>>> points.
>>>
>>> "oauth2/token"
>>> "oauth2/revoke"
>>> "/oauth2/introspect"
>>> "oauth2/userinfo"
>>>
>>
>>
>> Of these, I think only "/oauth2/introspect" is currently protected with
>> [1].
>>
>> 
>> > http-method="all"/>
>> > secured="true" http-method="all"/>
>> > http-method="all"/>
>> > http-method="all">
>> /permission/admin/manage/identity/applicationmg
>> t/delete
>> 
>> > secured="true" http-method="all">
>> /permission/admin/manage/identity/applicationmg
>> t/create
>> 
>> > http-method="all">
>> 
>> */permission/admin/manage/identity/applicationmgt/view*
>> 
>> > secured="true" http-method="all">
>> /permission/admin/manage/identity/pep> ons>
>> 
>> 
>>
>>
>> Based on [2], AFAIU these are the required permissions,
>>
>> "oauth2/token" -->  No permission check
>>
>> "oauth2/revoke" --> /permission/admin/manage/identity/applicationmgt/view
>>
>> "oauth2/userinfo" -->  No permission check
>>
>>
>>> [1] https://docs.wso2.com/display/IS530/Authenticating+and+Autho
>>> rizing+REST+APIs
>>>
>>
>> [2] https://github.com/wso2-extensions/identity-inbound-auth
>> -oauth/blob/master/components/org.wso2.carbon.identity.oauth
>> /src/main/resources/META-INF/services.xml
>>
>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby 
>>> wrote:
>>>
 How about "/oauth2/introspect" endpoint?

 On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna 
 wrote:

> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna <
 hars...@wso2.com> wrote:

>
> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <
>> hars...@wso2.com> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
>>> wrote:
>>>
 Hi Gayan,

 What are you trying to achieve by moving the client-secret
 validation logic to the interceptor from the jax-rs layer?

>>>
>>> ​Actually, we have separate layer to pass the secured API in IS
>>> and it is common service that can be used for any product. 
>>> AppManager also
>>> using that.
>>> In here also Gayan is trying to get the security check into that
>>> common layer instead of allowing to go into the next level to 
>>> validate
>>> headers.  ​
>>>
>>
>> Are we going to use common basic authentication handler  ?
>>
>
> ​This feature is already done in IS 5.3.0 as a common point to
> handle authentication and authorization per resources as in [1].​
>
> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
> ion-authorization-common.html
>
>>
>> BTW;  Client credentials can be received as url param..  Are we
>> validating them in here ?  If it is not;  Why are we introducing two
>> validation points for same ?
>>
>> ​If we have our own way to pass authentication details,​ then we
> have to write an authentication handler to that and register.
>

 This is according to the OAuth2 spec...  It meant that we need
 another handler implementation to do it or can we use existing
 authentication handler ?

>>>
>>> ​What i meant was that we can write custom handler as well to here. ​
>>>
>> Yes.  if it is;  it must be shipped by default.
>>
> ​Gayan will do that with this implementation. ​
>
>>
>>
>>>

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-05-01 Thread Manoj Gunawardena 
If permission check not provided, is it allow to all?
Any reason for token and user info end points hasn't check permissions?

On Tue, May 2, 2017 at 3:02 AM, Farasath Ahamed  wrote:

>
>
>
> On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena  wrote:
>
>> +1 for handle authorization in consistent way for all end points.
>> Such as
>> "/oauth2/introspect"
>> "oauth2/userinfo"
>>
>> According to IS 5.3 Authentication and Authorization of REST APIS
>> mechanism [1], what are the permission strings assign for following end
>> points.
>>
>> "oauth2/token"
>> "oauth2/revoke"
>> "/oauth2/introspect"
>> "oauth2/userinfo"
>>
>
>
> Of these, I think only "/oauth2/introspect" is currently protected with
> [1].
>
> 
>  http-method="all"/>
>  secured="true" http-method="all"/>
>  http-method="all"/>
>  http-method="all">
> /permission/admin/manage/identity/
> applicationmgt/delete
> 
>  secured="true" http-method="all">
> /permission/admin/manage/identity/
> applicationmgt/create
> 
>  http-method="all">
> 
> */permission/admin/manage/identity/applicationmgt/view*
> 
>  secured="true" http-method="all">
> /permission/admin/manage/identity/pep Permissions>
> 
> 
>
>
> Based on [2], AFAIU these are the required permissions,
>
> "oauth2/token" -->  No permission check
>
> "oauth2/revoke" --> /permission/admin/manage/identity/applicationmgt/view
>
> "oauth2/userinfo" -->  No permission check
>
>
>> [1] https://docs.wso2.com/display/IS530/Authenticating+and+Autho
>> rizing+REST+APIs
>>
>
> [2] https://github.com/wso2-extensions/identity-inbound-
> auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/
> resources/META-INF/services.xml
>
>
>>
>>
>> On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby 
>> wrote:
>>
>>> How about "/oauth2/introspect" endpoint?
>>>
>>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna 
>>> wrote:
>>>
 On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna >> > wrote:
>>>

 On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <
> hars...@wso2.com> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
>> wrote:
>>
>>> Hi Gayan,
>>>
>>> What are you trying to achieve by moving the client-secret
>>> validation logic to the interceptor from the jax-rs layer?
>>>
>>
>> ​Actually, we have separate layer to pass the secured API in IS
>> and it is common service that can be used for any product. 
>> AppManager also
>> using that.
>> In here also Gayan is trying to get the security check into that
>> common layer instead of allowing to go into the next level to 
>> validate
>> headers.  ​
>>
>
> Are we going to use common basic authentication handler  ?
>

 ​This feature is already done in IS 5.3.0 as a common point to
 handle authentication and authorization per resources as in [1].​

 [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
 ion-authorization-common.html

>
> BTW;  Client credentials can be received as url param..  Are we
> validating them in here ?  If it is not;  Why are we introducing two
> validation points for same ?
>
> ​If we have our own way to pass authentication details,​ then we
 have to write an authentication handler to that and register.

>>>
>>> This is according to the OAuth2 spec...  It meant that we need
>>> another handler implementation to do it or can we use existing
>>> authentication handler ?
>>>
>>
>> ​What i meant was that we can write custom handler as well to here. ​
>>
> Yes.  if it is;  it must be shipped by default.
>
 ​Gayan will do that with this implementation. ​

>
>
>>
>>
>>
>>>
>>>



> Actually I do not see much use of changing the current validation
> model.
>
 ​This is for all the APIs in IS to handle
 authentication/authorization in common way​ and decouple it with
 implementation of each.

>>>


>
> Thanks,

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-05-01 Thread Farasath Ahamed 
On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena  wrote:

> +1 for handle authorization in consistent way for all end points.
> Such as
> "/oauth2/introspect"
> "oauth2/userinfo"
>
> According to IS 5.3 Authentication and Authorization of REST APIS
> mechanism [1], what are the permission strings assign for following end
> points.
>
> "oauth2/token"
> "oauth2/revoke"
> "/oauth2/introspect"
> "oauth2/userinfo"
>


Of these, I think only "/oauth2/introspect" is currently protected with [1].







/permission/admin/manage/identity/applicationmgt/delete



/permission/admin/manage/identity/applicationmgt/create



*/permission/admin/manage/identity/applicationmgt/view*


/permission/admin/manage/identity/pep




Based on [2], AFAIU these are the required permissions,

"oauth2/token" -->  No permission check

"oauth2/revoke" --> /permission/admin/manage/identity/applicationmgt/view

"oauth2/userinfo" -->  No permission check


> [1] https://docs.wso2.com/display/IS530/Authenticating+and+
> Authorizing+REST+APIs
>

[2]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/resources/META-INF/services.xml


>
>
> On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby 
> wrote:
>
>> How about "/oauth2/introspect" endpoint?
>>
>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna 
>> wrote:
>>
>>> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <
 hars...@wso2.com> wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
> wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret
>> validation logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS
> and it is common service that can be used for any product. AppManager 
> also
> using that.
> In here also Gayan is trying to get the security check into that
> common layer instead of allowing to go into the next level to validate
> headers.  ​
>

 Are we going to use common basic authentication handler  ?

>>>
>>> ​This feature is already done in IS 5.3.0 as a common point to
>>> handle authentication and authorization per resources as in [1].​
>>>
>>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>>> ion-authorization-common.html
>>>

 BTW;  Client credentials can be received as url param..  Are we
 validating them in here ?  If it is not;  Why are we introducing two
 validation points for same ?

 ​If we have our own way to pass authentication details,​ then we
>>> have to write an authentication handler to that and register.
>>>
>>
>> This is according to the OAuth2 spec...  It meant that we need
>> another handler implementation to do it or can we use existing
>> authentication handler ?
>>
>
> ​What i meant was that we can write custom handler as well to here. ​
>
 Yes.  if it is;  it must be shipped by default.

>>> ​Gayan will do that with this implementation. ​
>>>


>
>
>
>>
>>
>>>
>>>
>>>
 Actually I do not see much use of changing the current validation
 model.

>>> ​This is for all the APIs in IS to handle
>>> authentication/authorization in common way​ and decouple it with
>>> implementation of each.
>>>
>>
>>>
>>>

 Thanks,
 Asela.


>
>
>
>> Since both run on the same JVM, doesn't the overhead of the
>> process remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana <
>> ga...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-05-01 Thread Manoj Gunawardena 
+1 for handle authorization in consistent way for all end points.
Such as
"/oauth2/introspect"
"oauth2/userinfo"

According to IS 5.3 Authentication and Authorization of REST APIS mechanism
[1], what are the permission strings assign for following end points.

"oauth2/token"
"oauth2/revoke"
"/oauth2/introspect"
"oauth2/userinfo"

[1]
https://docs.wso2.com/display/IS530/Authenticating+and+Authorizing+REST+APIs

On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby  wrote:

> How about "/oauth2/introspect" endpoint?
>
> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna 
> wrote:
>
>> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <
>>> hars...@wso2.com> wrote:
>>>

 On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
 wrote:

> Hi Gayan,
>
> What are you trying to achieve by moving the client-secret
> validation logic to the interceptor from the jax-rs layer?
>

 ​Actually, we have separate layer to pass the secured API in IS and
 it is common service that can be used for any product. AppManager also
 using that.
 In here also Gayan is trying to get the security check into that
 common layer instead of allowing to go into the next level to validate
 headers.  ​

>>>
>>> Are we going to use common basic authentication handler  ?
>>>
>>
>> ​This feature is already done in IS 5.3.0 as a common point to handle
>> authentication and authorization per resources as in [1].​
>>
>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>> ion-authorization-common.html
>>
>>>
>>> BTW;  Client credentials can be received as url param..  Are we
>>> validating them in here ?  If it is not;  Why are we introducing two
>>> validation points for same ?
>>>
>>> ​If we have our own way to pass authentication details,​ then we
>> have to write an authentication handler to that and register.
>>
>
> This is according to the OAuth2 spec...  It meant that we need another
> handler implementation to do it or can we use existing authentication
> handler ?
>

 ​What i meant was that we can write custom handler as well to here. ​

>>> Yes.  if it is;  it must be shipped by default.
>>>
>> ​Gayan will do that with this implementation. ​
>>
>>>
>>>



>
>
>>
>>
>>
>>> Actually I do not see much use of changing the current validation
>>> model.
>>>
>> ​This is for all the APIs in IS to handle
>> authentication/authorization in common way​ and decouple it with
>> implementation of each.
>>
>
>>
>>
>>>
>>> Thanks,
>>> Asela.
>>>
>>>



> Since both run on the same JVM, doesn't the overhead of the
> process remain the same, irrespective of where it runs?
>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana <
> ga...@wso2.com> wrote:
>
>> Hi All,
>>
>> In Oauth /token endpoint and /revoke endpoint
>>
>> https://localhost:9443/oauth2/token
>> https://localhost:9443/oauth2/revoke
>>
>> required authorization with client key, client secret in basic
>> auth headers. Currently in implementation we validate those headers 
>> after
>> serving request to JAX-RS endpoints. Basically /token, /revoke 
>> endpoints
>> are unsecured. There is significant amount of processing happen even 
>> for
>> wrong client secret.
>>
>> Since we have REST API  interceptor layer In IS 5.3.0  can we use
>> it to validate client credentials ? We may need to plug an additional
>> authenticator to validate client key, client secret in basic auth 
>> headers.
>> This authenticator may conflict with basic authenticator because
>> both authenticators validate basic auth credentials different way. 
>> There
>> are two approaches to avoid the conflict.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check the
>> context inside authenticator canHandle.
>>
>> *#option 01 *
>> Increase the priority of

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-26 Thread Johann Nallathamby 
How about "/oauth2/introspect" endpoint?

On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna  wrote:

> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
 wrote:

>
> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna > > wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
>>> wrote:
>>>
 Hi Gayan,

 What are you trying to achieve by moving the client-secret
 validation logic to the interceptor from the jax-rs layer?

>>>
>>> ​Actually, we have separate layer to pass the secured API in IS and
>>> it is common service that can be used for any product. AppManager also
>>> using that.
>>> In here also Gayan is trying to get the security check into that
>>> common layer instead of allowing to go into the next level to validate
>>> headers.  ​
>>>
>>
>> Are we going to use common basic authentication handler  ?
>>
>
> ​This feature is already done in IS 5.3.0 as a common point to handle
> authentication and authorization per resources as in [1].​
>
> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
> ion-authorization-common.html
>
>>
>> BTW;  Client credentials can be received as url param..  Are we
>> validating them in here ?  If it is not;  Why are we introducing two
>> validation points for same ?
>>
>> ​If we have our own way to pass authentication details,​ then we have
> to write an authentication handler to that and register.
>

 This is according to the OAuth2 spec...  It meant that we need another
 handler implementation to do it or can we use existing authentication
 handler ?

>>>
>>> ​What i meant was that we can write custom handler as well to here. ​
>>>
>> Yes.  if it is;  it must be shipped by default.
>>
> ​Gayan will do that with this implementation. ​
>
>>
>>
>>>
>>>
>>>


>
>
>
>> Actually I do not see much use of changing the current validation
>> model.
>>
> ​This is for all the APIs in IS to handle authentication/authorization
> in common way​ and decouple it with implementation of each.
>

>
>
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>
 Since both run on the same JVM, doesn't the overhead of the process
 remain the same, irrespective of where it runs?

 Thanks,
 NuwanD.

 On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> In Oauth /token endpoint and /revoke endpoint
>
> https://localhost:9443/oauth2/token
> https://localhost:9443/oauth2/revoke
>
> required authorization with client key, client secret in basic
> auth headers. Currently in implementation we validate those headers 
> after
> serving request to JAX-RS endpoints. Basically /token, /revoke 
> endpoints
> are unsecured. There is significant amount of processing happen even 
> for
> wrong client secret.
>
> Since we have REST API  interceptor layer In IS 5.3.0  can we use
> it to validate client credentials ? We may need to plug an additional
> authenticator to validate client key, client secret in basic auth 
> headers.
> This authenticator may conflict with basic authenticator because
> both authenticators validate basic auth credentials different way. 
> There
> are two approaches to avoid the conflict.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check the
> context inside authenticator canHandle.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check
> existence of oauth application from client key.
>
> WDYT?
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Harsha Thirimanna 
On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya  wrote:

>
>
> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>>> wrote:
>>>

 On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>
>>> Hi Gayan,
>>>
>>> What are you trying to achieve by moving the client-secret
>>> validation logic to the interceptor from the jax-rs layer?
>>>
>>
>> ​Actually, we have separate layer to pass the secured API in IS and
>> it is common service that can be used for any product. AppManager also
>> using that.
>> In here also Gayan is trying to get the security check into that
>> common layer instead of allowing to go into the next level to validate
>> headers.  ​
>>
>
> Are we going to use common basic authentication handler  ?
>

 ​This feature is already done in IS 5.3.0 as a common point to handle
 authentication and authorization per resources as in [1].​

 [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
 ion-authorization-common.html

>
> BTW;  Client credentials can be received as url param..  Are we
> validating them in here ?  If it is not;  Why are we introducing two
> validation points for same ?
>
> ​If we have our own way to pass authentication details,​ then we have
 to write an authentication handler to that and register.

>>>
>>> This is according to the OAuth2 spec...  It meant that we need another
>>> handler implementation to do it or can we use existing authentication
>>> handler ?
>>>
>>
>> ​What i meant was that we can write custom handler as well to here. ​
>>
> Yes.  if it is;  it must be shipped by default.
>
​Gayan will do that with this implementation. ​

>
>
>>
>>
>>
>>>
>>>



> Actually I do not see much use of changing the current validation
> model.
>
 ​This is for all the APIs in IS to handle authentication/authorization
 in common way​ and decouple it with implementation of each.

>>>


>
> Thanks,
> Asela.
>
>
>>
>>
>>
>>> Since both run on the same JVM, doesn't the overhead of the process
>>> remain the same, irrespective of where it runs?
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi All,

 In Oauth /token endpoint and /revoke endpoint

 https://localhost:9443/oauth2/token
 https://localhost:9443/oauth2/revoke

 required authorization with client key, client secret in basic auth
 headers. Currently in implementation we validate those headers after
 serving request to JAX-RS endpoints. Basically /token, /revoke 
 endpoints
 are unsecured. There is significant amount of processing happen even 
 for
 wrong client secret.

 Since we have REST API  interceptor layer In IS 5.3.0  can we use
 it to validate client credentials ? We may need to plug an additional
 authenticator to validate client key, client secret in basic auth 
 headers.
 This authenticator may conflict with basic authenticator because
 both authenticators validate basic auth credentials different way. 
 There
 are two approaches to avoid the conflict.

 *#option 01 *
 Increase the priority of newly added authenticator and check the
 context inside authenticator canHandle.

 *#option 01 *
 Increase the priority of newly added authenticator and check
 existence of oauth application from client key.

 WDYT?

 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Asela Pathberiya 
On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna  wrote:

>
>
> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
 wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret validation
>> logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS and it
> is common service that can be used for any product. AppManager also using
> that.
> In here also Gayan is trying to get the security check into that
> common layer instead of allowing to go into the next level to validate
> headers.  ​
>

 Are we going to use common basic authentication handler  ?

>>>
>>> ​This feature is already done in IS 5.3.0 as a common point to handle
>>> authentication and authorization per resources as in [1].​
>>>
>>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>>> ion-authorization-common.html
>>>

 BTW;  Client credentials can be received as url param..  Are we
 validating them in here ?  If it is not;  Why are we introducing two
 validation points for same ?

 ​If we have our own way to pass authentication details,​ then we have
>>> to write an authentication handler to that and register.
>>>
>>
>> This is according to the OAuth2 spec...  It meant that we need another
>> handler implementation to do it or can we use existing authentication
>> handler ?
>>
>
> ​What i meant was that we can write custom handler as well to here. ​
>
Yes.  if it is;  it must be shipped by default.


>
>
>
>>
>>
>>>
>>>
>>>
 Actually I do not see much use of changing the current validation
 model.

>>> ​This is for all the APIs in IS to handle authentication/authorization
>>> in common way​ and decouple it with implementation of each.
>>>
>>
>>>
>>>

 Thanks,
 Asela.


>
>
>
>> Since both run on the same JVM, doesn't the overhead of the process
>> remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client secret in basic auth
>>> headers. Currently in implementation we validate those headers after
>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>> are unsecured. There is significant amount of processing happen even for
>>> wrong client secret.
>>>
>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
>>> to validate client credentials ? We may need to plug an additional
>>> authenticator to validate client key, client secret in basic auth 
>>> headers.
>>> This authenticator may conflict with basic authenticator because
>>> both authenticators validate basic auth credentials different way. There
>>> are two approaches to avoid the conflict.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check the
>>> context inside authenticator canHandle.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check
>>> existence of oauth application from client key.
>>>
>>> WDYT?
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Thanks & Regards,
 Asela

 ATL
 Mobile : +94 777 625 933 <+94%2077%20762%205933>
  +358 449 228 979

 http://soasecurity.org/
 http://xacmlinfo.org/

 ___
 Architecture mailing list
 Architecture@wso2.org

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Asela Pathberiya 
On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna  wrote:

>
> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>>
 Hi Gayan,

 What are you trying to achieve by moving the client-secret validation
 logic to the interceptor from the jax-rs layer?

>>>
>>> ​Actually, we have separate layer to pass the secured API in IS and it
>>> is common service that can be used for any product. AppManager also using
>>> that.
>>> In here also Gayan is trying to get the security check into that common
>>> layer instead of allowing to go into the next level to validate headers.  ​
>>>
>>
>> Are we going to use common basic authentication handler  ?
>>
>
> ​This feature is already done in IS 5.3.0 as a common point to handle
> authentication and authorization per resources as in [1].​
>
> [1] http://harshathirimanna.blogspot.com/2016/11/
> authentication-authorization-common.html
>
>>
>> BTW;  Client credentials can be received as url param..  Are we
>> validating them in here ?  If it is not;  Why are we introducing two
>> validation points for same ?
>>
>> ​If we have our own way to pass authentication details,​ then we have to
> write an authentication handler to that and register.
>

This is according to the OAuth2 spec...  It meant that we need another
handler implementation to do it or can we use existing authentication
handler ?


>
>
>
>> Actually I do not see much use of changing the current validation model.
>>
> ​This is for all the APIs in IS to handle authentication/authorization in
> common way​ and decouple it with implementation of each.
>

>
>
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>
 Since both run on the same JVM, doesn't the overhead of the process
 remain the same, irrespective of where it runs?

 Thanks,
 NuwanD.

 On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
 wrote:

> Hi All,
>
> In Oauth /token endpoint and /revoke endpoint
>
> https://localhost:9443/oauth2/token
> https://localhost:9443/oauth2/revoke
>
> required authorization with client key, client secret in basic auth
> headers. Currently in implementation we validate those headers after
> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
> are unsecured. There is significant amount of processing happen even for
> wrong client secret.
>
> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
> to validate client credentials ? We may need to plug an additional
> authenticator to validate client key, client secret in basic auth headers.
> This authenticator may conflict with basic authenticator because both
> authenticators validate basic auth credentials different way. There are 
> two
> approaches to avoid the conflict.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check the
> context inside authenticator canHandle.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check existence
> of oauth application from client key.
>
> WDYT?
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729 <+94%2077%20777%205729>

>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Harsha Thirimanna 
On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya  wrote:

>
>
> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>
>>> Hi Gayan,
>>>
>>> What are you trying to achieve by moving the client-secret validation
>>> logic to the interceptor from the jax-rs layer?
>>>
>>
>> ​Actually, we have separate layer to pass the secured API in IS and it is
>> common service that can be used for any product. AppManager also using
>> that.
>> In here also Gayan is trying to get the security check into that common
>> layer instead of allowing to go into the next level to validate headers.  ​
>>
>
> Are we going to use common basic authentication handler  ?
>

​This feature is already done in IS 5.3.0 as a common point to handle
authentication and authorization per resources as in [1].​

[1]
http://harshathirimanna.blogspot.com/2016/11/authentication-authorization-common.html

>
> BTW;  Client credentials can be received as url param..  Are we validating
> them in here ?  If it is not;  Why are we introducing two validation points
> for same ?
>
> ​If we have our own way to pass authentication details,​ then we have to
write an authentication handler to that and register.



> Actually I do not see much use of changing the current validation model.
>
​This is for all the APIs in IS to handle authentication/authorization in
common way​ and decouple it with implementation of each.



>
> Thanks,
> Asela.
>
>
>>
>>
>>
>>> Since both run on the same JVM, doesn't the overhead of the process
>>> remain the same, irrespective of where it runs?
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi All,

 In Oauth /token endpoint and /revoke endpoint

 https://localhost:9443/oauth2/token
 https://localhost:9443/oauth2/revoke

 required authorization with client key, client secret in basic auth
 headers. Currently in implementation we validate those headers after
 serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
 are unsecured. There is significant amount of processing happen even for
 wrong client secret.

 Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
 validate client credentials ? We may need to plug an additional
 authenticator to validate client key, client secret in basic auth headers.
 This authenticator may conflict with basic authenticator because both
 authenticators validate basic auth credentials different way. There are two
 approaches to avoid the conflict.

 *#option 01 *
 Increase the priority of newly added authenticator and check the
 context inside authenticator canHandle.

 *#option 01 *
 Increase the priority of newly added authenticator and check existence
 of oauth application from client key.

 WDYT?

 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Nuwan Dias 
Ok got it. So you're not trying to gain anything in terms of performance
but you get to reuse the existing code which validates the auth header.

On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret validation
>> logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS and it is
> common service that can be used for any product. AppManager also using
> that.
> In here also Gayan is trying to get the security check into that common
> layer instead of allowing to go into the next level to validate headers.  ​
>
>
>
>> Since both run on the same JVM, doesn't the overhead of the process
>> remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client secret in basic auth
>>> headers. Currently in implementation we validate those headers after
>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>> are unsecured. There is significant amount of processing happen even for
>>> wrong client secret.
>>>
>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
>>> validate client credentials ? We may need to plug an additional
>>> authenticator to validate client key, client secret in basic auth headers.
>>> This authenticator may conflict with basic authenticator because both
>>> authenticators validate basic auth credentials different way. There are two
>>> approaches to avoid the conflict.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check the context
>>> inside authenticator canHandle.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check existence
>>> of oauth application from client key.
>>>
>>> WDYT?
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Harsha Thirimanna 
On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:

> Hi Gayan,
>
> What are you trying to achieve by moving the client-secret validation
> logic to the interceptor from the jax-rs layer?
>

​Actually, we have separate layer to pass the secured API in IS and it is
common service that can be used for any product. AppManager also using
that.
In here also Gayan is trying to get the security check into that common
layer instead of allowing to go into the next level to validate headers.  ​



> Since both run on the same JVM, doesn't the overhead of the process remain
> the same, irrespective of where it runs?
>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
> wrote:
>
>> Hi All,
>>
>> In Oauth /token endpoint and /revoke endpoint
>>
>> https://localhost:9443/oauth2/token
>> https://localhost:9443/oauth2/revoke
>>
>> required authorization with client key, client secret in basic auth
>> headers. Currently in implementation we validate those headers after
>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>> are unsecured. There is significant amount of processing happen even for
>> wrong client secret.
>>
>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
>> validate client credentials ? We may need to plug an additional
>> authenticator to validate client key, client secret in basic auth headers.
>> This authenticator may conflict with basic authenticator because both
>> authenticators validate basic auth credentials different way. There are two
>> approaches to avoid the conflict.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check the context
>> inside authenticator canHandle.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check existence of
>> oauth application from client key.
>>
>> WDYT?
>>
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Nuwan Dias 
Hi Gayan,

What are you trying to achieve by moving the client-secret validation logic
to the interceptor from the jax-rs layer? Since both run on the same JVM,
doesn't the overhead of the process remain the same, irrespective of where
it runs?

Thanks,
NuwanD.

On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> In Oauth /token endpoint and /revoke endpoint
>
> https://localhost:9443/oauth2/token
> https://localhost:9443/oauth2/revoke
>
> required authorization with client key, client secret in basic auth
> headers. Currently in implementation we validate those headers after
> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
> are unsecured. There is significant amount of processing happen even for
> wrong client secret.
>
> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
> validate client credentials ? We may need to plug an additional
> authenticator to validate client key, client secret in basic auth headers.
> This authenticator may conflict with basic authenticator because both
> authenticators validate basic auth credentials different way. There are two
> approaches to avoid the conflict.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check the context
> inside authenticator canHandle.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check existence of
> oauth application from client key.
>
> WDYT?
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Validate Authorization headers for Oauth endpoints

2017-04-25 Thread Gayan Gunawardana 
Hi All,

In Oauth /token endpoint and /revoke endpoint

https://localhost:9443/oauth2/token
https://localhost:9443/oauth2/revoke

required authorization with client key, client secret in basic auth
headers. Currently in implementation we validate those headers after
serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
are unsecured. There is significant amount of processing happen even for
wrong client secret.

Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
validate client credentials ? We may need to plug an additional
authenticator to validate client key, client secret in basic auth headers.
This authenticator may conflict with basic authenticator because both
authenticators validate basic auth credentials different way. There are two
approaches to avoid the conflict.

*#option 01 *
Increase the priority of newly added authenticator and check the context
inside authenticator canHandle.

*#option 01 *
Increase the priority of newly added authenticator and check existence of
oauth application from client key.

WDYT?

-- 
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture