I want to know all the steps for the execution of obligation by the XACML enforcement engine (PEP, PDP, PIP, PAP) and when the execution is triggered.
example of obligation:
Your medical record has been accessed by:
thanks
The XACML engine generates the obligation / advice from the Policy. The PEP (Policy Enforcement Point) - not part of the engine - is responsible for implementing / enforcing the obligation. This typically happens via code / obligation handlers which the PEP owner is responsible for.
Based on XACML 3 specification, obligation and advice expressions are triggered by a XACML engine(PDP) when evaluation of a particular node (policy set, policy or a rule) matches the decision defined in that particular node and only for a PERMIT or DENY decision.
E.g., When I have a permit rule that says, 'Alice can view medical records' and an obligation defined in the same rule which says 'Medical record has been accessed by Alice', the obligation will be triggered by the XACML engine only when the rule evaluates to a permit in this example.
It's upto PEP to use this value from PDP.
Related
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.
How can I measure the XACML PDP performance using WSO2 exactly time taken to evaluate an access control request? Is it possible to do that using Apache Jmeter?
It is probably not any different from measuring the performance of any application.
In XACML specifically you need to measure:
PEP-PDP call
PDP evaluation (including serialization / deserialization of XACML requests / responses)
PDP-PIP calls
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
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.