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.
Related
How to cover following scenario using XACML (with WSO2 PDP) and PIP (if required).
In Used Car application, in particular location, salesperson are
allowed to view-update car price. They can only view cars which are
assigned to them.
Now from a xacml prespective, we can create policy for salesperson role and based on location hide the particular menus.
But what to do with the method getCarDetails(Object User){...}?
here based on UserID (salesperson) we will show the list.
How to design this with xacml Specifications?
My understanding for this is : We can use spring-security and add "salesperson" role on top of this method. But it will only restrict other users from different roles. from there I am confused that should we use database call as per our traditional applications with userid and get the list of cars or is there a way to get fine-grained access with xacml?
Your question contains 2 questions:
How do I model my policy?
How do I protect my application? (Enforce the decisions)
First of all, let's model your policy in ALFA:
Rule: A sales person can view a car if and only if the car's assigned salesperson identifier is equal to the requesting user's identity.
In ALFA, this becomes:
namespace com.axiomatics{
/**
* A sales person can view a car if and only if the car's assigned salesperson
* identifier is equal to the requesting user's identity.
*/
policy viewCars{
target clause user.role=="sales person" and actionId == "view" and objectType=="car"
apply firstApplicable
/**
*
*/
rule allowAssignedUser{
permit
condition car.assignedSalesPerson==user.identifier
}
}
}
That's your modelling sorted.
Now, with respect to the second question: how do I enforce the authorization? I would argue against mixing roles managed by Spring Security and XACML policies unless you correctly document them.
There are two approaches you can take.
Use the Multiple Decision Profile - this is part of the XACML 3.0 set of optional profiles, or
Use the Reverse Query approach - this is specific to Axiomatics only. I am not sure WSO2 supports it.
The Multiple Decision Profile (MDP) defines how you can send multiple authorization requests written in xacml to a Policy Decision Point (PDP) using a single request. This saves you several round-trips. The response you will receive will contain as many decisions as authorization requests in the original request sent. You save on transport time and on evaluation time too. Use the MDP when you know how many items you want to protect and when that number is anywhere between 1 and 1,000 but not greater (though, of course, it is always worth a try). You can read more on the MDP on the Axiomatics blog. In your case, the flow would be as follows:
Call getCarDetails(Object user).
Call the underlying db to retrieve all the cars
Call the PDP in an MDP fashion for all the records found to get a decision
Return only those records for which you had a Permit
The main drawback is that you may end up receiving thousands if not millions of records from the database. Using the MDP then is not practical.
The Reverse Query approach is interesting albeit specific to Axiomatics. It defines a new interface on top of a XACML PDP which lets you query the authorization engine in a reverse way. Instead of asking:
Can Alice view car #123?
The Reverse Query lets you ask
Which cars can Alice view?
Instead of the response being a Permit or Deny, the response is a filter expression such as a SQL statement e.g.
SELECT id FROM cars WHERE assignedSP='Alice';
All you have to do then is use the SQL statement against your database to query it and return only the entitled data. This works no matter how much data you have in your database. You can find more information on the ARQ SQL via this webinar.
I have the following scenario:
in a business workflow many decisions regarding different arguments must be taken.
eg: first check user roles, then do some business logic, then check business permission, ecc...
my question is:
assuming that on the PDP there are many policies for each of that arguments,
should the PEP do a single (big) xacml request to the PDP, containing all the attributes (eg: user roles, buisiness attributes, ecc)?
or
should the PEP do multiple (short) xacml request to the PDP, containing just one kind of attributes (eg: first call with user roles, second with business attributes, ecc..) ?
thank you
The PEP should never be aware of how many policies the PDP has let alone how they are structured. In addition, you should have one request per authorization question. If you have multiple use cases e.g.
create transaction
view transaction
print transaction
approve transaction
then you should do 4 independent XACML requests. 1 XACML request = 1 authorization request. If you created a single XACML request with a huge number of attributes, you wouldn't actually be asking 4 separate questions but rather a weird mix whereby you might be permitted if any of the provided attributes triggered a Permit (and of course that all depends on the policies and combining algorithms you have).
To save on roundtrip time (transport cost...), you can use the Multiple Decision Profile of XACML (MDP) whereby you can ask in one go:
Can the user create, view, print, approve transaction X?
The Axiomatics Policy Server implements the Multiple Decision Profile. You can read this blog post to understand how to create the request.
HTH,
David.
I am working on an API in a system that has very complex access control rules. Often times there are complex SQL queries required to determine if a user has read or write access to a particular resource. This causes a lot of complexity and redundancy in our client applications as they have to know all these rules in order to determine whether to present the user with CRUD options for each object.
My goal is to reduce much of the complexity on the client side and house all the complex logic in the API. This way new client applications written against our API can avoid re-implementing the complex access rule logic on their side when ensuring that the UI only presents valid options to the user.
I am not sure what the best way is to handle this. I'm considering two different options but I don't know if there is a better or more standard way to expose generic access information to callers of an API.
Option 1
When a caller makes a GET request on a resource entity or collection of them, every returned entity will return an _allowed_actions field attached, which is an array of actions the caller is allowed to perform on that entity. For example, requesting a Listing object may result in the following response.
GET /listing/5
{
"id": 5,
"address": "123 Foo Street",
"city": "New York",
"state": "New York",
"price": 457000,
"status": "pending",
"_allowed_actions": ["READ", "UPDATE", "DELETE"]
}
Still unsure how to relate to clients whether they have the authority to create instances of a resource entity using this method, but perhaps the client will simply need to maintain enough understanding of the permission structure to determine this on its own. The access rules around creating instances are typically less complex than the READ/UPDATE/DELETE access rules so that doesn't seem too bad.
Option 2
Create a meta-API, which clients can make requests to in order to determine what actions they can perform on each resource. For example, checking what the client can do with a listing:
GET /access-query/listing/5
{
"allowed_actions": ["READ", "UPDATE","DELETE"]
}
And checking what options are allowed for listings in general, including CREATE:
GET /access-query/listing
{
"allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]
}
The benefit of this approach is that it allows callers to have a full understanding of what they can do on every resource in a generic way. This way clients wouldn't have to understand that the "create_listing" permission AND a non-probationary user status are required required in order to create listings. They can simply query for this information ahead of time.
The downside to this approach is that it increases the amount of requests. Rather than require clients to have an understanding of the permissions logic, they now have to query once to determine what they can do and a second time to do it.
I don't particularly care for either of these methods but they're all I can come up with at the moment. Is there a better way to go about this?
What you are looking for is fine-grained, externalized authorization:
fine-grained: you want to create authorization policies that take into account multiple parameters or attributes and possibly relationships between the client (the requestor) and the targeted entity e.g. a listing in your case.
externalized: you want to decouple the business logic from the authorization logic. In your question you complain about how complex the code and the SQL statements are becoming. This is a direct consequence of not clearly separating business logic from authorization logic.
There is a model called attribute-based access control (ABAC) that defines an approach to fine-grained externalized authorization. NIST, the National Institute of Standards and Technology, has produced a report on ABAC which you can read online.
OASIS, the organization for the advancement of structured information standards, has defined a standard called XACML (eXtensible Access Control Markup Language) to implement ABAC.
XACML brings you:
an architecture as illustrated below
The policy enforcement point (PEP) intercepts your API calls. It protects your API, inspects the messages and sends an authorization request to the policy decision point (PDP).
The policy decision point (PDP) evaluates incoming authorization requests from the PEP against a set of authorization policies written in XACML. The PDP eventually reaches a Permit or Deny decision. To reach decisions it may need to look up additional attribute values from databases, web services, LDAP, or files. These are called policy information points in the architecture.
a policy language: the XACML policy language is attribute-based which means it uses attributes to define what can be allowed and what is not. For instance, you could define rules such as:
a real estate agent can see all the listings if and only if the listing location == the agent location
a real estate agent can edit a listing if and only if he/she owns the listing
a real estate agent can close a listing if and only if the listing's item is sold and if and only if the agent is the person that sold the item.
a request/response scheme: XACML also defines a way to query the PDP and to get responses back. A PDP can be queried either via single questions or via multiple questions in a single request e.g.:
Can Alice view listing 123? Yes, permit.
Can Alice view, edit, or delete listing 123? Permit; Deny; Deny.
With a XACML-based approach, you get to maintain your business logic and your API separate from the authorization logic. This has several benefits:
you can always reimplement the API and keep the same authorization model
you can easily expand your API without having to rewrite the authorization
you can change your authorization logic independently of your code
you can audit your authorization logic more easily
your authorization logic is technology-neutral. It works for REST APIs, web services, databases, and more
I recommend you check out the following resources:
the OASIS XACML website
the ALFA plugin for Eclipse - a free tool to write XACML policies.
The XACML developer community
There are both vendor and open-source implementations of XACML:
Axiomatics is a vendor solution that provides both .NET and Java XACML implementations
SunXACML is a long-standing open source Java XACML implementation
HTH,
David.
Not trying to resurrect an old question, but I came here searching for almost exactly the same thing and wanted to add a solution that I think is more RESTful.
I haven't actually implemented this but think it may help others who come here...
Your second option is very nearly what I think should be done, but instead of a get use the OPTIONS verb to your resource which will then return an "allow" header with a list of available verbs for that resource.
OPTIONS /listing/5
Assuming your resources are fine-grained enough for this to make sense, then you would know if you can make a POST/DELETE
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
Originally, I asked "How do you write a policy that requires a subject be granted access to a requested permission, where the set of allowed permissions is in an external attribute store. Can you reference an external set of permissions in a policy?" The second question has been answered in the affirmative, so I'm revising the question a bit to focus on the "how".
Can someone provide a xacml policy snippet (or even pseudo-xacml) that requires a role attribute id (will be provided by the request) to be within a set of roles which are identified by another attribute id (managed by external attribute store).
For the sake of providing a starting point, the following is an example from http://docs.oasis-open.org/xacml/2.0/XACML-2.0-OS-ALL.zip. In this case, the role is inline.
<Subject>
<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">administrator</AttributeValue>
<SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</SubjectMatch>
</Subject>
Yes, policies can be written to reference attributes that come from an external attribute store.
However, where the attributes actually come from is usually not specified in the policy itself, other than perhaps by a naming pattern in the attribute ID. In the XACML PDP reference architecture, it's the responsibility of the request context handler to resolve attribute IDs and produce values for the PDP.
It goes something like this: While evaluating a request against a set of policies, the PDP encounters an attributeID in a policy rule that it needs to form a decision about the request. The PDP asks the request context handler to get the value of that attributeID "from whereever" - the PDP doesn't care where it comes from. The request context handler may look for the attribute in the attributes provided with the request, or in any number of external attribute providers, such as LDAP or AD or SAML or plain old databases. The request handler might recognize naming patterns (like, namespace prefixes) in the attributeID to know where to obtain it.
You want your attributeIDs to be specific enough to know what they are and what they mean, but not so specific that all of your policies break when you move your attribute provider to a different machine. Policies should be configuration independent.
Ultimately, where the request handler looks for attributes is a matter of configuration of the request handler / PDP server, and will vary by product vendor.
Update: To answer the 2nd revision to this question
You would write your policy to perform a comparison between the attribute value(s) provided in the request and a list of values provided by an external source.
Keep in mind that an attribute designator returns a list of values, since the request could contain multiple attribute values for the same attributeID. You can accommodate that by either by wrapping the attribute designator in a "one-and-only" reduction function, or by using a many-to-many cross product match function that will test every member of list1 for a match in list2.
Unless you have a specific design requirement that the request is only allowed to contain one role attribute, it's best to avoid the "one-and-only" reduction since it really limits your options.
Your Xacml 2.0 policy could look something like this: (forgive syntax errors, my Xacml 2.0 is a little rusty)
<Policy [...] RuleCombiningAlgorithm="deny-unless-permit">
<Rule [...]>
<Effect>Permit</Effect>
<Condition>
<Apply FunctionId=”urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of”>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
<SubjectAttributeDesignator
AttributeId="list-of-acceptable-roles-from-external-provider-attribute-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Condition>
</Rule>
</Policy>
The Xacml function "at-least-one-member-of" takes two lists as parameters. For every item in the first list, it tests to see if that item exists in the second list. It returns true as soon as it finds at least one match.
The attribute "...example:attribute:role" from your example is the attribute you're expecting to be provided in the request. If you want to enforce that the attribute must be provided in the request, you can set MustBePresent="true" in the attribute designator.
The "list-of-acceptable-roles..." attribute is an attribute id that your PDP context handler recognizes and retrieves from some external provider. What prefix or pattern the context handler looks for and which provider it fetches from is a matter of PDP configuration.
Ideally, the naming pattern on the attribute id indicates a conceptual domain or namespace the id is associated with, but the id does not explicitly indicate the physical location or provider of the attribute value(s). For longer app lifetime with lower maintenance costs, you want to be able to change your provider implementation details without having to rewrite all of your policies.
You can have vendor-specific attribute ids that will probably only come from a single provider, you can have application-specific attribute ids that could be supplied by multiple providers but only make sense for a particular application, and you can have generic or standardized attribute ids that could come from multiple providers and be used in multiple applications. The Oasis standards body and domain-specific profiles are a good starting point for finding standardized attribute ids and their semantics or getting ideas on how to organize your own app specific ids.
Depending on your PDP and context handler implementation, it may also possible to use the "Issuer" field as a way to constrain the list of providers for an attribute. The Xacml spec doesn't say much about use of the Issuer field, but the same goals of decoupling policy from provider implementation details still holds.