On Tue, May 2, 2017 at 9:55 AM, Manoj Gunawardena <man...@wso2.com> 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 <farasa...@wso2.com>
> wrote:
>
>>
>>
>>
>> On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena <man...@wso2.com>
>> 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/applicationmg
>> t/delete</Permissions>
>>         </Resource>
>>         <Resource context="(.*)/identity/connect/register(.*)"
>> secured="true" http-method="all">
>>             <Permissions>/permission/admin/manage/identity/applicationmg
>> t/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</Permissi
>> ons>
>>         </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 <joh...@wso2.com>
>>> wrote:
>>>
>>>> How about "/oauth2/introspect" endpoint?
>>>>
>>>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya <as...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna <hars...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya <as...@wso2.com>
>>>>>>> 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 <as...@wso2.com>
>>>>>>>>> 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 <nuw...@wso2.com>
>>>>>>>>>>> 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?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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/
>>>>>>>> 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/
>>>>>> 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,
>>>>
>>>> *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
>>>> Architecture@wso2.org
>>>> 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
>>> Architecture@wso2.org
>>> 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to