Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / products / directory / directory data access /

Sodium - (Secure Open Data, Identity and User Manager)

 

Sodium is used to manage the data held in an M-Vault directory server in a secure and flexible way as well as to control secure identities of users and Isode servers.

Sodium is part of the Isode directory product set, and is ideal for use with M-Vault. It may also be used with any directory server which supports X.500 DAP (Directory Access Protocol) or LDAP Lightweight Directory Access Protocol).

Sodium capabilities include:

• Support for Strong Authentication and Signed Operations (more)
• X.509 certificate request and management functions (more)
• Secure Identity Management (more)
• M-Vault Strong Authentication Configuration (more)
• PKI Display and checking (more)
• Secure Bind Profiles (more)
• Extensive built-in schema support (more)
• Easy Browsing and Searching (more)
• Data modification, addition and checking facilities (more)
• Security Policy, Security Label and Security Clearance Capabilities (more)
• Subentry and collective Attribute Management (more)
• Identity Based Access Control Management (more)
• Password Policy controls (more)
• Bulk Load/Dump of LDIF files (more)
• Flexible template configuration (more)

Support for Strong Authentication and Signed Operations

Sodium's Bind Manager contains configuration details for stored directory server connections. Each configuration contains details of the protocol (LDAP or DAP), address details and the type of authentication being used (Anonymous, Simple or Strong).

The bind profiles can be modified at a later stage or copied for use as a template for another connection configuration. Isode whitepaper's relating to Strong Authentication can be found here.

Sodium also supports Directory signed operations: providing additional security by applying an X.509 digital signature to individual directory operations and to the results returned, you can read more about this subject in Isode's whitepaper on Directory Signed Operations.

For LDAP, TLS can be configured with either LDAP (using START-TLS) or LDAPS. For both cases, if the server returns a certificate that is not trusted, trust configuration can be set up for the connection or permanently (bind profile) shown below:

Certificate checking in the bind profile for DAP and LDAP is RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) compliant. A trust anchor can be configured for the bind profile, and CRL checking may be used.

X.509 Certificate and Secure Identity Management

Sodium simplifies the process of creating and managing certificate signing requests (CSRs) for an entry in order to create a secure identity as a PKCS#12 file containing a private key. Sodium does this by issuing that CSR to a Certificate Authority (CA) and creating identities from X.509 certificates returned from the CA.

Sodium's 'Create Identity' wizard will automatically create a Certificate Signing Request (CSR) for passing onto the CA and, when the certificate has been issued, create a PKCS#12 file representing the identity. Operations can be deferred for later action in situations where the time delay between CSR and the issuing of the certificate makes it impractical to wait.

Sodium provides help generate certificates with the correct SubjectAltName values. The starting point for generating a certificate is to use Sodium's capability to build a PKCS#10 CSR (Certificate Signing Request) that is sent to the Certificate Authority (CA) that generates the Certificate Sodium's starting point for the CSR is a directory entry that holds information on the entity to be certified. The SubjectAltName information will usually be held as attributes in the directory entry, so Sodium makes it straightforward to include SubjectAltName values derived from appropriate attributes in the directory entry. SubjectAltName values can also be manually entered into the CSR. Supported types include:

