HI,
On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias <nuw...@wso2.com> wrote:
> Yes, maintaining the mappings is not an issue AFAIS. The API definition
> (Swagger) itself has the scope associated with each resource. So we just
> need a way of storing the role(s) against each scope. By default the
> product will have like say <10 scopes. So what we're looking at is a config
> with the following format.
>
> {
> "scopes": [{
> "key": "apim:add_api",
> "roles": ["creator", "admin"]
> },
> {
> "key": "apim:add_application",
> "roles": ["subscriber", "admin"]
> }
> ]
> }
>
> The above config is only required by the server, to issue the token. What
> the client (Browser) needs to render the buttons and links are the scopes
> associated with the token and the API definition (Swagger).
>
If we are only using scops and Roles, and if we are not going for
finegrain level such as attribute base restriction on this APIs I think its
ok to go with simple implementation.
Which will be easy to implement and anyone users will easily understand
stuff.
-Ishara
>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 10:10 AM, Harsha Thirimanna <hars...@wso2.com>
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> What's wrong with using OAuth2.0 scopes? The authorization requirements
>>> are simply to define which role/group is permitted to access a given
>>> resource. Which is very simply supported OOTB via scopes and the
>>> configuration is very simple as well.
>>>
>>> One of the key design principles here is to keep things simple. Because
>>> this is something almost all users of the product will be
>>> configuring/tweaking when setting up a deployment for real. I don't think
>>> everyone understands XACML. Besides, we do not need the extensive feature
>>> set offered by XACML for this particular API.
>>>
>>> Another key design principle here is to make the API generic so that
>>> anyone can easily write a UI using it. OAuth2.0 is the de facto security
>>> standard for REST APIs and anyone using a REST API understands it (now). So
>>> why move away from the standard? When developing an SPA type UI app, it is
>>> extremely easy to render (or not) buttons/links when the resource is
>>> protected via scopes. XACML makes that tougher. Actually I personally
>>> haven't figured out how to render the html on the client side unless I
>>> evaluate the XACML policy on the client side, which of course is nearly
>>> impossible I guess.
>>>
>>> Our concern was not to say any wrong about the OAuth2 scopes. Only
>> concern was we can use XACML for such a fine grained cases by getting its
>> extensibility as well. Now we have JSON based RestAPI for XACML within IS
>> as well.
>> Yes I agree that OAuth 2 story is bit simple rather than using XACML. But
>> anyway, you guys have to maintain the mapping somehow and as you said, it
>> is also not such complicated to that.
>>
>>
>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Apr 25, 2017 at 8:55 AM, Harsha Thirimanna <hars...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 21 Apr 2017 5:27 p.m., "Asela Pathberiya" <as...@wso2.com> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray <isha...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Asela,
>>>>>
>>>>> What is reason for using scopes for authorization.. ? Can't we use
>>>>> policy based approach such as XACML ?
>>>>>
>>>>> Default authentication and authorization protocol we use is oauth,
>>>>> hence we already have support for scopes in our REST APIs.
>>>>> Therefore is it straight forward to use scopes as we just need to
>>>>> validate UI components and it is not required to add the complexities we
>>>>> can have from XACML.
>>>>>
>>>>
>>>> What is the standard which defines the policies.. In scopes also; you
>>>> need to store the authorization mapping in some where.. isn't it ? Can't
>>>> we use XACML policies for that ?
>>>>
>>>>>
>>>> I also believe this is real use case of having XACML. Maintainability
>>>> wise also XACML may be easy. I don't think it will give additional
>>>> complexity ,because as Asela said anyway you must have this association in
>>>> somewhere.
>>>> Performance wise also XACML is good because of its caching layers in
>>>> different level.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> On Thu, Apr 20, 2017 at 6:22 PM, Bhathiya Jayasekara <
>>>>> bhath...@wso2.com> wrote:
>>>>>
>>>>>> Hi Ishara,
>>>>>>
>>>>>> Please see my comments inline.
>>>>>>
>>>>>> On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray <isha...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Previous versions(Before C5) of APIM Publisher, Store Apps front end
>>>>>>> validations were done based on user roles.
>>>>>>>
>>>>>>> But with C5 we think of fine graining User Interfaces by controlling
>>>>>>> access to UI components such as Add, Edit, Delete buttons/links based on
>>>>>>> the user scopes.
>>>>>>>
>>>>>>> 1. We need to find scopes associate with each action (REST api
>>>>>>> call). This can be done in two ways.
>>>>>>>
>>>>>>> - Read the scopes from swagger definition
>>>>>>>
>>>>>>> - Associate scopes with the UI component itself.
>>>>>>>
>>>>>>> IMO associate scopes with the UI component will be more efficient
>>>>>>> than processing swagger definition while rendering UI.
>>>>>>>
>>>>>>
>>>>>> Yes, on the other hand it'll be very hard to do this dynamically.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2. We need to find logged in user scopes and persists in somewhere
>>>>>>>
>>>>>>> - We can do a introspect call and get the user scopes.
>>>>>>>
>>>>>>> - We can get the roles from logged in user claims and then find
>>>>>>> scopes based on role to scopes mapping
>>>>>>>
>>>>>>> +1 for the 1st option. In the 2nd one, we're doing the same what
>>>>>> introspect service already does. So we don't have to do that again.
>>>>>>
>>>>>>> In both the cases we will need to persist these info in a browser
>>>>>>> session.
>>>>>>>
>>>>>> I believe, here you meant cookies, because in our webapps there won't
>>>>>> be a session, since ithey're completely client side apps.
>>>>>>
>>>>>>> persisting user claims will be helpful for future use cases as well.
>>>>>>>
>>>>>> I think there can be security issues of storing user claims in
>>>>>> browser cookies.
>>>>>>
>>>>>>> We can use a secure cookie with HttpOnly and Secure flags enabled to
>>>>>>> persist these data.
>>>>>>>
>>>>>> I don't think we can use HttpOnly here, because they can't be
>>>>>> accessed by JS.
>>>>>>
>>>>>>>
>>>>>>> *Implementation*
>>>>>>>
>>>>>>> There will be a common js function that accepts UI component and
>>>>>>> then it validates against user scopes. Based on that the UI component
>>>>>>> will
>>>>>>> be enabled/ disabled.
>>>>>>>
>>>>>>> Followings are the UI components that have identified to be
>>>>>>> validated among currently available UIs.
>>>>>>>
>>>>>>>
>>>>>>> *-Publisher-*
>>>>>>>
>>>>>>> 1.Create API
>>>>>>> 2. API - Edit
>>>>>>> 3. API - Delete
>>>>>>> 4.Change Policies - Update
>>>>>>> 5. Change Labels - update
>>>>>>> 6. Change LC status buttons
>>>>>>> 7. Endpoint Update
>>>>>>>
>>>>>> There will be "Endpoint - Add" too.
>>>>>>
>>>>>> Thanks,
>>>>>> Bhathiya
>>>>>>
>>>>>>> 8. Resource Add
>>>>>>> 9. Resource Save
>>>>>>> 10. Document Add
>>>>>>> 11. Document Edit/Delete
>>>>>>> 12. Create new version - Add
>>>>>>> 13. Access Controll - Not yet Available
>>>>>>> 14. Mediation - todo
>>>>>>> 15. Scripting - todo
>>>>>>>
>>>>>>> *-Store-*
>>>>>>> 1. Application - Add
>>>>>>> 2. application - View
>>>>>>> 3. application - Edit
>>>>>>> 4. application - Delete
>>>>>>> 5. Subscription - todo
>>>>>>>
>>>>>>> Appreciate your thoughts.
>>>>>>>
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Ishara Cooray
>>>>>>> Senior Software Engineer
>>>>>>> Mobile : +9477 262 9512 <077%20262%209512>
>>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>>> Lean . Enterprise . Middleware
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Bhathiya Jayasekara*
>>>>>> *Associate Technical Lead,*
>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>>
>>>>>> *Phone: +94715478185 <071%20547%208185>*
>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>>> <https://twitter.com/bhathiyax>*
>>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>
>
> --
> 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
>
>
--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware | wso2.com
email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile:
+94717996791
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
