On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya <[email protected]> wrote:
> > > On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna <[email protected]> > wrote: > >> >> >> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya <[email protected]> wrote: >> >>> >>> >>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna <[email protected]> >>> wrote: >>> >>>> >>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias <[email protected]> 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 <[email protected]> >>>>>>> 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: [email protected] >>>>>>>> Mobile: +94 (71) 8020933 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
