Isode has developed a flexible Security Label Infrastructure which has been used to support Isode's server products. The Security Label Server (SLS) provides a web server interface that exposes the capabilities of this infrastructure for integration with third-party applications. The Security Label Server saves application developers the cost of implementing security label support, provides end-users with integrated security label capabilities that can be managed consistently with Isode and non-Isode applications.

On this page you will learn about Key features of the SLS, Target applications which might make use of SLS capabilities, the web interface to the SLS and Directory configuration to support SLS deployment.

If you need to familiarise yourself with the concepts surrounding security policies, labels, clearances and access control, then we recommend you read the Isode whitepaper [Access Control using Security Labels and Security Clearance].

Target Applications

Security Label Server can be used to support both client and server applications.

Client Applications

The SLS can be used to support client applications, into which developers wish to incorporate security enforcing functionality, by providing lightweight access to security label capabilities. An example client application which might require this is an email client.

The email client queries the Security Label Server, providing it with a set of email addresses (the sender and all of the recipients).

The SLS queries the directory for security label catalogs accesible by the sender and, on receiving them, filters the labels depending on the clearances of the the recipients. The set of permissable labels that result are returned to the email client for use. For more information on this scenario, you should read the whitepaper [Easy Security Label Support for Email Clients].

An example where this has been used in practice is the Harrier client, our Android Email client. Harrier accesses the SLS for relevant labels which are then presented for use via a drop-down on the message composition screen. Below you can see both label selection on composition and the message as received.

Harrier supports multiple label formats when generating a message (ESS, X.411, NATO Confidentiality Label, Structured Text). When a message is displayed, the label is shown appropriately and clearly using label display markings. If the SIO-Label: header is used, this information will be available directly from the message header.

Server Applications

The Security Label Server can also be used by server applications, such as those that provide Security Enforcing Functionality using Security Label based access control using an Access Control Decision Function (ACDF). The diagram below illustrates how the SLS integrates into an environment using an Electronic Document & Record Management System (EDRMS) to control distribution of documents within an environment that makes use of security labels.

Further information on EDRMS as a security enforcing server application can be found in the whitepaper [Using Isode Security Label Server for EDRMS].

Key Features

The Security Label Server provides a range of capabilities including:

  • Support for a number of Text, XML, and ASN.1 (X.411 and ESS) label formats.
  • Support for a range of Security Policies, including US GENSER and NATO ACP 332.
  • Label Conversion between formats.
  • Access Control Checks against Security Clearance (which can be looked up by Security Label Server).
  • Label and Clearance management in System and Personal Catalogs.
  • Label Catalog filtering (against Security Clearance) so that only valid and appropriate Security Labels are returned.
  • SPIF Visualization, so that detailed aspects of the SPIF may be viewed
  • Built in Web UI to facilitate management of Security Label Server.
  • Use of Directory to hold Catalogs and User Security Clearance information.
  • Catalog creation and management
  • Security Label Creation, including creation from text input
  • TLS access with password and PKI (client) based authentication.
  • Support for multi-policy configurations.

These capabilities are provided in a way that hides the bulk of the complexity from the application using the server.

The SLS operates as a web service. Requests are simple text commands with XML encoded responses which can be easily analyzed by applications. It can also be used directly with a Web Browser, enabling easy visualization and management of capabilities.

The core capability provided by Security Label Server is lookup and management of System and Personal catalogs. These catalogs are retrieved by the client to provide easy selection of Security Labels (and Security Clearances) without the client needing to be aware of label syntax or semantics. The following Label Formats are supported:

  • ASN.1 Encoded Label formats:
    • ESS (used by S/MIME and STANG 4406)
    • X.411
  • XML Encoded Label formats:
    • NATO XML Confidentiality Labels (NXL)
    • Isode XML Label Format
  • Display marking, consisting of string, foreground and background colour.
  • Structured Text Labels. These are a variant on display marking, and are generated and parsed according to the security policy (SPIF). This can be used for handling complex labels in a text encoded format. These are often used in FLOT (First Line of Text) encodings and in SMTP X- Headers.

