On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias <[email protected]> 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 <[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 <+94%2077%20777%205729> > > _______________________________________________ > 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
