If a Broker client has an identity (a distinguished name or DN) and an authenticator name (the issuer DN of the client's SSL certificate), the Broker automatically requests an access label for the client when establishing a client session, if an access label adapter (ALA) is available.

The ALA is a custom Java API program that uses a client on the system-defined accessLabelAdapter client group. It is not necessary for an ALA to create subscriptions.

The accessLabelAdapter client group has a life cycle of destroy on disconnect and storage type of volatile. You can place an Access Control List (ACL) on the accessLabelAdapter client group to control the access to this client group by ALAs.

The primary function of the ALA is to receive access label lookup documents (Broker::ALA::lookup) from the Broker, retrieve the access label from storage, and reply with access labels. A secondary function is to update or revoke access labels that the Broker already has.

The client access labels are usually stored in a file or a database as key-value pairs. The key fields for an access label are as follows:

The hint field allows a unique user DN, authenticator DN, and certificate serial number combination to have multiple access labels. If you use hint strings as a key field in the lookup table, then you must supply the appropriate hint strings (through BrokerConnectionDescriptor) when creating Broker clients.

Multiple ALAs can be connected to a single Broker and a single ALA can be connected to multiple Brokers. When multiple ALAs are connected to a single Broker, the Broker locates the ALA that contains the access label for a particular user. If multiple ALAs contain access labels for the same user, the Broker will use the value returned by the first ALA that it contacts.