The SLS will usually be configured with an associated directory server, which may be Isode M-Vault or another directory server. The directory will hold information on users, in particular authentication information, security clearances and personal label catalogs. It can use (and optionally mandate) TLS access (https), and user authentication can use password or strong authentication based on PKI and the user’s private key. Password authentication uses the directory, and once a user is authenticated, the clearance can be obtained. Client authentication can be mandated if desired.

The SLS can configure a local domain (e.g., "") and an associated default Security Clearance. It's also possible to configure security clearances for other domains, so that clearances can be specified for partner organizations.

Security Label Catalogs returned to the user can be filtered to only return suitable Security Labels. A number of filters (checking each Security Label against one or more Security Clearances) can be applied:

  • Where the user has authenticated, the user’s own Security Clearance (from the directory) is applied.
  • A set of "recipients" (or users) can be specified using either directory name, or email address. This is used to find a clearance in the directory. If the identified user does not have an explicitly set Security Clearance, the following is done:
    • If the email address uses the local domain, the default Security Clearance is used; or
    • If the email address uses a configured domain, the associated Security Clearance is used; or
    • If none of these, then the default Security Clearance associated with the Security Policy is used.

A number of additional capabilities are provided by the Security Label Server:

  • To convert a Security Label from one format to another (e.g. from ESS to NATO Confidentiality XML Label).
  • To retrieve the Security Policy (SPIF)
  • To validate a Security Label against a set of users (this is useful to check a Security Label before sending a message, when the set of recipients has changed since the security label was selected).
  • To perform an Access Control check (ACDF) between a Security Label and either a Security Clearance or a user (with Security Clearance obtained from the directory).
  • Server-side XML to HTML translation via XSLT

Web Interface

The Security Label Server provides a Web interface that can be used directly from a browser. This enables:

  • Direct user demonstration of SLS features.
  • Configuration of capabilities.
  • Viewing and visualization of Security Policies.
  • Viewing and editing of Security Catalogs and their contents.
  • Security Label creation and display.

This capability is illustrated in the following screenshots. Note that the Security Label Server text command to drive this is shown in the top line. The data returned in XML, which could be processed by the client, but is here rendered in the browser. The rendering is driven by stylesheets, so the look and feel can be rebranded.

The first screenshot shows the default screen, illustrating a full set of catalogss, user authentication information & security clearance, default domain ( & default security clearance for that domain, and access to the security policy.

The next screenshot shows the Security Policy. This is a demonstration policy, reflecting a number of security label capabilities used in the UK. This policy is based on JSP 457 (a UK Government Policy) which in turn is based on the NATO AC/322-D(2004)0029(INV) framework.

Finally, this is an example Security Label Catalog. Note that this is filtered based on two email addresses ( and using the default domain, so the default Security Clearance from the Security Label server for is used as a filter.

Directory Configuration

The following screenshots show how information is stored in the directory to support a Security Label Server deployment. This screenshot shows Sodium which is Isode’s GUI Directory Client. This is showing the entry for the authenticated user in the above examples, which includes the Security Clearance for that user. When the user connects to Security Label Server and retrieves a Security Label Catalog, this Security Clearance is used to filter the Security Label Catalog.

This is another view of the same entry, showing the Personal Security Label Catalog. Note that Sodium can be used to modify and extend the catalog.

This final screenshot show the same Personal Security Label Catalog viewed from Security Label Server, with the data taken from the directory. The Web interface on Security Label Server can be used to modify and extend this catalog.


  • RFC 2634. Enhanced Security Services for S/MIME, P. Hoffman, June 1999.
  • ITU X.411. Message Transfer System: Abstract Service Definition and Procedures, ISO/IEC 10021-4, 1988.
  • ITU X.501 The Directory: Models, ISO/IEC 9594-2, 2008.
  • SDN 801c. Access Control Concept and Mechanism: Revision C. May 1999.
  • ACP 332. INFOSEC Technical and Implementation Guidance for Labelling of NATO Information. March 2004.