• Internet Email Address
• Domain Name  
• IP Address
• URI
• X.400 OR Address (for Users, UAs, P7 and P3; defined in X.509)
• Two XMPP forms (define in RFC 3920 Section 5.1.1):
• Client (the JID - which is the XMPP User Name)
• Server (according to the services offered

There is also support for ongoing management. SubjectAltName values in certificates stored in the directory are displayed by Sodium along with other information in the certificate. The values of SubjectAltName are checked against values in the entry in the directory. Similarly, the Subject Name is checked against the name of the entry. Any inconsistencies are clearly flagged. This enables problems to be easily detected; for example it would show where a user changed email address (as represented in the email attribute) and this change was not correctly reflected in an updated certificate. Sodium will also include a user's Security Clearance as part of the CSR and check Security Clearance value consistency with the entry. On completion of the identity creation, Sodium allows for storing the certificate information inside the directory by associating it with the entry matching that of the certificate. Sodium enables secure identity creation for:

• Full installation for users with accounts on the local system.
• Full installation for an M-Vault server running on the local system.
• Provision of files that can be used for any user or server.

Secure Identity Management

Local identities on the system can be displayed and deleted as shown above. Editing facilities would be prone to user error, so we recommend creation of new secure identity rather than modification.

M-Vault Strong Authentication Configuration

Sodium can be used to configure M-Vault's Strong Authentication configuration, once the core Secure Identity is installed. This includes specification of additional trust anchors and configuration of CRL checking shown above.

PKI Display and Checking

There is a close relationship between X.509 PKI (Public Key Infrastructure) and X.500/LDAP directory. It is common practice to store certificates, CRLs (Certificate Revocation Lists) and other PKI information in a directory. For a complex PKI with multiple Certification Authorities (CAs) there will be many entities publishing related information into the directory. This can be complex. Sodium helps to manage PKI information in the directory with two types of target user:

1. Those deploying Isode products, which make use of PKI to support digital signatures for a number of peer authentication and other security features. This is part of the management tool set in support of an Isode deployment.
2. Those operating a PKI for other purposes, and simply using Isode servers to hold the data. 

Sodium provides detailed display of PKI objects and in particular Certificates, Cross Certificate Pairs and CRLs in order to make more useful information available to the manager.

As a part of Certificate display, Sodium provides an option to verify the certificate.  This will be done using trust anchors and other verification settings from the bind profile, so multiple profiles can be defined to give different checking environments.  The checks use the same verification libraries as the Isode client and server products, so this is helpful to diagnose authentication configuration problems with Isode servers, as well as general purpose checking of PKI correctness.

The following screenshots show display of information in a CRL, and certificate verification in Sodium.

Certificate Revocation List

Certificate Verification in Sodium

Certificate Verification Result

Secure Bind Profiles

Sodium stores configured servers in a bind profile. This may be encrypted, using a key prompted for each time Sodium starts. When an encrypted profile is used, it can hold passwords and pass phrases of PKCS#12 files. This provides the convenience of not having to type passwords for each server connection, while giving good data security. Bind profiles allow setting of security and protocol parameters for each directory. Multiple profiles may be established for a single server, with different security and protocol options.

Extensive built-in schema support

Sodium includes extensive built-in schema support, including templates for military (ACP133) and aviation (ATN Directory) markets.

Attribute names and values are displayed in groups appropriate to the schema within tabs attached to the object.

Easy Browsing and Searching

Sodium's main window can support multiple tabs, which can be re-arranged and moved to additional Sodium windows.

• The Browse Tab: opened when you connect to a directory server. This is the default view that shows directory entries in a tree, structured by their distinguished name.

• Search Tab: If the user performs a search, results from that search are displayed in a Search Tab. The search tab view is similar to that of the Browse tab, but only entries matching the search filter are displayed. The screenshot below shows results for the search criteria (cn=Kate*)

• Log: Sodium will display warnings and error messages in a 'Log' tab. If there are no warnings or errors, this tab will not be displayed.

Data modification, addition and checking

Entries can be viewed and edited using the standard browser interface. The interface allows for entry removal, addition of entries at any place in the DIT or added using the current entry as a template.

There are number of editing features that make it easy to manage information in the directory. These include:

• Modifying the templates to be used for an object.
• Viewing the object in 'schema view', and selecting the object classes to be used (underlying the templates).
• Drag and drop move of sub-trees.
• Delete sub-trees.
• Copy and paste attribute values.
• Copy of DNs (Distinguished Names), to easily enter values for DN value attributes.
• Clone an existing entry, to make it easy to create a new entry based on an existing one.
• Validate DN attributes, with graphical display of object class and quick link to see the associated entry.
• "Referential Integrity Check" of sub-tree, to identify DN values that do not point to an entry in the directory.
• Syntax validation of all attributes.
• Graphical display of many structured attributes.
• Validation of expiry dates in Certificates and Certificate Revocation Lists.
• Management of the component Certificates in Cross Certificate Pairs.
• Option to display operational attributes.

Security Policy, Security Label and Security Clearance Capabilities

Sodium provides support for Security Labels, Security Policy, and Security Clearances. The above screenshot shows how Sodium displays an entry that has a Security Label. The strings displayed on the screen, tooltip, and colour are controlled by the Security Policy of the Security Label. Sodium loads the Security Policy from the M-Vault server it is managing, and can also be used to set or update that Security Policy by use an attribute in the DSA entry. Sodium provides GUI management of:

• Security Labels associated with entries in the directory.
• Security Clearances associated with Directory Users.
• Security controls for the DSA, on Security Labels associated with data that can be stored and Security Clearance of users that can bind to the directory.

Security Labels and Security Clearances can be selected from a Security Catalog, which may be configured along with the Security Policy.

Sodium is Security Policy aware, but not Security Policy enforcing. Security Policy is enforced by M-Vault.For more information on this see the following white papers:

• Access Control using Security Labels & Security Clearance
• Isode Security Policy, Security Label and Security Clearance Infrastructure

Subentry and Collective Attribute Management

X.500 directories (including LDAP) have a subentry mechanism, that allows information to be associated with a part if the directory tree. Sodium provides a mechanism to specify and edit subentries, illustrated above.

Subentries may be used to associate an attribute with multiple entries (e.g., where a phone number is shared). This mechanism is called "collective attributes", and collective attributes can be managed by Sodium.

Identity Based Access Control Management

Sodium supports management of X.500 identity based Access Control used by M-Vault. Identity based access control specifies access control based on the identity of the user connecting to the directory. This includes role based access control.   Access control can be specified for a single entry (X.500 Entry ACI), or as a "template" (prescriptive ACI) to be applied across a directory sub-tree (administrative area) using a sub-entry. M-Vault implements the X.500 "basic" and "simplified" access control functionality, which give sophisticated access control capabilities.

Sodium's Access Control UI provides full access to the capabilities of X.500 Access control. To illustrate this we have provided the content of Sodium Help Files on ACI here.

Password Policy Controls

Sodium can be used to manage password policy. It allows:

• Setting of password policy preferences.
• Choice of hash algorithm (or plain passwords).
• Management of password policy exclusions.
• Account locking.

Further information on password policy is given in the Isode white paper Password Policy for Directories.

Bulk Load/Dump of LDIF files

Sodium allows for flexible bulk load and dump of LDIF (LDAP Data Interchange Format) files. This includes the ability to load data to any part of the DIT, automatically changing names and references to other names.

In addition to Sodium, Isode provides a family of bulk load tools based on Isode's Tcldish directory scripting tool. As these are written in the Tcl scripting language, they can be easily adapted for use in slightly different environments or with different data sources. These tools support two useful formats:

1. Comma Separated Value (CSV). This format is generated by many popular applications, and is a convenient and simple means to load data.
2. LDIF. (LDAP Data Interchange Format). LDIF is a directory data format, which is likely to be standardized, and is already used by some data tools. As well as being a standard format, LDIF enables incremental loading of data into the directory.

These are client/server tools which give a great deal of flexibility and should be used where possible. Isode also provides tools for loading and dumping LDIF files directly to the M-Vault database, which are useful when the very highest performance is needed.

Flexible Template Configuration

Sodium templates are XML based, allowing new templates to be rapidly generated for specific user requirements, to modify support for current schema or to add support for new schema. Templates may be created with default values. This will be convenient where entries are often created with the same values. Where an object type has multiple templates, typically reflecting different sets of default values, the user is prompted for the choice of which template to use.