Hi Rushmin, I sent the above reply having the impression like that the XACML policy 'yes' / 'no' option is mapped with the resource.. But since its mapped to Policy Group +1 for the change...
Thanks.. On Tue, Mar 31, 2015 at 10:55 AM, Lahiru Cooray <[email protected]> wrote: > Hi Rushmin, > > *Regarding XACML Policy assigning change.* > > Policy Groups were initially introduced to centralise the policy > combinations, where we can assign all the required policies and wrap the > combination as a policy group. > So we do not need to set policies(User Roles, Allow Anonymous, XAML > policies , etc) against each resource,instead we can map only the policy > group. > > Here what you have mentioned is technically correct. We do not need the > link between Policy Group and XACML Policies. > > But if we think end user's perspective, I think the XACML policies are > also should be included to the policy group. > Because for the end user, this is just another policy type. > So why does he need to create a policy group with all other policy > combinations and again assign the XACML policies separately? > > > i'll vote '0' for the XACML Policy assigning change.. > > Thanks.. > > > On Fri, Mar 27, 2015 at 8:54 PM, Rushmin Fernando <[email protected]> > wrote: > >> >> 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 >> >> > > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
