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/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+
> 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 <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
>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
