Hi Manoj, To be clear, the Rest API for XACML 3.0 was already there. So whatever access control that needs to happen should already be happening in this Rest endpoint. *@IAM Team*: I believe we are using the access control valve to secure this Rest endpoint?
What Isuranga has done here is to use the same standard Rest API to evaluate our permission tree. Because earlier we couldn't evaluate our permission tree without going through the SOAP API. Also we didn't want to introduce a new proprietary API as well. Regards, Johann. On Thu, Oct 12, 2017 at 8:50 PM, Manoj Gunawardena <[email protected]> wrote: > +1 for REST API. How we secure this REST API. Basic authentication? > What are the permissions required for the user to invoke to this REST API? > if we use basic authentication, the permissions should be only view the > permissions tree. > > On Thu, Oct 12, 2017 at 5:38 PM, Isuranga Perera < > [email protected]> wrote: > >> 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 >> >> > > > -- > Manoj Gunawardena > Tech Lead > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > Mobile : +94 77 2291643 > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
