Cobalt User and Role Provisioning
Cobalt provides a web interface for provisioning users and roles in an LDAP directory. It enables easy addition and management of information to support directory white pages, XMPP deployments, email deployments and military messaging deployments.
Further details on this are provided in the whitepaper [Provisioning for Military Messaging Handling Systems].
A core Cobalt service is to provision users. This can be in support of XMPP, email or military messaging services or simply as a generic white pages provisioning to provide directory lookup and support by other applications.
Cobalt features comprehensive user management capabilities, in an easy to navigate interface. Administrators will have the ability to:
- Create new users
- Assign and reset passwords
- Delete, restore and purge users
- Lock accounts
- View and edit white pages information, including contact information and pictures
- Manage user X.509 PKI Certificates
Email & XMPP Support
Provisioned users may be configured as XMPP users and a special directory attribute may be used to identify the user. Users may also have a standard email address to support email service in conjunction with servers such as Isode M-Box.
Military Messaging Support
Cobalt provides a range of capabilities to support Formal Military Message Handling Systems (MMHS), with capabilities oriented towards support of systems using Isode’s Harrier, M-Box and M-Switch products. Capabilities provided include:
- Role based User Agents: A key characteristic of MMHS is that mailboxes are role based, with multiple users able to access a role and users able to access multiple mailboxes. Cobalt enables configuration of role based mailboxes (UAs).
- ACP 127 Support: UAs can be configured with ACP 127 attributes (RI and PLA) and also with line length, character set (ITA2/IA5) and attachment restrictions. Harrier will enforce these restrictions, which is important for messages that are transmitted using ACP 127.
- Capability Checking. Configuration of additional message capabilities of maximum message size and control of S/MIME signing/encryption.
- Military Address Lists. Military address lists are similar to email address lists, but list members are split into Action and Info recipients, in support of MMHS processing. Recipient configuration follows ACP 133 schema.
- Profiled Addresses (Organizations). MMHS messages flow between organizations. On message reception a message is sent to a Profiler, such as Isode’s M-Switch profiler which distributes the message to role based mailboxes. Cobalt allows provision of such profiled addresses that represent organizations. It also allows configuration of which roles are allowed to send messages on behalf of an organization, which Harrier picks up and presents valid choices to the role.
- Organization/Role address type. To facilitate Harrier communication between Roles (for some functions) and Organizations (for released messages), Cobalt enforces User/Role/Organization type on managed entities. This is important, as it enables a distribution list to contain organizations only (or roles only) and then appear in address book as an organization (or role).
M-Vault core server
Cobalt works with a primary M-Vault server, which holds Cobalt configuration. Commonly, this single directory server will also hold the data for all of the managed domains. For all configurations, a directory server needs to be present to hold Cobalt configuration information.
Active Directory Support
For a domain supporting users only, Cobalt can access Microsoft Active Directory with no schema changes. For such a domain, Cobalt cannot add or modify users, but can view the users that are configured in Active Directory.
This setup is important for support of MMHS where users are provisioned in Active Directory. Cobalt can then be used to configure Role Based UAs, where the role occupants are users configured in Active Directory. This enables use of Cobalt for MMHS configuration, while using Active Directory provisioned users and authentication.
Deleted users entries are moved into a separate part of the directory to active users, which enables deleted users to be restored. It also allows Cobalt to warn when a new user’s email or XMPP address conflicts with a deleted user. This allows all Cobalt configured users to be searched from a single point in the DIT which does not include deleted users.
Roles and Access Control
Cobalt Server Access to Directory
Cobalt maintains role based access control, recording which roles a given user has access to. When a user authenticates, a user with single role will simply run with that role. A user with rights to multiple roles will be given a choice of roles.
Cobalt Administrator Roles
Cobalt has two role types:
- Cobalt Administrator: Full access to all Cobalt administrator functions.
- Cobalt Viewer: Can see Cobalt configuration, but no rights to modify.
A Cobalt Administrator can assign users from any domain to either of these roles. A user not assigned to one of these roles has no access to Cobalt configuration.
Domain Administrator Roles
For each domain created by Cobalt, the following role types are supported for each domain:
- Manage Everything: Full rights for the domain, including management of domain administrators.
- Users Manager: Can add, delete and modify users.
- Roles Manager: Can add, delete and modify other Cobalt managed information for the domain.
- Users and Roles Viewer: Can view information for the domain.