We are planning to change the existing XACML based authorization implementation.
In the current implementation the XACML policies are generated by aggregating the following parts. 1) Target -> Resource-Id (Determined by the URL of a resource) 2) Target -> Action-Id (Determined by the HTTP verb of a resources) 3) Condition (App creator can author the condition element which whatever logic he needs) In the new implementation the policy generation part will be gone and the users should create policies using the carbon console. The main purpose of generating the policies from APPM side was to prevent a user who owns one app, from writing a XACML policy which might affect another app. Because it was APPM who generated the resource-id (relative URL of the resource) in the target of the policy. So that the users had no control over the resource-id hence there was no possibility for a creator of one app to mention a resource id of another app. So we should think of a way of enforcing this restriction, in the new implementation as well. (May be asking the policy creators to prefix the resource ids with the app UUID)That's one concern. And the other concern is, in the new implementation, the plan is to show the user, the policies list which were created using the Carbon console, when the user is going to create a policy group. So that the user can pick the policies and add them to the policy group. In other words we are going to maintain a mapping between the XACML policies refs and the APPM policy groups. But why ? When a request comes to the gateway we simply send a XACML request which contains the resource id (the http request url) and the action id (http verb). And the XACML engine would go through ALL the XACML policies to find out a policy which would match the given request. So there is not point of maintaining a mapping between the XACML policies and policy groups. Because its the XACML policy's 'target' sections which determine which policy should get engaged to a XACML request, not the mapping we are going to maintain from the APPM side. Therefore without do a mapping, shouldn't it be a simple option to say 'yes' or 'no' to XACML policy evaluation for a given APPM policy group Thoughts please ? Thanks Rushmin -- *Rushmin Fernando* *Technical Lead* WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware email : [email protected] mobile : +94772310855
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
