Role Based Access Control

The ebxmlrr server supports fine-grained or custom Access Control Policies (ACP) including Role Based Access Control (RBAC) as specified in the chapter 13 "Access Control Information Model" of the ebXML Registry Information Model Specification version 2.5 .

This features allows clients to specify custom policies (rules) for protecting access to RegistryObjects and repository items submitted by them. For example, it enables a submitter to define a custom access control policy to restrict read access to a resource (RegistryObject or RepositoryItem) to specified user(s), user group(s) and/or user role(s). It also enables a a submitter to grant Update and/or Delete access to specified user(s), user group(s) and/or user role(s).

A RegistryObject may be associated with an Access Control Policy by a special Association with the canonical associationType of ?AccessControlPolicyFor?. This association has the reference to the ExtrinsicObject representing the Access Control Policy as the value of its sourceObject and has the reference to the RegistryObject as the value of its targetObject attribute. If a RegistryObject does not have an Access Control Policy explicitly associated with it, then it is implicitly associated with the default Access Control Policy defined for the registry.

The XACML feature is not enabled in the ebxmlrr server by default. To turn the feature on you must follow these steps:

• Edit the ebxmlrr.properties file in your home directory and set to true the value of the property:
  
  ebxmlrr.security.authorization.useXACML
• Shutdown and restart the web server (e.g. Tomcat) where ebxmlrr is deployed.

The ebxmlrr project does not provide a GUI tool for authoring XACML access control policies yet. It also does not provide any special support for associating XACML access control policies to a RegistryObject. However a user may use the Registry Browser tool to define a custom ACP as follows:

• Create a custom XACML ACP using a text editor, XML Authoring tool or an XACML authoring tool.
• Validate the custom ACP using an XML Schema validation tool to avoid obscure problems.
• Submit the custom ACP like any other RepositoryItem using Registry Browser. Make sure that its objectType is specified as an XACML Policy or PolicySet.
• Perform ad hoc query "Find All My Objects" to find the custom ACP and also the object you wish to assign the ACP to.
• Multiple select both objects (resource and policy), using <control><left mouse button>.
• Browse both selected objects using <right mouse button>Browse.
• Create an Association of caninical associationType AccessControlPolicyFor with ACP as source and resource as target.
• Save both selected objects using <right mouse button>Save.

Cataloging of XML Content

The Content Cataloging feature provides the ability to selectively convert submitted RegistryObject and repository items into RegistryObject metadata, in a content specific manner.

Cataloging creates and/or updates RegistryObject metadata such as ExtrinsicObject or Classification instances. The cataloged metadata enables clients to discover the repository item based upon content from the repository item, using standard query capabilities of the registry. This is referred to as Content-based Discovery. The main benefit of the Content Cataloging feature is to enable Content-based Discovery.

The ebxmlrr server supports Default XML Content Cataloging Service as defined by section 9.10 of the ebXML Registry Services Specification version 2.5 . This service allows an XSLT style to be associated with an ObjectType. Whenever a user submits an ExtrinsicObject matching that ObjectType, the registry automatically applies the style sheet to the repository item associated with the ExtrinsicObject. The output of the style sheet must be RegistryObject instances. These registry stores these objects along with the submitted ExtrinsicObject and repository item.

There are three separate roles of users involved with this feature. Note that these the same users may play multiple roles within a use case scenario.

• The Catalog Publisher: Defines how content of this type gets cataloged.
• The Content Publisher: Submits content of this type to registry.
• The Content Consumer: Discovers and uses content of this type within the registry

• If needed, create an ObjectType Concept for the type of content if needed as a descendant of the ExtrinsicObject Concept. This is done using the ClassificationScheme Dialog in the Registry Browser.
• Create an XSLT Style Sheet to catalog XML documents that are instance documents for the ObjectType. This is done using any XSLT or XML Authoring tool or text editor. Make sure the XSLT style sheet is valid. Make sure to test it stand alone using a stylesheet aware Web Browser or an XSLT transformer engine such as xalan (shipped with ebxmlrr). For an example of what a "Catalog Definition" XSLT Style sheet looks like you may see:
  
  

  Example from HL7 Standard.
  
  Example from ebXML CPP/A Standard.
  
  

