PAM Authentication & RSA Authentication Manager
Hey Everyone, Any information I have found related to utilizing PAM for authentication dates back in 1999, so I'm assuming some solution has been found and I'm just not seeing it or the issue was dropped. I'm interested in implementing PAM for authentication mainly because I ideally need authentication that draws from a variety of sources including RSA's Authentication Manager. Any suggestions would be greatly appreciated! Thanks in Advance, Dave
David Ayres wrote:
Any information I have found related to utilizing PAM for authentication dates back in 1999, so I'm assuming some solution has been found and I'm just not seeing it or the issue was dropped. I'm interested in implementing PAM for authentication mainly because I ideally need authentication that draws from a variety of sources including RSA's Authentication Manager. Any suggestions would be greatly appreciated!
PluggableAuthenticationService is your friend, you may not even need PAM ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
PluggableAuthenticationService is your friend, you may not even need PAM ;-)
I'm sure PluggableAuthService -- and exUserFolder, etc. -- are great and all, but if you don't mind my asking the dumb question ... why reinvent a perfectly good wheel? This seems like exactly the kind of thing PAM was designed for. One product introducing PAM support would eliminate the need to support most of these other authentication schemes. And with the kind of extensibility already available, it'd still be perfectly possible to create your own authentication method if it's not something PAM supports, but most of these are no-brainers for PAM. Tom
+-------[ Tom Trelvik ]---------------------- | Chris Withers wrote: | >PluggableAuthenticationService is your friend, you may not even need PAM | >;-) | | I'm sure PluggableAuthService -- and exUserFolder, etc. -- are great | and all, but if you don't mind my asking the dumb question ... why | reinvent a perfectly good wheel? This seems like exactly the kind of | thing PAM was designed for. One product introducing PAM support would | eliminate the need to support most of these other authentication | schemes. And with the kind of extensibility already available, it'd | still be perfectly possible to create your own authentication method if 1st, you need PAM support on every platform. 2nd, you need python/zope bindings for PAM that don't impose licensing restrictions on you. The current PyPAM bindings are GPL (not even LGPL), so that pretty much restricts the pool of people willing to bind to them. (Motivation for me to write my own bindings is pretty low). 3rd, you underestimate just what people want out of their web app. They don't want to setup PAM and deal with new mysterious TLA crap, when their database or NT server is already working just fine. 4th, people use these things to manage users not just auth them, and PAM unfortunately doesn't do that. In other words, if people wanted it badly enough, it'd be done. Let me know when you're finished d8) -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
1st, you need PAM support on every platform.
True, but it's not like this is the only non-Zope dependency. For example, to use LDAPUserFolder I need python-ldap.
2nd, you need python/zope bindings for PAM that don't impose licensing restrictions on you. The current PyPAM bindings are GPL (not even LGPL), so that pretty much restricts the pool of people willing to bind to them. (Motivation for me to write my own bindings is pretty low).
I'm not sure I understand the implications here. Most of this code is already open source anyway, right? Wouldn't the GPL terms only apply to code that its code gets used in, and not some other program that calls it?
3rd, you underestimate just what people want out of their web app. They don't want to setup PAM and deal with new mysterious TLA crap, when their database or NT server is already working just fine.
Oh of course, I completely agree, but like I said, other authentication modules are of course still available if you need something PAM doesn't handle or need a home grown solution of some sort. I of course understand the need for that.
4th, people use these things to manage users not just auth them, and PAM unfortunately doesn't do that.
Now this makes the most sense. Unfortunately, it also doesn't apply to my situation, as I'm part of a larger organization, and want to use the preexisting centralized LDAP (which I of course only have read access to) to manage authentication so my users don't need a new set of usernames/passwords, but I'll be *managing* the users locally (Not sure yet exactly how that's going to work, still working through documentation and whatnot (but I certainly wouldn't mind any pointers)).
In other words, if people wanted it badly enough, it'd be done.
I can't really dispute that, it's certainly been thoroughly demonstrated by all the other products people have come out with to suit their needs.
Let me know when you're finished d8)
Ha, I wish. Unfortunately, I'm still quite new to Zope/Plone, and haven't touched python yet at all (Blasphemous, I know!). But perhaps someday (so I'm optimist) ... Thanks for the informative response! Tom
On Feb 1, 2005, at 20:42, Tom Trelvik wrote:
Andrew Milton wrote:
1st, you need PAM support on every platform.
True, but it's not like this is the only non-Zope dependency. For example, to use LDAPUserFolder I need python-ldap.
Yes? That's available even on lesser operating systems from M$. Is PAM?
Now this makes the most sense. Unfortunately, it also doesn't apply to my situation, as I'm part of a larger organization, and want to use the preexisting centralized LDAP (which I of course only have read access to) to manage authentication so my users don't need a new set of usernames/passwords, but I'll be *managing* the users locally (Not sure yet exactly how that's going to work, still working through documentation and whatnot (but I certainly wouldn't mind any pointers)).
You can use the LDAPUserFolder in read-only mode so it does not try to write back to the directory and store group/role information on the LDAPUserFolder itself. That way the users log in with the same credentials *and* you can manage the roles they get in the Zope context locally. It's just a matter of configuration. jens
Jens Vagelpohl wrote:
Yes? That's available even on lesser operating systems from M$. Is PAM?
Okay, excellent point. But I also don't understand why so many people are using Windows as a *server* for a service that just seems so much better suited for a unix environment (and with so much less overhead), but that's just me.
You can use the LDAPUserFolder in read-only mode so it does not try to write back to the directory and store group/role information on the LDAPUserFolder itself. That way the users log in with the same credentials *and* you can manage the roles they get in the Zope context locally. It's just a matter of configuration.
But would that give every user in the LDAP server Zope level access to my server? I'm still trying to figure out how to select which users from the LDAP server will get accounts on my server. Do I add/remove the users manually (or programmatically) through Zope? (Sorry for the newbie questions ...) Thanks! Tom
On Feb 2, 2005, at 5:05, Tom Trelvik wrote:
Okay, excellent point. But I also don't understand why so many people are using Windows as a *server* for a service that just seems so much better suited for a unix environment (and with so much less overhead), but that's just me.
I keep wondering about the very same thing, trust me ;)
You can use the LDAPUserFolder in read-only mode so it does not try to write back to the directory and store group/role information on the LDAPUserFolder itself. That way the users log in with the same credentials *and* you can manage the roles they get in the Zope context locally. It's just a matter of configuration.
But would that give every user in the LDAP server Zope level access to my server? I'm still trying to figure out how to select which users from the LDAP server will get accounts on my server. Do I add/remove the users manually (or programmatically) through Zope? (Sorry for the newbie questions ...)
In a scenario like this you could only restrict by the following: - where in the DIT you root the search for users - what specific objectClass you search for If all your users are in the same place and all the same object classes then they would all be able to authenticate. But only those who *you* picked out and assigned roles to using the configuration screens would get roles assigned to them during login and be authorized to access stuff, depending on what roles you assign inside Zope and what permissions are assigned to the roles. jens
+-------[ Tom Trelvik ]---------------------- | | >You can use the LDAPUserFolder in read-only mode so it does not try to | >write back to the directory and store group/role information on the | >LDAPUserFolder itself. That way the users log in with the same | >credentials *and* you can manage the roles they get in the Zope context | >locally. It's just a matter of configuration. | | But would that give every user in the LDAP server Zope level access | to my server? I'm still trying to figure out how to select which users | from the LDAP server will get accounts on my server. Do I add/remove | the users manually (or programmatically) through Zope? (Sorry for the | newbie questions ...) You can add them to an OU or Group on the LDAP server and restrict the users available when to Zope to users in that OU or group. -- Andrew Milton akm@theinternet.com.au
+-------[ Jens Vagelpohl ]---------------------- | | On Feb 1, 2005, at 20:42, Tom Trelvik wrote: | | >Andrew Milton wrote: | >>1st, you need PAM support on every platform. | > | > True, but it's not like this is the only non-Zope dependency. For | >example, to use LDAPUserFolder I need python-ldap. | | Yes? That's available even on lesser operating systems from M$. Is PAM? | | | > Now this makes the most sense. Unfortunately, it also doesn't apply | >to my situation, as I'm part of a larger organization, and want to use | >the preexisting centralized LDAP (which I of course only have read | >access to) to manage authentication so my users don't need a new set | >of usernames/passwords, but I'll be *managing* the users locally (Not | >sure yet exactly how that's going to work, still working through | >documentation and whatnot (but I certainly wouldn't mind any | >pointers)). | | You can use the LDAPUserFolder in read-only mode so it does not try to | write back to the directory and store group/role information on the | LDAPUserFolder itself. That way the users log in with the same | credentials *and* you can manage the roles they get in the Zope context | locally. It's just a matter of configuration. Ditto for exUserFolder d8) -- Andrew Milton akm@theinternet.com.au
participants (5)
-
Andrew Milton -
Chris Withers -
David Ayres -
Jens Vagelpohl -
Tom Trelvik