Hi IAM Team, I'm currently working on the solution proposed by Johann. As he suggested I just introduced a new function which takes resource-id and subject-id as arguments and evaluates the permission tree.
I will submit a PR as soon as possible. Best Regards Isuranga Perera On Wed, Oct 4, 2017 at 7:56 PM, Asela Pathberiya <as...@wso2.com> wrote: > > > On Wed, Oct 4, 2017 at 7:14 PM, Johann Nallathamby <joh...@wso2.com> > wrote: > >> Hi IAM Team, >> >> Currently we don't have $subject. What we have currently are two APIs. >> >> 1. RemoteAuthorizationManagerService.isUserAuthorized(user, resource, >> action) - a SOAP API that evaluates the permission tree. >> >> 2. XACML3.0 Rest/JSON API - a Restful API which takes a JSON payload and >> evaluates the XACML3.0 policies in the PDP. >> >> What we need to have is a Restful API to evaluate the permission tree, so >> that users can add their application permissions using the Service Provider >> UI in IS, and evaluate them by calling the Restful API from their >> application. Rather than innovating our own Rest API to do this, the best >> way would be using the XACML3.0 Rest API, because it conforms to an >> industry standard. >> >> Therefore what I am proposing is to have XACML3.0 policy shipped with IS >> 5.4.0 which will be used to evaluate the permission tree. Some of the >> considerations when designing this policy. >> >> a. A permission is the combination of resource + action. Both resource >> and action are defined attribute categories in XACML3.0. Therefore we don't >> need to define a new category for this. >> >> b. If we use the same category "Resource" to identify resources in the >> permission tree, as well as any other resources defined in any other >> policies, we may not be able to exclusively evaluate permission tree only, >> or exclusively evaluate the other policies which don't need permission >> tree. The solution for this would be to have a policy target which matches >> the action "ui.execute", which is the constant action for all our UI >> permissions, or a policy target that checks for resource startwith >> "/permission/" because all our UI permissions start with "/permission". >> >> Attached is the kind of policy I am having in mind. We can define a new >> XACML function to evaluate permission tree, that takes two arguments, >> subject-id and resource-id. This XACML function will internally invoke the >> AuthorizationManager.isUserAuthorized() OSGi service and return the >> result. >> >> Comments and suggestions are welcome. >> > > +1 This look likes a simple approach to support a standard RESTful API > for application authorization with our permission tree. > > Thanks, > Asela. > > >> >> Thanks & Regards, >> Johann. >> >> -- >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.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
