I'm working with a customer on a single sign on (SSO) system for Zope. We haven't yet chosen which SSO system we want to use. I would like to hear from anyone who has set up SSO with Zope. We have some definite requirements: * We can't accept arbitrary identities like OpenID normally does. We need to set up our own identity provider (IDP) and force our servers to accept only identities provided by our own IDP. * The SSO process should be very similar to an ordinary cookie-based login process. I don't want the user to have to enter their username on one form and their password on another, but that's the standard OpenID process. * This will be implemented in Zope 3. We are considering OpenID, Shibboleth, CAS, and any other mature system that others might suggest. Shibboleth seems like the most obvious fit, but it's nowhere near as popular as OpenID. I haven't yet looked at CAS in detail. Alternatively, I have wondered if we actually need full-blown SSO; perhaps a carefully constructed domain-wide cookie would do the trick. Any experiences with that? Thanks to anyone who participates. Shane
Hi Shane. Launchpad uses OpenID. We don't have that slated for abstraction and open-sourcing immediately. However, most of the Launchpad code (including this bit) is to be open-sourced by this summer, abstracted or not. Therefore, we should at least be able to give you some idea of what we have done before then. I've forwarded your email to the primary implementer/designer of our OpenID integration. Hopefully he can directly participate, or at least give me some answers to forward to you. Generally, we're using python-openid for the Zope code, and an Apache plugin as a front-end for hooking up other bits. Gary On Feb 17, 2009, at 7:06 PM, Shane Hathaway wrote:
I'm working with a customer on a single sign on (SSO) system for Zope. We haven't yet chosen which SSO system we want to use. I would like to hear from anyone who has set up SSO with Zope.
We have some definite requirements:
* We can't accept arbitrary identities like OpenID normally does. We need to set up our own identity provider (IDP) and force our servers to accept only identities provided by our own IDP.
* The SSO process should be very similar to an ordinary cookie-based login process. I don't want the user to have to enter their username on one form and their password on another, but that's the standard OpenID process.
* This will be implemented in Zope 3.
We are considering OpenID, Shibboleth, CAS, and any other mature system that others might suggest. Shibboleth seems like the most obvious fit, but it's nowhere near as popular as OpenID. I haven't yet looked at CAS in detail.
Alternatively, I have wondered if we actually need full-blown SSO; perhaps a carefully constructed domain-wide cookie would do the trick. Any experiences with that?
Thanks to anyone who participates.
Shane _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Gary Poster wrote:
Launchpad uses OpenID. We don't have that slated for abstraction and open-sourcing immediately. However, most of the Launchpad code (including this bit) is to be open-sourced by this summer, abstracted or not. Therefore, we should at least be able to give you some idea of what we have done before then.
I've forwarded your email to the primary implementer/designer of our OpenID integration. Hopefully he can directly participate, or at least give me some answers to forward to you.
Cool, thanks.
Generally, we're using python-openid for the Zope code, and an Apache plugin as a front-end for hooking up other bits.
In that case, what do you pass to Consumer.begin()? It expects a user URL and no password, yet launchpad.net accepts a user name and password. Shane
On Feb 17, 2009, at 7:55 PM, Shane Hathaway wrote:
Gary Poster wrote:
Launchpad uses OpenID. We don't have that slated for abstraction and open-sourcing immediately. However, most of the Launchpad code (including this bit) is to be open-sourced by this summer, abstracted or not. Therefore, we should at least be able to give you some idea of what we have done before then. I've forwarded your email to the primary implementer/designer of our OpenID integration. Hopefully he can directly participate, or at least give me some answers to forward to you.
Cool, thanks.
Generally, we're using python-openid for the Zope code, and an Apache plugin as a front-end for hooking up other bits.
In that case, what do you pass to Consumer.begin()? It expects a user URL and no password, yet launchpad.net accepts a user name and password.
Shane
Hi Shane. Francis Lacoste gave this answer: We use the OpenID 2.0 identifier select URL. This is a special OpenID url that basically means: identity using whatever ID you have on that server. The OpenID response will contain the actual OpenID identifier of the user at the end of the request. So sites that we integrate in our SSO simply sends you to Launchpad for authentication and then uses the returned identifier to link with their local account representation. We also use sreg (Simple Registration) to transfer information about the account to the integrated sites, so that they can update their local account representation with the central data. Gary
Gary Poster wrote:
We use the OpenID 2.0 identifier select URL. This is a special OpenID url that basically means: identity using whatever ID you have on that server.
The OpenID response will contain the actual OpenID identifier of the user at the end of the request.
So sites that we integrate in our SSO simply sends you to Launchpad for authentication and then uses the returned identifier to link with their local account representation. We also use sreg (Simple Registration) to transfer information about the account to the integrated sites, so that they can update their local account representation with the central data.
I see now! Thanks, Francis and Gary. Shane
On Wed, Feb 18, 2009 at 09:00:10AM -0500, Gary Poster wrote:
On Feb 17, 2009, at 7:55 PM, Shane Hathaway wrote:
Gary Poster wrote:
Launchpad uses OpenID. We don't have that slated for abstraction and open-sourcing immediately. However, most of the Launchpad code (including this bit) is to be open-sourced by this summer, abstracted or not. Therefore, we should at least be able to give you some idea of what we have done before then. I've forwarded your email to the primary implementer/designer of our OpenID integration. Hopefully he can directly participate, or at least give me some answers to forward to you.
Cool, thanks.
Generally, we're using python-openid for the Zope code, and an Apache plugin as a front-end for hooking up other bits.
In that case, what do you pass to Consumer.begin()? It expects a user URL and no password, yet launchpad.net accepts a user name and password.
Shane
Hi Shane. Francis Lacoste gave this answer:
We use the OpenID 2.0 identifier select URL. This is a special OpenID url that basically means: identity using whatever ID you have on that server.
The OpenID response will contain the actual OpenID identifier of the user at the end of the request.
So sites that we integrate in our SSO simply sends you to Launchpad for authentication and then uses the returned identifier to link with their local account representation. We also use sreg (Simple Registration) to transfer information about the account to the integrated sites, so that they can update their local account representation with the central data.
I have the impression that you're talking past each other. There are two ways of using OpenID: * you can be an OpenID provider, i.e. accept logins with username & password and respond to authentication requests from other websites confirming that the user does own this particular OpenID. * you can be an OpenID consumer, i.e. accept OpenID URLs from users and ask the corresponding OpenID provider to validate them. It's my impression that launchpad.net is an OpenID provider only, while Shane is trying to figure out how to use the OpenID consumer API in AuthKit. I could be mistaken about any of the particular points here. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Marius Gedminas wrote:
It's my impression that launchpad.net is an OpenID provider only, while Shane is trying to figure out how to use the OpenID consumer API in AuthKit.
No. I am going after the more conventional single sign on use case where many consumers depend on only one centralized identity provider, and I'd like to use a restricted form of OpenID to accomplish it. It turns out that Launchpad's internal authentication system is pretty much exactly what I was planning to do, so Gary's info pointed me in the right direction. Launchpad also happens to provide public OpenID services, but I don't need to do that. Shane
On Feb 19, 2009, at 2:07 AM, Marius Gedminas wrote:
I have the impression that you're talking past each other.
There are two ways of using OpenID:
* you can be an OpenID provider, i.e. accept logins with username & password and respond to authentication requests from other websites confirming that the user does own this particular OpenID.
* you can be an OpenID consumer, i.e. accept OpenID URLs from users and ask the corresponding OpenID provider to validate them.
It's my impression that launchpad.net is an OpenID provider only, while Shane is trying to figure out how to use the OpenID consumer API in AuthKit.
I could be mistaken about any of the particular points here.
I'm glad that Shane replied that what Francis said helped him. FWIW, IRT Launchpad being an OpenID consumer, that's supposed to be a possibility very soon. Gary
Previously Shane Hathaway wrote:
Alternatively, I have wondered if we actually need full-blown SSO; perhaps a carefully constructed domain-wide cookie would do the trick. Any experiences with that?
auth_tkt based cookies sounds like a good option, possibly combined with something like SQL or LDAP for shared member properties. It has the advantage of being very widely supported as well as bwing very simple. CAS appears to be a common SSO system used for Plone sites and should work as well. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Shane Hathaway schreef:
* The SSO process should be very similar to an ordinary cookie-based login process. I don't want the user to have to enter their username on one form and their password on another, but that's the standard OpenID process.
* This will be implemented in Zope 3.
We are considering OpenID, Shibboleth, CAS, and any other mature system that others might suggest. Shibboleth seems like the most obvious fit, but it's nowhere near as popular as OpenID. I haven't yet looked at CAS in detail.
Alternatively, I have wondered if we actually need full-blown SSO; perhaps a carefully constructed domain-wide cookie would do the trick.
In the two cases where I've been involved in SSO, both times there was some apache module that could handle the actual SSO-part. The result from zope's viewpoint was either a special http header or a special cookie. Working from that header ("special_user=username_you_want") or cookie with similar contents is easy with zope2/plone's PAS and thus also zope2's authentication system which is mostly similar. You can look at http://svn.plone.org/svn/collective/PASPlugins/apachepas/ for some copy/paste code. So: easiest way is to let some trusted apache plugin handle the hard part and then laugh all the way to the bank with some 100-line authentication plugin. Reinout -- Reinout van Rees http://reinout.vanrees.org/
Reinout van Rees wrote:
So: easiest way is to let some trusted apache plugin handle the hard part and then laugh all the way to the bank with some 100-line authentication plugin.
That would usually work, but in this case, customers will be doing their own installation, so we need to keep the number of installation steps down. Shane
participants (5)
-
Gary Poster -
Marius Gedminas -
Reinout van Rees -
Shane Hathaway -
Wichert Akkerman