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 <[email protected]> wrote: > > > > On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena <[email protected]> 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]. > > <ResourceAccessControl> > <Resource context="(.*)/api/identity/user/(.*)" secured="true" > http-method="all"/> > <Resource context="(.*)/api/identity/recovery/(.*)" > secured="true" http-method="all"/> > <Resource context="(.*)/.well-known(.*)" secured="true" > http-method="all"/> > <Resource context="(.*)/identity/register(.*)" secured="true" > http-method="all"> > <Permissions>/permission/admin/manage/identity/ > applicationmgt/delete</Permissions> > </Resource> > <Resource context="(.*)/identity/connect/register(.*)" > secured="true" http-method="all"> > <Permissions>/permission/admin/manage/identity/ > applicationmgt/create</Permissions> > </Resource> > <Resource context="(.*)/oauth2/introspect(.*)" secured="true" > http-method="all"> > <Permissions> > */permission/admin/manage/identity/applicationmgt/view*</Permissions> > </Resource> > <Resource context="(.*)/api/identity/entitlement/(.*)" > secured="true" http-method="all"> > <Permissions>/permission/admin/manage/identity/pep</ > Permissions> > </Resource> > </ResourceAccessControl> > > > 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 <[email protected]> >> wrote: >> >>> How about "/oauth2/introspect" endpoint? >>> >>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Technical Lead & Product Lead of WSO2 Identity Server >>> Governance Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Manoj Gunawardena >> Tech Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> Mobile : +94 77 2291643 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- Manoj Gunawardena Tech Lead WSO2, Inc.: http://wso2.com lean.enterprise.middleware Mobile : +94 77 2291643
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
