The micro broker offers three types of security.
- Encryption: All network data transfer between clients and micro broker can be encrypted.
- Authentication: An authentication mechanism ensures the identity of both clients and micro broker.
- Authorization: Clients may only access the broker, individual topics, and queues if they are authorized to do so.
The micro broker takes a key role in the security architecture. It is the guardian of the topic and queue space that provides both authentication as well as authorization. When a client connects, the client must authenticate itself to the broker. If successful, the broker checks the authorization of the client and grants or denies access to the broker and/or individual topics or queues. The Admin Client can also communicate over an encrypted connection and is subject to Authentication and Authorization.
To successfully implement a secure system requires attention to detail and some knowledge of the underlying technologies, specifically:
- SSL/TLS - Secure Sockets Layer and Transport Layer Security
- JAAS - Java Authentication and Authorization Service (if using it in place of the default mechanism for authentication clients on the micro broker)
The nature of secure systems is such that it is not possible to simply “enable security” and hope everything operates as you expect it to.
The micro broker security features contain system implementers to provide secure access and communications to and from the micro broker. This includes SSL/TLS (Secure Sockets Layer and Transport Layer Security) data encryption as it transmits over the network. These features can be utilized by both messaging and administrative clients of the broker.
Authentication between micro broker and micro broker clients
The micro broker authenticates itself to its clients by presenting a valid X509 certificate during the SSL/TLS protocol handshake.
Authentication of micro broker clients to micro broker
To allow the micro broker to authenticate clients, a flexible and extensible authentication mechanism allows for different authentication methods. For example, password based authentication is provided.
The micro broker uses the Java Authentication and Authorization Service (JAAS) to authenticate clients. If running on a platform supporting security features, any client application which specifies a user name and password will be authenticated. If authentication succeeds, then the user name provided by the client becomes the subject name for authorization. If a client does not specify a user name and password, then the client is considered authenticated, and the user name “anonymous” is used for authorization.
Authorization of clients
The micro broker uses a policy-based authorization scheme. Policies are specified in an access control language (ACL), which is specified in XML. The ACL file is called micro-acl.xml
and resides in the broker data directory. A default ACL file is created when a micro broker is created. Any changes to the file take effect when the broker starts or restarts. To use an existing ACL file with a new broker, create the broker then overwrite the generated default ACL file with the pre-written one. When you start the new broker, it will use the existing ACL file.
The micro broker runs securely on Java SE runtimes. This means that clients (such as MQTT V3, MQTT V5 and JMS clients) can connect to the broker using SSL, and that the broker will authenticate and authorize their actions. On DeviceEE runtimes the broker runs without security enabled, and only secure clients and secure outgoing bridge connections are possible.
Parent topic: Lotus Expeditor micro broker overview