global login?

[sergio]

the application i am currently writing in turbogears is part of a much larger family of sites..

in a perfect world, a user would log in to the main site, and then be logged in everywhere (through a session, maybe?)..

the main part of the site is not written in turbogears.. it is a php site..

there is also another part of the site that runs a wiki based on a product called "confluence.." this runs on java..

anyone have any idea if this perfect world is even nearly attainable?

thanks!

___

peace,

sergio

photographer, journalist, visionary

www.coffee-black.com

[Timothy Freund]

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:

http://pythonpaste.org/module-paste.auth.cas.html

It looks like we could add CAS support to Identity just by implementing
a method called identity_from_cas in turbogears.identity.visitor

I'm willing to give that a shot, so someone correct me if I'm completely
off base... :-)

Tim

--
Timothy Freund
http://digital-achievement.com
http://edodyssey.com

[Jeff Watkins]

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

--

Jeff Watkins

http://newburyportion.com/

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)

[Timothy Freund]

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.

Tim

[sergio]

On Feb 23, 2006, at 10:19 PM, Timothy Freund wrote:

I'm willing to give that a shot, so someone correct me if I'm completely 

off base... :-)

hi, tim!

thanks for the help..

unfortunately, i have decided that turbogears is not the tool for me on this project...

i was just running into too many stumbling blocks that i had to research how to solve, rather than just implement them quickly using other tools..

i have not given up on turbogears.. 

i have another personal project in the works right now that i will implement in turbogears...

but for a project that everyone wants to see results on every few minutes, i was just moving too slow..

[Timothy Freund]

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

[cale...@gmail.com]

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.

Cheers,

Caleb Shay

[isaac]

Yes, this is very needed, and will make TG even more widely used. Go for it.

[Diwaker Gupta]

On 2/26/06, Timothy Freund <t...@digital-achievement.com> 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.

+1. I think its a great idea, since I'll be needing such a provider
myself in a little while :-)

Diwaker
--
Web/Blog/Gallery: http://floatingsun.net/blog

[de...@chargedmultimedia.com]

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!

[Krys]

+1 me too to LDAP auth support.

Krys

[Jeff Watkins]

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.

--

[Francis Lavoie]

2006/2/27, Timothy Freund <t...@digital-achievement.com>:

>
> 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.

[Timothy Freund]

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!

Thanks,

Tim

[smilechaser]

Sign me up for LDAP testing too. :)

[Lee McFadden]

And me :)

[qhar...@gmail.com]

Yet another "me too" of needing this... Go Tim!

[Timothy Freund]

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.

http://trac.turbogears.org/turbogears/ticket/634

Let me know what the major pain points are. I'll be back at it
Wednesday night once I'm done with my pesky day job.

Thanks!

Tim

qhar...@gmail.com wrote:
> Yet another "me too" of needing this... Go Tim!
>
>
>

[Jorge Vargas]

really nice i'll give it a try