You might want to look at Yale's CAS (Central Authentication Service). I have integrated a Java and Ruby on Rails application using it, and it's only a matter of time until I have to figure out how to get a TurboGears application running with the same authentication. It looks like there are already some python solutions out there:
Actually the best way to implement this would be to write a CasIdentityProvider class and use that instead of SqlObjectIdentityProvider. Ultimately, it is the IdentityProvider classes that are responsible for determining who the request is from.
On 23 Feb, 2006, at 10:19 pm, Timothy Freund wrote:
> It looks like we could add CAS support to Identity just by > implementing > a method called identity_from_cas in turbogears.identity.visitor
Getting an education was a bit like a communicable sexual disease. It made you unsuitable for a lot of jobs and then you had the urge to pass it on. -- (Terry Pratchett, Hogfather)
> Actually the best way to implement this would be to write a > CasIdentityProvider class and use that instead of > SqlObjectIdentityProvider. Ultimately, it is the IdentityProvider > classes that are responsible for determining who the request is from.
Thanks for pointing me in the right direction -- I will be able to really dig in and get that working over this weekend.
Here is a quick update on my IdentityProvider progress -- since Sergio no longer immediately needs the CASIdentityProvider I started work on an LdapIdentityProvider this weekend. LDAP authentication is a little more conventional compared to CAS, so I thought it would be a better place to jump in and learn. It is starting to take shape, but I have some rough edges to smooth out before releasing the code into the wild.
I think that the LdapIdentityProvider will be a great resource for people in corporate environments since most businesses big enough to write internal applications have all of their users stored in a directory of some sort (Active Directory, Sun One, OpenLDAP, etc).
The idea is to authenticate users against an LDAP directory and to pull most of their basic user information (name, email, phone number and more) from the directory as well. There is still a tg_user table in the database but it only contains an id and a username. The table's primary purpose is to provide referential integrity against the visit records and other business objects.
I'd enjoy hearing any comments or criticism about the idea.
Thanks,
Tim
Timothy Freund wrote: > Jeff Watkins wrote: > > Actually the best way to implement this would be to write a > > CasIdentityProvider class and use that instead of > > SqlObjectIdentityProvider. Ultimately, it is the IdentityProvider > > classes that are responsible for determining who the request is from.
> Thanks for pointing me in the right direction -- I will be able to > really dig in and get that working over this weekend.
I'm actually in desperate need of this. I'm currently building an enterprise application on turbogears and the spec was just changed on me a few days ago that it needs to be able to pull users and groups from AD. I was about to dive into implementing it myself, but if you are already working on it, I'll put it on hold. I'd be glad to provide any help I can, either through code or just testing what you have and supplying feedback.
> Here is a quick update on my IdentityProvider progress -- since Sergio > no longer immediately needs the CASIdentityProvider I started work on an > LdapIdentityProvider this weekend. LDAP authentication is a little more > conventional compared to CAS, so I thought it would be a better place to > jump in and learn. It is starting to take shape, but I have some rough > edges to smooth out before releasing the code into the wild.
> I think that the LdapIdentityProvider will be a great resource for > people in corporate environments since most businesses big enough to > write internal applications have all of their users stored in a > directory of some sort (Active Directory, Sun One, OpenLDAP, etc).
> The idea is to authenticate users against an LDAP directory and to pull > most of their basic user information (name, email, phone number and > more) from the directory as well. There is still a tg_user table in the > database but it only contains an id and a username. The table's primary > purpose is to provide referential integrity against the visit records > and other business objects.
> I'd enjoy hearing any comments or criticism about the idea.
+1. I think its a great idea, since I'll be needing such a provider myself in a little while :-)
Timothy Freund wrote: > I think that the LdapIdentityProvider will be a great resource for > people in corporate environments since most businesses big enough to > write internal applications have all of their users stored in a > directory of some sort (Active Directory, Sun One, OpenLDAP, etc).
! Strongly want this functionality. I am working on a TG based administration tool, which would be much better if built in LDAP auth was available. I was also (not looking forward to) considering implementing this identity provider. Thanks!
Tim, if you need any help with this, don't hesitate to drop me a line. I don't have the time to personally write it, but I'll answer any questions you might have.
On 27 Feb, 2006, at 1:05 am, Timothy Freund wrote:
> Here is a quick update on my IdentityProvider progress -- since Sergio > no longer immediately needs the CASIdentityProvider I started work > on an > LdapIdentityProvider this weekend. LDAP authentication is a little > more > conventional compared to CAS, so I thought it would be a better > place to > jump in and learn. It is starting to take shape, but I have some > rough > edges to smooth out before releasing the code into the wild.
> I think that the LdapIdentityProvider will be a great resource for > people in corporate environments since most businesses big enough to > write internal applications have all of their users stored in a > directory of some sort (Active Directory, Sun One, OpenLDAP, etc).
> The idea is to authenticate users against an LDAP directory and to > pull > most of their basic user information (name, email, phone number and > more) from the directory as well. There is still a tg_user table > in the > database but it only contains an id and a username. The table's > primary > purpose is to provide referential integrity against the visit records > and other business objects.
> I'd enjoy hearing any comments or criticism about the idea.
> Thanks,
> Tim
> Timothy Freund wrote: >> Jeff Watkins wrote: >>> Actually the best way to implement this would be to write a >>> CasIdentityProvider class and use that instead of >>> SqlObjectIdentityProvider. Ultimately, it is the IdentityProvider >>> classes that are responsible for determining who the request is >>> from.
>> Thanks for pointing me in the right direction -- I will be able to >> really dig in and get that working over this weekend.
Getting an education was a bit like a communicable sexual disease. It made you unsuitable for a lot of jobs and then you had the urge to pass it on. -- (Terry Pratchett, Hogfather)
> Here is a quick update on my IdentityProvider progress -- since Sergio > no longer immediately needs the CASIdentityProvider I started work on an > LdapIdentityProvider this weekend. LDAP authentication is a little more > conventional compared to CAS, so I thought it would be a better place to > jump in and learn. It is starting to take shape, but I have some rough > edges to smooth out before releasing the code into the wild.
> I think that the LdapIdentityProvider will be a great resource for > people in corporate environments since most businesses big enough to > write internal applications have all of their users stored in a > directory of some sort (Active Directory, Sun One, OpenLDAP, etc).
> The idea is to authenticate users against an LDAP directory and to pull > most of their basic user information (name, email, phone number and > more) from the directory as well. There is still a tg_user table in the > database but it only contains an id and a username. The table's primary > purpose is to provide referential integrity against the visit records > and other business objects.
> I'd enjoy hearing any comments or criticism about the idea.
> Thanks,
> Tim
I have started learning turbogears a weeks ago when I was searching something more similar to ruby on rails. I have a background in zope and I must say that turbogears is amazing. I had started an application in zope, but I think I will switch it to tg. Even if it's still not in stable branch, the potential is astonishing.
LDAP would be a must to enterprise adoption. Often simple ldap support make people perception of an application jump from normal to professionnal.
I would inevitably use this for my own project , +1.
I'll be working on this just a little bit today, and then I'll be full time on it tonight. I'll send out another update then. I may end up with a couple of questions, but so far the code has been easy to understand -- thanks for making it easy to jump in to Identity, Jeff!
Jeff Watkins wrote: > Tim, if you need any help with this, don't hesitate to drop me a > line. I don't have the time to personally write it, but I'll answer > any questions you might have.
> On 27 Feb, 2006, at 1:05 am, Timothy Freund wrote:
>>Here is a quick update on my IdentityProvider progress -- since Sergio >>no longer immediately needs the CASIdentityProvider I started work >>on an >>LdapIdentityProvider this weekend. LDAP authentication is a little >>more >>conventional compared to CAS, so I thought it would be a better >>place to >>jump in and learn. It is starting to take shape, but I have some >>rough >>edges to smooth out before releasing the code into the wild.
>>I think that the LdapIdentityProvider will be a great resource for >>people in corporate environments since most businesses big enough to >>write internal applications have all of their users stored in a >>directory of some sort (Active Directory, Sun One, OpenLDAP, etc).
>>The idea is to authenticate users against an LDAP directory and to >>pull >>most of their basic user information (name, email, phone number and >>more) from the directory as well. There is still a tg_user table >>in the >>database but it only contains an id and a username. The table's >>primary >>purpose is to provide referential integrity against the visit records >>and other business objects.
>>I'd enjoy hearing any comments or criticism about the idea.
>>Thanks,
>>Tim
>>Timothy Freund wrote:
>>>Jeff Watkins wrote:
>>>>Actually the best way to implement this would be to write a >>>>CasIdentityProvider class and use that instead of >>>>SqlObjectIdentityProvider. Ultimately, it is the IdentityProvider >>>>classes that are responsible for determining who the request is >>>>from.
>>>Thanks for pointing me in the right direction -- I will be able to >>>really dig in and get that working over this weekend.
> Getting an education was a bit like a communicable sexual disease. It > made you unsuitable for a lot of jobs and then you had the urge to > pass it on. > -- (Terry Pratchett, Hogfather)
It's still rough.... test and patch! I've only tested against OpenLDAP, and groups and permissions are still handled in the database. I want to get the groups pulled from the directory as well as test against some other LDAP directory vendors among other things.
> It's still rough.... test and patch! I've only tested against OpenLDAP, > and groups and permissions are still handled in the database. I want to > get the groups pulled from the directory as well as test against some > other LDAP directory vendors among other things.
