Re: [Orbited] Re: Introducing Hotdot: project combining Django + Orbited + Twisted. Questions and Feedback
40 views
Skip to first unread message
Mario Balibrera
Dec 5, 2009, 8:03:07 PM12/5/09
to orbite...@googlegroups.com, mor...@googlegroups.com
Great work, Alex. I listed your project here: http://orbited.org/wiki/Sites .
> And here is the Twisted cred checker that uses Django models to do auth:http://github.com/clemesha/hotdot/blob/master/realtime/auth.py
Good call, Matthew. Ken Whitesell would probably know the best way to integrate it into his auth module. Ken, thoughts? I've cc'ed the MorbidQ list. We should finish this subthread there. ;)
-mario
> And here is the Twisted cred checker that uses Django models to do auth:http://github.com/clemesha/hotdot/blob/master/realtime/auth.py
> (there is a limitation is MorbidQ such that I could not just "plug this in",Could you propose a patch to MorbidQ to address this limitation? It
> see
> the above comment and the file "stompfactory.py")
would be great if you could plug your DatabaseChecker into MorbidQ
without having to work around anything.
Good call, Matthew. Ken Whitesell would probably know the best way to integrate it into his auth module. Ken, thoughts? I've cc'ed the MorbidQ list. We should finish this subthread there. ;)
-mario
Alex Clemesha
Dec 5, 2009, 11:23:19 PM12/5/09
to mor...@googlegroups.com
(Sent this email before I was subscribed, so now I'm re-sending in)
--
Alex Clemesha
clemesha.org
--
Alex Clemesha
clemesha.org
On Sat, Dec 5, 2009 at 5:03 PM, Mario Balibrera <mario.b...@gmail.com> wrote:
Great work, Alex. I listed your project here: http://orbited.org/wiki/Sites .
> And here is the Twisted cred checker that uses Django models to do auth:http://github.com/clemesha/hotdot/blob/master/realtime/auth.py
> (there is a limitation is MorbidQ such that I could not just "plug this in",Could you propose a patch to MorbidQ to address this limitation? It
> see
> the above comment and the file "stompfactory.py")
would be great if you could plug your DatabaseChecker into MorbidQ
without having to work around anything.
Absolutely.
Good call, Matthew. Ken Whitesell would probably know the best way to integrate it into his auth module. Ken, thoughts? I've cc'ed the MorbidQ list. We should finish this subthread there. ;)
I'd appreciate any thoughts on the best way to plug this in, but whatever the final decision is, I'm happy to contribute a patch.
thanks,
Alex
thanks,
Alex
--
Alex Clemesha
clemesha.org
--
Alex Clemesha
clemesha.org
KenWhi...@comcast.net
Dec 6, 2009, 12:40:12 PM12/6/09
to mor...@googlegroups.com
On Sat, Dec 5, 2009 at 5:03 PM, Mario Balibrera
<mario.b...@gmail.com>wrote:
> Great work, Alex. I listed your project here:
> http://orbited.org/wiki/Sites .
>
>
> > And here is the Twisted cred checker that uses Django models to do auth:
> http://github.com/clemesha/hotdot/blob/master/realtime/auth.py
>
>> > (there is a limitation is MorbidQ such that I could not just "plug this
>> in",
>> > see
>> > the above comment and the file "stompfactory.py")
>>
>> Could you propose a patch to MorbidQ to address this limitation? It
>> would be great if you could plug your DatabaseChecker into MorbidQ
>> without having to work around anything.
>>
> Absolutely.
>
> Good call, Matthew. Ken Whitesell would probably know the best way to
> integrate it into his auth module. Ken, thoughts? I've cc'ed the MorbidQ
> list. We should finish this subthread there. ;)
>
I'd appreciate any thoughts on the best way to plug this in, but whatever
the final decision is, I'm happy to contribute a patch.
been there to provide database authentication / authorization. (The problem
_I_ encountered when trying to develop one was my inability to create
reliable & repeatable "unit-style" tests.)
The requirements for authenticators are really quite minimal - it's just a
couple of special-named functions that need to be provided. When I get home
and can get to my notes, I'll reply in more detail later. (Will probably be
tomorrow.) Please feel free to nag me again Monday night if I should forget
between now and then.
Ken
to nag me
KenWhi...@comcast.net
Dec 7, 2009, 8:32:53 PM12/7/09
to mor...@googlegroups.com
Ok, I've attached the documentation I've worked on for the authentication process.
It should provide a starting point for writing a db authenticator.
I'm willing to answer any questions you might have. Unfortunately, however, I haven't even looked at the code is close to six months, so if you have any specific questions about what I've written, I'll have to refresh my memory.
Inside MorbidQ
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 many of these are provided in the
sample_auth directory.
(This document will not go into all the intracacies 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 primay 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, it is recommended that the userID is
assigned to the groups.
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 useable 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 protcol 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:
1) 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.
2) file - provides an interface to the checkers.FilePasswordDB object.
3) pam - provides an interface to the
checkers.PluggableAuthenticationModulesChecker object
4) db - intended to provide a reasonably generic interface through
twisted.enterprise to an arbitrary database. (Not yet implemented)
5) restq - provides an interface to a restq object which provides
authentication from a web-based resource.
6) any - accepts any ID and password as valid, creating the appropriate
avatar for that connection.
7) 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.
It should provide a starting point for writing a db authenticator.
I'm willing to answer any questions you might have. Unfortunately, however, I haven't even looked at the code is close to six months, so if you have any specific questions about what I've written, I'll have to refresh my memory.
Inside MorbidQ
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 many of these are provided in the
sample_auth directory.
(This document will not go into all the intracacies 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 primay 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, it is recommended that the userID is
assigned to the groups.
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 useable 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 protcol 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:
1) 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.
2) file - provides an interface to the checkers.FilePasswordDB object.
3) pam - provides an interface to the
checkers.PluggableAuthenticationModulesChecker object
4) db - intended to provide a reasonably generic interface through
twisted.enterprise to an arbitrary database. (Not yet implemented)
5) restq - provides an interface to a restq object which provides
authentication from a web-based resource.
6) any - accepts any ID and password as valid, creating the appropriate
avatar for that connection.
7) 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.
Alex Clemesha
Dec 14, 2009, 9:13:53 PM12/14/09
to MorbidQ
Thanks very much Ken for the detailed response,
I'll be going over this carefully as soon as I can and
I'll post any questions, if I have them.
-Alex
I'll be going over this carefully as soon as I can and
I'll post any questions, if I have them.
-Alex
Reply all
Reply to author
Forward
0 new messages