![(please configure the [header_logo] section in trac.ini)](/trac/chrome/site/your_project_logo.png){kind=logo}
Changes between Version 2 and Version 3 of MorbidQSecurity
- Timestamp:
- 12/09/09 23:01:58 (9 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MorbidQSecurity
v2 v3 12 12 the work involved in developing an authentication module. Interfaces for 13 13 common checkers are provided in the module, along with the ability to 14 supply a custom checker. Samples for manyof these are provided in the14 supply a custom checker. Samples for some of these are provided in the 15 15 sample_auth directory. 16 16 … … 20 20 information on how to actually _use_ the various interfaces.) 21 21 22 The MQPortal is the primary object in this module. An instance of it 23 is created by the StompFactory in morbid. The __init__ function requires 24 the MessageQueueManager as a parameter, and will accept an optional 25 filename. The filename is the fully qualified name of the security 26 module. (Note: The specified directory gets added to sys.path. If 27 the module already resides in a directory on your path, you do not need 28 to specify the directory for that module.) 22 The MQPortal is the primary object in this module. 23 An instance of it is created by the !StompFactory in morbid. 24 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.) 29 25 30 When the security module has been imported, a twisted Realm is created 31 (MQRealm), using information defined in that module. A twisted 32 portal.Portal object is then created for that realm. (The Portal is 33 the connection between the protocol and the authentication function.) 26 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.) 34 27 35 Authorization is designed around a "groups" model. It is intended that 36 the credentials checker provide a group (or a collection of groups) 37 to which that user belongs. If the concept of groups doesn't apply 38 to your specific situation, it is recommended that the userID is 39 assigned to the groups. 28 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. 40 29 41 Authorization is provided by a function supplied to the security 42 module. Any function performed on a queue by a user causes the 43 authorization function to be called with the group(s) stored in that 44 user's avatar, and the name of the queue. 30 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. 45 31 46 When the authorization function is called, it returns a set containing 47 zero or more of 'c', 'r', or 'w', representing the ability to create, 48 read, or write that queue. If the set is empty, then all access to that 49 queue by that user is denied. 32 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. 50 33 51 It is up to the security module author to ensure that the groups 52 stored in the avatar are usable by the authentication function. 34 It is up to the security module author to ensure that the groups stored in the avatar are usable by the authentication function. 53 35 54 36 A security module is expected to have a Parms class defined within it. … … 64 46 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. 65 47 66 * The StompFactory creates an instance of aStompProtocol when a client connects to the twisted server.48 * The !StompFactory creates an instance of a !StompProtocol when a client connects to the twisted server. 67 49 68 50 * 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. 69 51 70 * stomp_login creates a credentials. UsernamePassword object, then passes that to portal.Portal.login.52 * stomp_login creates a credentials.!UsernamePassword object, then passes that to portal.Portal.login. 71 53 72 54 * 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. … … 86 68 * file - provides an interface to the checkers.FilePasswordDB object. 87 69 88 * pam - provides an interface to the checkers. PluggableAuthenticationModulesChecker object70 * pam - provides an interface to the checkers.!PluggableAuthenticationModulesChecker object 89 71 90 72 * db - intended to provide a reasonably generic interface through twisted.enterprise to an arbitrary database. (Not yet implemented)
