Hi IAM Team, I implemented the $subject feature. Please review and merge PR for the carbon-identity framework [1] and PR [2] for Product-IS. JIRA for the feature can be found at [3].
[1] https://github.com/wso2/carbon-identity-framework/pull/1122 [2] https://github.com/wso2/product-is/pull/1406 [3] https://wso2.org/jira/browse/IDENTITY-6724 Best Regards Isuranga Perera On Wed, Oct 4, 2017 at 9:32 PM, Isuranga Perera <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Wed, Oct 4, 2017 at 7:14 PM, Johann Nallathamby <[email protected]> >> 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
