Re: [Architecture] Validate Authorization headers for Oauth endpoints
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. > >> >> >>> >>> >>> > > > >> Actually I do not see much use of changing the current validation >> model. >> >>
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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, > Asela. > > >> >> >> >>> Since both run on the same JVM, doesn't the overhead of the >>> process remain the sam
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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 secret in basic >>> auth headers. Currently in implementation we validate those headers >>> after >>> serving request to JAX-RS e
Re: [Architecture] Validate Authorization headers for Oauth endpoints
+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 newly added authenticator and check >> existence of oauth application from client key. >> >> WDYT? >>
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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 email : nuw...@wso2.com Phone : +94 777 775 729 <+94%2077%20777%205729> >>> >>> >>>
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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 >> >> > > > -- > Thanks & Regards, > Asela > > ATL > Mobile : +94 777 625 933 <+94%2077%20762%205933> >
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> _
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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. > > >> >> >> >>> 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 <+94%2077%20762%205933> > +358 449 228 979 > > http://soasecurity.org/
Re: [Architecture] Validate Authorization headers for Oauth endpoints
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
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
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 ? 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 ? Actually I do not see much use of changing the current validation model. 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 +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
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
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
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
