Our requirement is that i have to separate xacml policy file from default registry called wso2Registry.
so , i am trying to do this scenario using wso2-Governance Registry
but i cant get succeded on this
is anythings other then i have to do to seprate xacml policy based on Tenent so that one tenent cant see other Tenent Xacml policy file not even super tenent
I think your requirement is to isolate the entitlement(XACML) policy. You don't need a separate WSO2 G-Reg instances to do that. In default you it will save the policy at following path for all the tenant, and all the tenants have their own registry space. Therefore any other tenant/ super tenant cannot access them. /_system/governance/repository/identity/entitlement/policy/pap
Related
I basically want to use Authzforce in a multi-tenant system.
Right now, I have a single root policy that has a few PolicySetIdReference elements that point to other policy sets (per organization) but I noticed that it tries to resolve every reference element and queries the database (I set up my own version of the MongoDbBasedRefProvider). I am worried that I would needlessly load every other policy for other organizations.
<PolicySet PolicySetId="ROOT" ....>
<PolicySetIdReference>ID-for-org-1</PolicySetIdReference>
<PolicySetIdReference>ID-for-org-2</PolicySetIdReference>
</PolicySet>
Am I able to make the root policy provider check some condition(based on org) so that the policies that I check are significantly smaller? In the example above, i only want to retrieve the one for ID-for-org-1
For full multi-tenancy, I recommend to have one PDP instance per tenant, i.e. dispatch the request to a specific PdpEngine instance based on the tenant (org) ID, e.g. via a String-to-PdpEngine map or whatever, just a suggestion.
If you still want to use the same PDP engine for all tenants (i.e. handling policies for all), make sure you do all these:
Use the first-applicable policy combining algorithm in the ROOT policy (so that the evaluation stops at the first applicable policyset within).
Make sure there is a tenant/org ID attribute present in XACML requests.
Define a XACML Target in each org policyset with a Match (equal) on this tenant/org ID attribute, to make sure the policyset applies (is evaluated) only if the tenant/org-id matches.
Implement and enable a Decision Cache on the PDP.
I am exploring XACML and WSO2 to see if it fits my use cases. One of use case is to dynamically create XACML policies. I want to use role based access control system and my application allows admin users to create roles and assign permissions to these roles. Is there a way for my application to insert a policy/modify policy at run time?
Thanks
Chaitanya
PAP interface via SOAP API:
https://docs.wso2.com/display/IS540/Entitlement+with+APIs
Java example:
https://svn.wso2.org/repos/wso2/people/asela/xacml/pap/5.X.X/src/main/java/org/xacmlinfo/xacml/pap/is/PolicyAdminClient.java
Python example:
https://github.com/welkson/WSO2-PDP-CacheTest
I have followed the tutorial for enforcing policies on API calls
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
It wasn't easy but I got something up and running. I can change access to different endpoints of an API depending on the user's role.
I have a question. Here's a fictional setup to complete the tutorial:
API EduCollege, with endpoints /student/info and /staff/info (tutorial)
API Prison, with endpoints /prisoner/info and /staff/info (note that it's the same endpoint)
I write a policy EDUCollegePolicy that enables only those with role college_admin to access /staff/info (tutorial).
But there seems to be no way to restrict these college admins from accessing staff info of the prison!
The field resource only contains info about the endpoint.
Is there any way, using this setup, to limit by API?
Or does it maybe require a different JAR add-in, that would send a resource value set to API/version/endpoint instead of just /endpoint?
Oh, by the way: I couldn't set policies according to the endpoints provided in the tutorial. It doesn't seem that it's /staff/info, but I got it to work with regexp .*staff.*info.*. Not nice. I wonder what the actual resource sent from JAR to PDP is, I couldn't find it in any logs, including IDS logs (the IDS acts as PDP)
For testing purposes, We set a given policy that allows GET operations on one resource to users with Manager Role.
Then we used the "PEP TryIt" form to check how the policy was applied to users with and without the Manager role, and right after removing and adding the role. We found these two behaviors:
1) The PEP TryIt, returns Permit, for a given user who got his/her Manager role removed => Unexpected.
Only after publishing the given policy to the PDP, the system returns NotApplicable.
2) The PEP TryIt, returns NotApplicable, for a given user who got his/her Manager role reassigned => Unexpected
Only after publishing the given policy to the PDP, the system returns Permit.
Does the policy need to be published to the PDP, every time a Role is granted/removed to a given User ? Is this the expected behavior or should be considered a bug ?
Thanks!
Fermin Ordaz.
Yes.. I guess you have experienced the correct behavior.....
Carbon user store is acts an attribute finder (PIP) for the PDP. Basically Carbon user store is the default PIP implementation. In the PIP level, PDP has introduced the attribute caching. In simply, we can say that It caches the user's attribute (here user's roles). Your assignment modification, It is not known by the PIP cache. (As User store and PDP act as two separate entities) Therefore it can not invalidate the cache. That has been caused to experience above result. Basically Attribute sources (user stores or any ) are independent from the PDP and they can be running in separately. There are two way you can void this,
Once you update any attributes that is related to PIP. you can clear the attribute cache using UI or API. In UI, you can go to Entitlement-> PDP->Extension and There is icon to clear attribute cache. This has been expose via admin service.. therefore you can call this method from some external application as well.
You can disable or reduce the invalidation value of the attribute cache using entitlement.properties file which can be found at <IS_HOME>/repository/conf/security directory
PDP.AttributeCaching.Enable=true
PDP.AttributeCaching.CachingInterval=300
Also, for NotApplicable, I guess you have not enable the policy in PDP.. Once you have publish a policy to PDP.. It must be enabled to put it in to actual runtime
I am beginner for creating XACML 3.0 policies. In my case we have multiple actions for a single resource.The permissions of a single resource will be depend upon Role.Here in my case resource in the sense like "Name" and "Actions" in the sense "Read,Create,Update,Delete".
Please suggest me the best way of creating policy?
You can use policy editors to create XACML policies. There are some policy editors that are available free. If you are using WSO2 identity Server, You can find the policy editors in the management console to create the XACML policies. You can find more details about them from here. Also According to the your scenario, let me give few suggestion of creating a XACML policy
First identify the entities and their mapping.. Just think as following
Policy is going to create for Resource -- foo
Foo resource has actions -- Read,Create,Update,Delete
All actions can be preformed by role -- admin
Read action can be preformed by role -- role1
Update,Create action can be preformed by role - role2
Identify the target for policy --> This can be the entity that policy is written for, Here it is the resource; i.e "foo"
Define rules policy rule. There can be three rules (if want , we can write them in even one rule)
All action --> admin
Read action ---> role1
Update,Create -- role2
(Optional) Define the last rule as denied to avoid any other access to foo resource
I am attaching UI view of the Identity Server simple policy editor that is used to create the above scenario..(deny rule would be auto generated in this editor). once you have the template and idea, It is easy even to modify the policy using XML and see try out.