How does a XACML PEP interact with a context?

Question

My question has to do with the role and purpose of a XACML context handler. If I understand the OASIS XACML3.0 spec properly, the PEP intercepts a request for some resource or access from a client app which then uses a context handler to create a native XACML context object suitable for the PDP to process. In my design, I have the context handler as a global class with methods to create request objects and parse xml results. I envision the class looking something like this:

public static class ContextHandler
{
    public static bool CreatePolicy(PolicyType policyName)
    {
        // Serialize PolicyType to xml document

    }

    public static PolicyType LoadPolicy(string policyName)
    {
        // 1. Load policy from db, filesystem...
        // 2. Hydrate/deserialize into XACML policy object
        // 3. Return PolicyType object
    }

    public static RequestType BuildRequest(
        Dictionary<string, string> subjects,
        Dictionary<string, string> resources,
        Dictionary<string, string> actions,
        Dictionary<string, string> environment)
    {            
        // 1. Create AttributesType collection, populate with subjects, resource...
        // 2. Populate RequestType object
        // 3. Return Request

    }
}

The objects RequestType, AttributesType and others are part of the XACML context.

Is this the correct approach for the context handler class or have I completely missed the point of the context handler?

Thanks a lot!

Answer 1

In a complete XACML 2.0/3.0 implementation, the real central node or bottle-neck of all the authorization process is the Context Handler component, neither the PEP nor the PDP. The suggested dataf-flow in the official documentation clearly shows that.

So, I think the first question is "For simplicity's sake, is a good approach to stick the Context Handler component inside another component?" Yes. And then "If yes, the best place is PEP or PDP?" Well, it think it depends by your own real scenario.

In a generic simple scenario, for example when you don't need a PIP, I suggest to stick the Context Handler in the PEP domain as you did. And this for many reasons:

• you may have many PEPs, not a single one only, so you should achieve decoupling between PEPs and PDP
• every PEP knows its own particular authorization request specifications, so it's able to convert native requests into standard XACML requests and viceversa
• you obtain a central and standard PDP that is not affected by a specific PEP logic, neither by PEP dependencies (i.e. third party libraries), neither by PEP code management (i.e. changes to authorization request specifications, bug fixes, new deploys, etc.)

In a more complex scenario, maybe your authorization requests do not contain all the information PDP needs to reach a decision. In this case, PDP will need to ask for those information to the Context Handler, and the Context Handler must be able to access a PIP component to retrieve those user-resources-environment values. Because PIP usually access centralized resources, it usually is a centralized service. PDP also is usually a centralized service, so usually PDP and PIP are in the same domain.

In this scenario, you may be tempted to stick the Context Handler into the PDP component. But if you do so, you will need to deal with other problems because you loose decoupling and all the features listed above in the simple scenario. Moreover, following XACML specifications I expect a standard PDP is able to talk through XACML messages but, if you put the Context Handler directly there, PDP really start talking the PEP native language.

Answer 2

I consider the context handler to be part of the PDP. The PEP intercepts a SOAP call, extracts parameter values, composes a standardized request using those values, and sends the request to the PDP. The PDP extracts the parameter values from that request, looks up additional values by querying some PIPs, matches the request against its policies to reach a decision, and composes a standardized response that is sent back to the PEP.

Answer 3

Yes. I also hope that context handler to be part of the PDP. PEP can be with your application where it intercepts your requests and ask authorization decision from the PDP. You can find open source XACML 3.0. implementation called "Balana" (improvement of sun-xacml) from here which is used by WSO2 Identity Server as it's XACML engine. From its source, You can find the ctx classes that elaborate the implementation of context handler. Also this blog would help you to understand new things with XACML 3.0.