The ebxmlrr project implements all the required features and nearly all optional features defined in the OASIS ebXML Registry specifications version 2.1 as defined by the OASIS ebXML Registry Technical Committee . It also implements several features of the version 2.5 of these specifications.
In addition, the server implementation has several features that are not specified by the specification. Before going through the features, you are recommended to install the ebxmlrr server first.
The following features have been implemented in the ebxmlrr server from the ebXML Registry version 2.5 specification.
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:
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:
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.
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.
Content Consumer's Actions
The following steps describe how the Content Consumer discovers the content using content-based ad hoc queries.
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):
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):
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.
The following features have been implemented in the ebxmlrr server as above and beyond the features described by the ebXML Registry version 2.1 specification.
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):
Compare that with pre-existing HTTP interface enabled URL:
For RepositoryItem the new feature enables the following URL:
Compare that with pre-existing HTTP interface enabled URL:
Here is how to use this new feature.
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.
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/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.
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.
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.