2.2 Sealing Server

The sealing server is a J2EE application that runs on an application server and provides sealing, unsealing, peeking, and reclassification services. Operations such as sealing content can be accomplished by uploading a file to the sealing server: the relevant metadata will be added and digitally signed, and the contents encrypted. The resultant sealed content is then returned to the caller. The sealing operations are exposed as web services. The typical use for the sealing server is for integrations that want to seal, unseal or examine sealed content. Oracle IRM Desktop users typically create sealed content on their local machines and would not use the sealing server.

The sealing server exposes two web services: the sealing web service and the desktop web service. The sealing web service allows sealed content to be manipulated (for example, sealing and unsealing content). The desktop web service allows licenses checked out to the sealing server to be queried and checked in. The desktop web service also provides classification details.

2.2.1 Sealing Web Service

The sealing server provides a number of web services operations that allow the following tasks to be performed:

Sealing unsealed content
Unsealing sealed content
Resealing or reclassifying sealed content
Peeking sealed content metadata

The sealing services WSDL file can be downloaded from the sealing server using the following URL, replacing irm.example.com with the host and port name of the sealing server:

http://irm.example.com/irm_sealing/sealing_services?wsdl

2.2.1.1 Authentication

The sealing services web service calls require authentication. The current release supports HTTP basic authentication. When rights are requested and operations performed on sealed content, they are performed as the authenticated user.

2.2.1.1.1 Setting the Username and Password using JAX-WS

There are two main ways to set the username and password with a JAX-WS generated web service proxy. The first approach requires the user name and password to be set using the java.net.Authenticator class. This approach provides a user name and password for all HTTP requests for the running JVM instance.

java.net.Authenticator.setDefault(new java.net.Authenticator() {
            @Override
            protected PasswordAuthentication getPasswordAuthentication() {
                return new PasswordAuthentication("username", "password".toCharArray());
            }
        });

The other approach is to set the user name and password directly on the web services port object. This is the approach used in the web service sample code.

java.util.Map<String, Object> requestContext = (javax.xml.ws.BindingProvider)port).getRequestContext();
        requestContext.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "username");
        requestContext.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY, "password");

2.2.1.2 Authorization

The sealing services web service calls are authorized in the same way that Oracle IRM Desktop authorizes sealed content access. The authenticated user must have a valid license that allows an appropriate feature for the specified classification.

Sealing - requires a license that allows the seal feature.

In the context classification system, this means the user has to have a role assigned that allows the seal feature.
Unsealing - requires a license that allows the save unsealed feature.

In the context classification system, this means the user has to have a role that has export constraints set as none.
Resealing - requires a license that allows the reseal feature.

In the context classification system, this means the user has to have a role that allows the reseal feature.
Reclassification - requires a license that allows the copy to feature with an appropriate trusted destination in the source classification license and the seal feature in the target classification license.

In the context classification system, this means the user has to have a role that has export constraints set as trusted with the target context being a trusted context of the source context, or that the role has export constraints set as none.
Peeking - can be performed without having a license (unless the digital signature is checked, in which case the open feature is required).

In the context classification system, this means that the user does not need a role assigned within a context.

If the same user account is used to authenticate with the sealing server and the Oracle IRM Desktop, the user may have to perform a check-in when switching between Oracle IRM Desktop and the sealing server. It is advisable to use a different user account when using the sealing server, to avoid having to check in licenses. When requests are made to the sealing server, the sealing server requests the licenses and cryptography keys for the related classification from the Oracle IRM server. These licenses are checked out to the sealing server for the authenticated user. A record of these keys and rights is stored in memory and, if the license specifies, also on the file system. These licenses and keys are then used to process the content for this call and subsequent requests relating to the same classification (for the same user). Licenses that expire are re-requested by the sealing server. License rules, such as time constraints, are fully interpreted by the sealing server. License and key details are stored per authenticated user - there is an isolated store of rights and keys for any user that uses the sealing server. This is identical to the way that Oracle IRM Desktop requests licenses and keys. Oracle IRM Desktop also has an offline database in which keys and licenses are stored.

Sealing architecture

2.2.1.3 MTOM

The sealing server supports MTOM (SOAP Message Transmission Optimization Mechanism). This web service feature allows content to be transmitted as a raw binary attachment to the SOAP message rather than using in-line base 64 encoded data. This not only reduces the amount of data sent to the server, it also allows larger files to be uploaded and downloaded. It is strongly recommended to enable MTOM support when using the sealing web service operations.

For example, when using a JAX-WS client the MTOM feature can be enabled when obtaining the port:

service.getPort(SealingServices.class, new javax.xml.ws.soap.MTOMFeature());

If MTOM support is not enabled, the uploaded file size will be limited to the available memory in the client JVM.

2.2.2 Desktop Web Service

The sealing server also exposes a number of operations for managing licenses checked out to the sealing server and listing classification details. These operations are similar to the operations a user can perform using Oracle IRM Desktop. When licenses are checked out to the sealing server, the licences cannot be used by Oracle IRM Desktop unless the device count configuration setting has been configured to allow licenses to be used on multiple devices. The desktop services web service allows licenses to be checked in from the sealing server. In the same way that Oracle IRM Desktop can list classification details (contexts) when the user wants to seal content, the sealing server also provides an operation that lists classification details.

A couple of simple diagnostic pages are also made available on the sealing server so you can find out what licenses are checked out to the sealing server, and what classifications are currently available:

http://irm.example.com/irm_sealing/licenses

http://irm.example.com/irm_sealing/classifications

The desktop services WSDL file can be downloaded from the sealing server using the following URL, replacing irm.example.com with the host and port name of the sealing server.

http://irm.example.com/irm_sealing/desktop_services?wsdl