The Authentication Swiftlet serves as an authentication entity for a router network. SwiftMQ has a local authentication design where each router in a router network has to be a trusted router of the network. Each router serves as en entry point to the whole network and can authenticate access to every available resource. The authentication takes place by the Authentication Swiftlet of the local router. It is not possible to restrict the access between routers by asking a remote Authentication Swiftlet about specific grants (that would be too slow). Therefore, if one needs to connect routers that are not completely trusted, he has to use the JMS Bridge Extension Swiftlet to connect these routers.
The base of authentication are groups. Each group contains the grants of the resources (queues and topics). There are 2 predefined groups, "admin" and "public". The "admin" group contains grants of the management queues for the 2 sample routers of the distribution. The "public" group contains grants of the topic "swiftmq.jndi" to enable everybody to perform JNDI lookups. A user is assigned to exactly one group and receives all grants of this group. There are 2 predefined users, "admin" with password "secret" and "anonymous" without a password. If a user logs in without a user name (user name is null), the user "anonymous" will automatically be assigned by the system. To each user, a host access list can be defined. This list contains entries in form of SQL-Like predicates. If a user logs in, his remote host name is checked against this list. The access is denied if there is no match. Authentication can be enabled/disabled as a whole. It is disabled per default.
Resource limit groups are assigned to users similar to authentication groups. There exists a resource limit group "public" which is used per default. The sense of this feature is to avoid resource exhaustion due to client programming mistakes like opening many QueueReceivers/TemporaryQueues etc without closing them. A Resource Limit Group contains maximum values for connections, sessions, temp. queues, producers, and consumers. The limit for maximum connections is per user and the default is -1 (unlimited). The other values are on a per-connection-base and the default is 50/50/50/50. That means, a client can create 50 sessions, 50 temp. queues (TemporaryQueue/TemporaryTopic), 50 producers (QueueSender/TopicPublisher), and 50 consumers (QueueReceiver/TopicSubscriber) on each connection, being within the default limit. If the client attempts to create the 51th resource, it gets a JMSException with a message that the resource limit is exceeded. An administrator can define additional resource limit groups with higher/lower maximum values and can assign it to users. Resource limit checks cannot be switched off.