• Submit a sample Registry Browser's configuration file config.xml with one or more custom ad hoc parameterized query within the Registry Browser. The parameterized query is designed with knowledge of the catalog metadata generated by the XSLT style sheet.
• Submit the XSLT style sheet like any other RepositoryItem using Registry Browser. Make sure that its objectType is specified as XSLT.
  
  The ExtrinsicObject for the XSLT style sheet must have a required Association with associationType of ?InvocationControlFileFor?. The XSLT style sheet must be the sourceObject while the ClassificationNode in the canonical ObjectType ClassificationScheme representing the ObjectType must be the targetObject.

Content Publisher's Actions

The following steps describe how the Content publisher publishes content (referred to in abstract as the Original Content ) to the registry. Note that the Content Publisher is not aware that the registry automatically catalogs the published content.

• Create an ExtrinsicObject and assign the content to it using the Registry Browser as is normal when submitting content to registry.
• Assign an ObjectType to the ExtrinsicObject using the Concept defined by the Content Publisher for that type of content within the canonical ObjectType scheme.
• Save the ExtrinsicObject using <right mouse button>Save in Registry Browser. The registry automatically catalogs the content and saves the catalog metadata while saving the content.

Content Consumer's Actions

The following steps describe how the Content Consumer discovers the content using content-based ad hoc queries.

• Edit their personal Registry Browser configuration file:
  
  <jaxr>/src/com/sun/xml/registry/client/browser/conf/config.xml and add one or more custom ad hoc parameterized queries using the samples provided by the Catalog Publisher.
• Restart the Registry Browser, select Ad hoc Query panel, choose the newly added content specific ad hoc query. Enter parameter values and select the Find toolbar button. They have now discovered the content published by Content Publisher using the ad hoc query published by the Catalog Publisher and performed a potentially complex ad hoc content-based query without being exposed to all the gory details.

HTTP Interface to Registry

The ebxmlrr server supports the required parts of the HTTP interface specified in section 6.6.2 "QueryManager HTTP Interface" in the ebXML Registry Services Specification version 2.5 .

This features allows clients to access RegistryObjects and repository items over HTTP protocol. The syntax for the URLs for such access is defined by the specification and requires specifying the id attribute of the object. The URL syntax is exemplified below:

To access a RegistryObject with id urn:uuid:e3373a7b-4958-4e55-8820-d03a191fb76a use the following URL in a web browser (replace localhost as needed):

http://localhost:8080/ebxmlrr/registry/rest/?interface=QueryManager&method=getRegistryObject&param-id=urn:uuid:e3373a7b-4958-4e55-8820-d03a191fb76a

To access a RepositoryItem with id urn:uuid:e3373a7b-4958-4e55-8820-d03a191fb76a use the following URL in a web browser (replace localhost as needed):

http://localhost:8080/ebxmlrr/registry/rest/?interface=QueryManager&method=getRepositoryItem&param-id=urn:uuid:e3373a7b-4958-4e55-8820-d03a191fb76a

In addition the ebxmlrr server also supports a new User Defined URLs feature that is planned to be added to version 2.6 of the specifications.

User Defined URLs

Note that this feature has been proposed and accepted by the ebXML Registry TC. It will be supported in version 2.6 of the specifications.

The ebxmlrr server supports the ability for a user to specify a URL for any RegistryObject or RepositoryItem that they submit. This URL could then be used to access the object over HTTP interface as an alternative to the QueryManager parameterized URL. The benefit would be that objects could be accessible at a URL that is meaningful and memorable to the user.

Lets see how the HTTP access to the QueryManager interface and the new feature compare. The example below uses the Demo DB database created by the createDemoDB build target of ebxmlrr module.

For RegistryObjects the new feature enables us to the following URL (replace localhost with a different host if you need):

http://localhost:8080/ebxmlrr/registry/rest/pictures/nikola/zeusDescription

Compare that with pre-existing HTTP interface enabled URL:

http://localhost:8080/ebxmlrr/registry/rest/?interface=QueryManager&method=getRegistryObject&param-id=urn:uuid:e3373a7b-4958-4e55-8820-d03a191fb76a

