TESB Authorization XACML Policy Registry
The XACML registry stores XACML policies using JCR/Jackrabbit, which means all backends supported by Jackrabbit can be configured. As default a file based repository is used, but it can be changed to a database-based repository, for more information see Backend configuration.
The XACML registry rest interface is used by:
- The PDP which retrieves the policies needed to evaluate an authorization request.
- The PAP which supports administration of XACML policies.
The XACML registry distinguishes two types of XACML policies:
- Role policies - used to specify roles.
- Permission policies referred to by the role policies used to specify access rules.
The XACML policy registry client used by the PDP loads all role policies into the memory in advance and supports lazy loading of permission policies.
Deployment and configuration of the XACML registry
The XACML registry is deployed as two features in the TESB runtime Karaf container. There is one frontend feature: (tesb-registry-rest-atom-service) feature which installs the REST-ATOM frontend to the XACML registry. Make sure that featuresBoot in container/etc/org.apache.karaf.features.cfg includes cxf-abdera:
featuresBoot=config,ssh,management,kar,webconsole, //
spring,cxf-abdera,cxf,camel,..The Apache Jackrabbit XACML repository location is defined in container/etc/org.talend.esb.authorization.xacml.registry.server.cfg. The default location is container/xacmlrepository. Its Jackrabbit configuration is container/xacmlrepository/repository.xml. Here the storage type (file/database based) and repository access rights are specified.
Atom REST interface
The Atom REST interface is defined as follows:
@GET
@Produces({ "application/atomserv+xml" })
Response getAtomApplicationDocument();
@GET
@Path("{type}")
@Produces({ "application/atom+xml" })
ResourceCollection getResources(@PathParam("type") ResourceType type);
@GET
@Path("{type}/{id}")
@Produces({ "application/atom+xml;type=entry" })
Resource getResource(@PathParam("type") ResourceType type,
@PathParam("id") String id);
@POST
@Path("{type}")
@Consumes({ "application/atom+xml;type=entry" })
@Produces({ "application/atom+xml;type=entry" })
@CreateResourceResponse
Resource createResource(@PathParam("type") ResourceType type,
Resource resource);
@PUT
@Path("{type}/{id}")
@Consumes({ "application/atom+xml;type=entry" })
@Produces({ "application/atom+xml;type=entry" })
void updateResource(@PathParam("type") ResourceType type,
@PathParam("id") String id, Resource resource);
@DELETE
@Path("{type}/{id}")
void deleteResource(@PathParam("type") ResourceType type,
@PathParam("id") String id);
@GET
@Path("{type}/{id}/content")
@Produces({ "application/xml" })
Response getResourceContent(@PathParam("type") ResourceType type,
@PathParam("id") String id);
@PUT
@Path("{type}/{id}/content")
@Consumes({ "application/xml" })
void updateResourceContent(@PathParam("type") ResourceType type,
@PathParam("id") String id, InputStream body);
The XACML Registry Atom REST interface is very similar to the Talend Service Registry. Instead of the WSDL and Policy resource types, the XACML Registry supports resource types ROOT (for roles) and XACML (for access control definitions), but the provided service operations are the same.
The XACML Registry content model is defined analogously to the Talend Registry Content model. The XACML Registry uses Jackrabbit to persist policies. The Registry root has two subnodes, one for roles (labeled "ROOT") and one for access control definitions referenced by the roles (labeled "XACML"). Other than Talend Registry these subnodes define flat sets of policies, they are itself not hierarchical. A JCR relation between roles and access control definitions is supported by the XACML registry REST frontend but not used by the current PDP implementation.
The XACML Registry Domain Model is shown as below:
