mqsecurity

This module provides the framework for implementing access controls (authentication and authorization) to message queues.

It's important to remember that this module does not provide those features, it relies upon external modules. Developers wishing to add access controls must supply a module that provides authentication and authorization services.

MQSecurity does take advantage of twisted cred in an attempt to minimize the work involved in developing an authentication module. Interfaces for common checkers are provided in the module, along with the ability to supply a custom checker. Samples for some of these are provided in the sample_auth directory.

(This document will not go into all the intricacies of twisted cred - there are other sources of information on that topic, such as the twisted documentation itself. The samples may also provide some worthwhile information on how to actually _use_ the various interfaces.)

The MQPortal is the primary object in this module.

An instance of it is created by the StompFactory in morbid. The __init__ function requires the MessageQueueManager as a parameter, and will accept an optional filename. The filename is the fully qualified name of the security module. (Note: The specified directory gets added to sys.path. If the module already resides in a directory on your path, you do not need to specify the directory for that module.)

When the security module has been imported, a twisted Realm is created (MQRealm), using information defined in that module. A twisted portal.Portal object is then created for that realm. (The Portal is the connection between the protocol and the authentication function.)

Authorization is designed around a "groups" model. It is intended that the credentials checker provide a group (or a collection of groups) to which that user belongs. If the concept of groups doesn't apply to your specific situation, or if you need to limit access on a per-user basis, create a group for each user.

Authorization is provided by a function supplied to the security module. Any function performed on a queue by a user causes the authorization function to be called with the group(s) stored in that user's avatar, and the name of the queue.

When the authorization function is called, it returns a set containing zero or more of 'c', 'r', or 'w', representing the ability to create, read, or write that queue. If the set is empty, then all access to that queue by that user is denied.

It is up to the security module author to ensure that the groups stored in the avatar are usable by the authentication function.

A security module is expected to have a Parms class defined within it.

A Parms class must have at least three specific methods defined.

1. checker_config - Returns a dict containing configuration information for the checker being used.
2. group_config - Returns a function that returns group membership for a given ID.
3. get_group_access_rights - Returns a function that returns the rights a group has to a specific queue.

Flow of the authentication process

There are many objects that interact during the authentication process. It may be helpful to understand the flow of events during a routine logon in Morbid.

• The StompFactory creates an instance of a StompProtocol when a client connects to the twisted server.

• The first message received should be a "connect" command. The connect message is sent to mqsecurity.MQPortal.stomp_login, passing the dict of the headers included in the command.

• stomp_login creates a credentials.UsernamePassword object, then passes that to portal.Portal.login.

• portal.Portal.login calls requestAvatarId in the registered checker. It is requestAvatarId that validates the password for that ID. Assuming the ID and password are valid, portal.Portal.login then calls mqsecurity.MQRealm.requestAvatar.

• mqsecurity.MQRealm.requestAvatar creates an instance of mqsecurity.Connector, which is the Avatar for that user connected to that protocol instance.

If a standard credentials checker is used, then no code needs to be written to provide authentication. All the configuration information can be supplied in the Parms.checker_config method. Custom code is necessary only when authentication is going to be performed in a way that can't be handled by the standard authentication schemes.

The standard checkers provided are:

• test - creates a defined number of IDs named usr%d (with password pwd%d), where %d ranges from 0 to Parms.checker_config().id_count - 1.

• file - provides an interface to the checkers.FilePasswordDB object.

• pam - provides an interface to the checkers.PluggableAuthenticationModulesChecker object

• db - intended to provide a reasonably generic interface through twisted.enterprise to an arbitrary database. (Not yet implemented)

• restq - provides an interface to a restq object which provides authentication from a web-based resource.

• any - accepts any ID and password as valid, creating the appropriate avatar for that connection.

• private - allows you to supply any valid checker to be registered with the portal. (Not yet implemented)

Note: At this time, mqsecurity only allows for one checker to be registered.