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. Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 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/>* >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
