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. Thanks, NuwanD. On Tue, Apr 25, 2017 at 8:55 AM, Harsha Thirimanna <[email protected]> wrote: > > > On 21 Apr 2017 5:27 p.m., "Asela Pathberiya" <[email protected]> wrote: > > > > On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray <[email protected]> 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 <[email protected]> >> wrote: >> >>> Hi Ishara, >>> >>> Please see my comments inline. >>> >>> On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray <[email protected]> >>> 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 >>>> [email protected] >>>> 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 > [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 > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