For RepositoryItem the new feature enables the following URL:

http://localhost:8080/ebxmlrr/registry/rest/pictures/nikola/zeus

Compare that with pre-existing HTTP interface enabled URL:

http://localhost:8080/ebxmlrr/registry/rest/?interface=QueryManager&method=getRepositoryItem&param-id=urn:uuid:e3373a7b-4958-4e55-8820-d03a191fb76a

Here is how to use this new feature.

• To assign a URL to an RegistryObject a client must add a slot with name:
  
  urn:oasis:names:tc:ebxml-regrep:2.5:rim:RegistryObject:locator
  
  
• To assign a URL to an RepositoryItem a client must add a slot with name:
  
  urn:oasis:names:tc:ebxml-regrep:2.5:rim:RegistryObject:RegistryEntry:ExtrinsicObject:contentLocator
  
  
• The value of the specified Slot specified the URL. This URL suffix must be a relative URL that is relative from the base URL of the registry. For example:
  
  Base URL for Registry: http://localhost:8080/ebxmlrr/registry
  
  Implied Prefix URL for HTTP interface: http://localhost:8080/ebxmlrr/registry/rest
  
  Relative URL suffix: /pictures/nikola/zeus
  
  Resource access URL: http://localhost:8080/ebxmlrr/registry/rest//pictures/nikola/zeus
• An objects may have multiple URLs assigned to it. If so it is accessible from each URL assigned to it.
• A URL suffix must be unique across all objects within a registry.

We have not yet made code changes to Registry Browser to allow assigning URL to objects directly. Instead you must add Slots with names specified above explicitly in order to use the new feature.

Automatic user registration

The specifications do not specify how the users register their identities with the registry/repository. The registry browser provided by the ebxmlrr project provides a simple to use User Registration Wizard that can automate the process of user registration.

Although a typical user does not need to know the following gory details, Our implementation uses the following mechanism to register a new user:

1. Check whether the certificate contained in the element of path /Envelope/Header/Signature/KeyInfo/X509Data[0]/X509Certificate in the SubmitObjectsRequest message is already in the server keystore (the path is specified by ebxmlrr.security.keystoreFile property in ebxmlrr.properties).

2. If the certificate is already in the server keystore, the user has already registered with registry.

3. If the certificate is not in the keystore, the certificate is verified that it is issued by the most trusted certificate authority. Actually, when calling the SOAPSender class to make a signed request, the whole certificate chain will be attached in the signed request. Each certificate in the chain is attached as a element of path /Envelope/Header/Signature/KeyInfo/X509Data. When verifying the target certificate, a certificate chain path is tried to be built. See the section Configuring ebXMLRR in setup guide to see the configuration related to trust anchors.

4. If the verification fails, user registration fails. If the verification is successful, the server will check whether the SubmitObjectsRequest only has one user object:

When registering a new user, the id of the user object must be real UUID. Temporary id will not be accepted. In the above example SubmitObjectsRequest trying to register a new user, the organization is already existing in the registry. Like other SubmitObjectsRequest, the request can contain other objects. But it must have exactly one user object that represents the information of the newly registered user.

5. If the conditions in 4 are satisfied, the target certificate will be installed in the server keystore. Then, when next time the client submits a request to the server, the server will not start user registration process. In addition, the user object will be also inserted into registry.

Repository quota

The ebxmlrr allows you to configure the disk quota available for storing repository items. The quota is controlled by the property ebxmlrr.repository.quota in <your_home_directory>/ebxmlrr.properties.

The quota checking mechanism is very simple. If the user already submits items more than the quota, any further submission of repository items will be denied. However, before reaching the quota, the user can still submit a item of any size, even the total occupied space after submission is much bigger than the quota.

Unsigned registry response

The registry services specification specifies that all responses must be signed. However, ebxmlrr has a option to not sign the request. It is because signing a XML document, particularly if the document is big, too much memory is consumed and it takes a long time. The property ebxmlrr.interfaces.soap.signedResponse in <your_home_dir>/ebxmlrr.properties is to control this.