authorization - How does a XACML PEP interact with a context? -

my question has role , purpose of xacml context handler. if understand oasis xacml3.0 spec properly, pep intercepts request resource or access client app uses context handler create native xacml context object suitable pdp process. in design, have context handler global class methods create request objects , parse xml results. envision class looking this:

public static class contexthandler {     public static bool createpolicy(policytype policyname)     {         // serialize policytype xml document      }      public static policytype loadpolicy(string policyname)     {         // 1. load policy db, filesystem...         // 2. hydrate/deserialize 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 subjects, resource...         // 2. populate requesttype object         // 3. return request      } } 

the objects requesttype, attributestype , others part of xacml context.

is correct approach context handler class or have missed point of context handler?

thanks lot!

in complete xacml 2.0/3.0 implementation, real central node or bottle-neck of authorization process context handler component, neither pep nor pdp. suggested dataf-flow in official documentation shows that.

so, think first question "for simplicity's sake, approach stick context handler component inside component?" yes. , "if yes, best place pep or pdp?" well, think depends own real scenario.

in generic simple scenario, example when don't need pip, suggest stick context handler in pep domain did. , many reasons:

• you may have many peps, not single 1 only, should achieve decoupling between peps , pdp
• every pep knows own particular authorization request specifications, it's able convert native requests standard xacml requests , viceversa
• you obtain central , standard pdp not affected specific pep logic, neither pep dependencies (i.e. third party libraries), neither pep code management (i.e. changes authorization request specifications, bug fixes, new deploys, etc.)

in more complex scenario, maybe authorization requests not contain information pdp needs reach decision. in case, pdp need ask information context handler, , context handler must able access pip component retrieve user-resources-environment values. because pip usually access centralized resources, usually centralized service. pdp usually centralized service, usually pdp , pip in same domain.

in scenario, may tempted stick context handler pdp component. if so, need deal other problems because loose decoupling , features listed above in simple scenario. moreover, following xacml specifications expect standard pdp able talk through xacml messages but, if put context handler directly there, pdp start talking pep native language.