On Tue, Apr 25, 2017 at 1:11 PM, Ishara Karunarathna <[email protected]> wrote:
> HI, > > On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias <[email protected]> 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. > +1 I just want to know about how we are defining the policies whether it is based on standard approach such as XACML. Yes. we need to use scope at protocol level & it is totally fine. If policies are simple as just have some kind of mapping on role-scope.. yes we can use it within API definition & do not want to make it more complex. But; it is always better; if we can have some externalizing point (some kind of authorization handler/validator) in to the implementation which may help to plug any authorization server/endpoint. Thanks, Asela. > > > -Ishara > >> >> Thanks, >> NuwanD. >> >> On Tue, Apr 25, 2017 at 10:10 AM, Harsha Thirimanna <[email protected]> >> wrote: >> >>> >>> 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 >>>> >>>> >>> >> >> >> -- >> 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 >> >> > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: [email protected], blog: isharaaruna.blogspot.com, mobile: > +94717996791 <+94%2071%20799%206791> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
