Is there a standard or preferred way to use obligations and advice in XACML and ALFA? - xacml

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

Related

Where to double-check attributes of the XACML-request against Attribute-Providers at the PDP?

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 to add dynamic authorization to JAX-RS service?

I am trying to secure REST services by adding authorisation. For example, all customers are allowed to call /rest/{custno}/machines/{machno} but they are only allowed to see the machines which they own.
I see that there are annotations like #RolesAllowed but that doesn't help in this case.
I have tried using Interceptors and this seemed to work on Websphere8.5 but is not working on Tomcat 7 or 8. The interceptor was able to get the customer info from the session and from the path and ensure that they are the same or that the user has admin rights. It was quite nice to be able to generate an overview using the annotations to see how each service is secured.
What is a typical approach to this kind of problem?
You should use abac/xacml which will provide you with
An architecture
A policy language (XACML or alfa)
A request/response protocol to query for authorization.
Let's start with the policy.
For example, all customers are allowed to call /rest/{custno}/machines/{machno} but they are only allowed to see the machines which they own.
In pseudo-policy, using ALFA, this would become
/**
* Control access to machines
*/
policyset machines{
target clause objectType == "machine"
apply firstApplicable
/**
* View machines
*/
policy viewMachines{
target clause actionId == "view"
apply firstApplicable
/**
* Users are only allowed to see the machines which they own.
*/
rule usersCanViewTheirOwnMachines{
permit
condition machine.owner == username
}
}
}
The nice thing with this approach is that you need not write any code for this. All of the authorization logic is done inside the policy.
Now, let's talk architecture. You will need:
an interceptor or policy enforcement point (PEP) which in your case would be a JAX-RS filter or interceptor. The interceptor will call out to the authorization service to verify the policies.
an authorization service also known as a Policy Decision Point (PDP) which will process the request you sent against the policies it knows such as the one you just wrote.
Additional reading
ALFA on Wikipedia
XACML Architecture
XACML on Wikipedia

How and when the XACML engine execute obligations

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.

When using ABAC security, how do you look up rules?

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.

Secure WCF Services using WIF/STS - decorate methods with required claims?

I am looking at securing some WCF services using WIF, and have read within the Identity Training Kit from Microsoft, within exercise 1, "Furthermore, you can expect developers to assign conditions via Code Access Security style calls (i.e. decorating via attributes and so on). Both capabilities will require some coding support"
(midway through this article:
http://channel9.msdn.com/Learn/Courses/IdentityTrainingCourse/WebServicesAndIdentity/WebServicesAndIdentityLab/Exercise-1-Using-Windows-Identity-Foundation-to-Handle-Authentication-and-Authorization-in-a-WCF-Ser
)
However I'm unable to find any documentation regarding how to implement a solution that makes use of this decoration approach. I don't really have any need for using the claims within the actual WCF method or business logic, but simply want to use WIF/STS to secure access to the method. Any tips on whether this is the best approach, and how to secure methods using decorations would be appreciated.
I think you can take a look at PostSharp. You can implement your cross cutting concerns using AOP and then apply them as attributes to decorate your methods. So your checks would be isolated in well knows places and the business methods would have specified in the security attributes the claims required to execute those methods.
Or, for simple cases, you can use this (I think you were referring to these):
[ClaimsPrincipalPermission(SecurityAction.Demand, Operation = "Operation1", Resource = "Resource1")]
You can also implement an IOperationInvoker. Attribute your contract, and implement with a behavior. Spin through the channels and endpoints at startup, reflect on your operations for attributes on the methods and/or parameters to setup your checks. Then apply the checks when the operation is invoked.
There are a couple of good articles around. Though I can only find the one below.
http://msdn.microsoft.com/en-us/magazine/cc163302.aspx