If I define a XACML policy and provide some attributes in the policy target, do I actually need to provide an additional rule?
Yup, you need a Rule to actually say whether you want to Permit or Deny access.
From a schema validation perspective, you could have a policy with no rules, but as Craig points it out, the rule is what carries the decision. So a rule-less policy is pointless.
You need to think about the flow of logic for the policy. By defining target attributes, you are telling it what to affect, but not how. Even if you define actions in the policy target using ActionMatch, what you really did was target the Rule at Actions with a specific ActionID.
In other words, actions defined in the target of a policy identify action-related entities by matching attribute values. This still misses the mandatory Rule, which will contain action logic.
Related
In fluentvalidation you can either send the object to validate and options specifying the rulesets to run, or you can create a validationcontext and include additional data via RootContext. In my current situation, I need to do both. I need to include additional data on the RootContext and specify what validations to run. I am manually creating the validator as it is needed. Can this be accomplished?
Since a moderator deleted my answer. The following link explains how to setup the context, including the rule sets that need to be applied.
https://github.com/FluentValidation/FluentValidation/issues/1165
In short you create a rule set factory instance that is passed into the context constructor.
I'm evaluation PDP engines and at the moment I give AuthzForce Core a try. Evaluating a Request by the PDP runs pretty solid so far:
//My request and pdp configuration files
File confLocation = new File("D:/docs/XACML/AuthZForce/IIA001/pdp.xml");//pdp.xml tells the pdp where the policies xml files are
File requestFile = new File("D:/docs/XACML/AuthZForce/IIA001/Request.xml");
//I instantiate the pdp engine and the xacml parser
final PdpEngineConfiguration pdpEngineConf = PdpEngineConfiguration.getInstance(confLocation, null, null);
PdpEngineInoutAdapter<Request, Response> pdp = PdpEngineAdapters.newXacmlJaxbInoutAdapter(pdpEngineConf);
XmlUtils.XmlnsFilteringParser xacmlParserFactory = XacmlJaxbParsingUtils.getXacmlParserFactory(false).getInstance();
//I parse the request file
Object request = xacmlParserFactory.parse(requestFile.toURI().toURL());
if (request instanceof Request) {
//At this point I could access all request attributes or alter them
//I let the PDP evaluate the request
Response response = pdp.evaluate((Request) request);
//I check the results inside the response
for (Result result : response.getResults()) {
if (result.getDecision() == DecisionType.PERMIT) {
//it's permitted!
} else {
//denied!
}
}
}
Now, according to the literature like [1] I should not trust the attributes in the given request-xacml-file. Whenever possible, I have to check against a Attribute Provider (e.g. a Patient database) if the given attributes (e.g. patient birthdate) actually belong to the patient in order to prevent attacks.
Otherwise the attacker could make the patient younger in the Request in order to access the patient's record as a parent guardian.
Questions
Is checking Requests against Attribute Providers the task of a PDP or of another entitiy?
Did OASIS specify anything concrete about that issue? E.g. workflow or syntax of configuration files
Is there a way to make my pdp engine aware of Attribute Providers?
Should I just check the provided request on my own before Response response = pdp.evaluate((Request) request);?
I don't know for other XACML implementations, but regarding AuthzForce, Attribute Providers play the role of PIPs in official XACML terms (see the definition of PIP in XACML spec's Glossary), i.e. responsible for getting any additional attribute that is not in the XACML request context (it usually means they are not provided by the PEP originally), whenever the PDP needs it to evaluate the policy. This relates to steps 5-8 of XACML standard data-flow model (§3.1 of XACML 3.0 spec). Besides, if you read the XACML spec carefully, you notice that the actual entity calling the PIPs for the PDP is the so-called context handler. In practice, this is a matter of implementation, the context handler can take many forms. In AuthzForce, it is just a sub-component of the PDP, but you might have one on the PEP side as well which is application-specific, especially in a typical ABAC/XACML scenario where the PDP is a remote service from the PEP's perspective, and the PDP is possibly talking to many PEPs in completely different application environments.
As mentioned previously, for the workflow, look at section 3.1 Data-flow model in the XACML core spec. For the syntax, XACML core specification defines a syntax for policies, authorization decision requests and responses, nothing else at this point. You may find other things in XACML Profiles, but no such thing as configuration syntax, to my knowledge.
In AuthzForce, the PDP engine is made aware of Attribute Providers by the PDP configuration, i.e. the pdp.xml file in your example. You'll need two other files (XML catalog and schema) depending on the Attribute Provider you want to use. This is documented in the Using Attribute Providers section of AuthzForce Core's wiki.
Your code seems like test code to me since you are getting the xacml request from a local file so it seems you have full control over it, so no need to check further. More generally, it depends on the actual use case, really, no universal rule for that. Some attributes (like a subject-id resulting from authentication) are specific and only known by the PEP in its own app environment, so they are the responsibility of the PEP. Some other attributes are more likely the responsibility of the PDP (through attribute providers) if they can be resolved in a central way, such as attributes in a company's directory or other kind of identity repository.
In addition to #cdan's excellent response, here are a few more pointers:
Is checking Requests against Attribute Providers the task of a PDP or of another entitiy?
The PDP always trusts the information (attributes) it receives whether it be from the PEP or from the PIPs. As such the PDP need not verify values it received from a PEP by checking with a PIP. That's counter-productive an inefficient. If you cannot trust the PEP to send the right value, how can you trust it to enforce the right decision?
Did OASIS specify anything concrete about that issue? E.g. workflow or syntax of configuration files
No, we did not. PIP behavior is outside the scope of the XACML spec.
Is there a way to make my pdp engine aware of Attribute Providers?
Should I just check the provided request on my own before Response response = pdp.evaluate((Request) request);?
The PDP should be configured with PIPs. The PDP will use all the PIPs it can.
When implementing ABAC/XACML, the spec indicates you should intercept requests for sensitive data with PEPs, which route the request to PDPs (the PEPs include attributes about the subject, environment, resource and action when calling the PDP).
The PDP then determines what rules need to be evaluated for an access decision.
From Wikipedia:
https://en.wikipedia.org/wiki/XACML
XACML provides a target,[5] which is basically a set of simplified conditions for the subject, resource, and action that must be met for a policy set, policy, or rule to apply to a given request. Once a policy or policy set is found to apply to a given request, its rules are evaluated to determine the access decision and response.
Policy set, policy and rule can all contain target elements.
It's my understanding that how the PDP decides what rules in the PIP are applicable is implementation specific, but this seems like a very important part of the process-- if you miss a rule, for instance, you would not evaluate the request properly. What ways have folks implemented this? What's worked and what hasn't? (I'm reluctantly leaning towards lookups against an EAV-ish table.)
You always configure a PDP with a set of policies. You can give the PDP any number of policies and policy sets (groups of policies) but you must specify the entry point, i.e. there must be a root policy. That root policy may then contain and / or link to other policies (or policy sets).
The PDP alone decides which policies to invoke and evaluate based on the incoming request from the PEP. The PEP does not know how many policies there are. You would not miss a rule like you state in your question. It is the PDP's responsibility not to. You would not typically implement your own PDP. You would use an off-the-shelf one. There are several open-source engines e.g. SunXACML and commercial alternatives e.g. Axiomatics.
The PIP is used for attribute value retrieval, not for policy retrieval.
I wrote some obligations and advices but I was wondering if there is a widely accepted/or formal way to do this properly? In other words: Is there a standard or preferred way to use obligations and advices in ALFA?
I would really like to see an example how to define an obligation (e.g. to log every request) and its content, in a layered policy that will always be triggered (on every request) both on deny and permit?
Or do you have to define a separate obligation for every Policyset/policy and rule?
Do you have to define the exact content of such an obligation or is this depending on the functionality of the PEP?
This is a great question.
While the specification (all versions) do define the structure of an obligation and even advice in the case of XACML 3.0, the specification doesn't mention how the PEP (policy enforcement point) is to implement the obligation. All the specification mentions is what should happen if a PEP fails to implement an obligation i.e. what happens to the decision.
From a PEP code perspective, a best practice would be to write an ObligationHandler interface which you can implement for different obligations. The constructor for classes implementing the ObligationHandler interface would take the XACML request and response.
Example
obligation emailManager = "com.axiomatics.example.obligations.emailmanager"
policy documentAccess{
apply firstApplicable
rule allowAccessIfClearanceSufficient{
condition user.clearance>document.classification
permit
on permit {
obligation emailManager{
email = email
message = stringConcatenate("Employee ",
stringOneAndOnly(Attributes.subjectId),
" has obtained access to ",
stringOneAndOnly(Attributes.resourceId)
)
}
}
}
}
Other resources:
XACML Obligations
Enhancements and new features in XACML 3.0
I have a WCF service with multiple operations exposed as a RESTful API. Most operations on the service do not require authentication/authorization, but one or two do. The authorization policy I need to use is outside of my control, and is expensive to run. Therefore, I'd like to avoid using it on those operations that do not require it.
It appears that authorization policies defined in configuration must apply to the entire service - there is no way to apply them to selective operations. This means I need to come up with another mechanism to selectively apply the authorization policy to specific operations.
Operation behaviors don't help because the ServiceSecurityContext.AuthorizationPolicies collection is read-only.
Splitting my service into two contracts - authorized and unauthorized - is messy, and won't help anyway. In order to configure separate behaviors, I will need separate services (not just separate contracts implemented by the one service), so that each has a distinct name for the purposes of configuration. Separate services implies separate .svc files to point to those services, so all my RESTful URLs will change unless I have some crazy URI rewriting scheme. That seems way more work than should be required to make this happen.
I'm starting to think the only reasonable way to do this would be to write my own authorization policy that wraps the expensive one, and only call it for select operations. Of course, I'd need some way of identifying those operations, but I'll cross that bridge when I come to it.
How can I selectively apply an authorization policy to service operations? Is there an easier way?
Since no one has replied, I'm going to say there is no way to do this so I can mark as accepted. I ended up doing exactly what I said - writing a wrapper authorization policy that selectively calls the expensive authorization policy based on some configuration.