[Product-Developers] Single sign on across heterogenuous systems

[Martin Aspeli-2]

Hi all,

I have a Plone site that will maintain a member database and content.
One part of the site will go off to a "white labelled" (i.e. same style
sheet and template) shop system hosted by a third party, on completely
separate infrastructure. The shop will live on shop.domain.com and the
Plone site on domain.com.

I would like to support single sign-on and shared member data across
these two sites. In particular, users should only sign onto the Plone
site. When they enter the shop, they should appear logged in there if
they were logged into the Plone site (if they're not, there'll be a "log
in" link that goes back to the Plone site). Member data should only be
held in one place, the Plone site.

The shop site thus needs some way to:

  - Find out if the current user is logged into the Plone site

  - Retrieve member data for the current user

I'm wondering what the best approach for this might look like. The best
approach I can think of, is to always pass a unique, time-limited ID
from Plone site to shop when users click any link in the Plone site that
goes to the shop. This ID would be mapped to a Plone session. The site
then does a server-side call-back over HTTP to the Plone site, asking if
the user with the given ID has a valid session, and if so receiving
member data in the response.

This may work, but it's a bit clunky. It won't work if users have
bookmarks to the shop or hit it via some other URL. And it may make
session theft easier.

What better approaches are there? Do we have any tools for this? Could a
solution potentially be generalised (in which case I'd like to do so an
open source it).

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Sidnei da Silva-2]

What you describe sounds a lot like what OpenID. Maybe what you want
to do is to make Plone an OpenID provider, and use an OpenID library
in your commerce site.

On Mon, Jun 30, 2008 at 6:44 PM, Martin Aspeli <optilude@...> wrote:

> Hi all,
>
> I have a Plone site that will maintain a member database and content. One
> part of the site will go off to a "white labelled" (i.e. same style sheet
> and template) shop system hosted by a third party, on completely separate
> infrastructure. The shop will live on shop.domain.com and the Plone site on
> domain.com.
>
> I would like to support single sign-on and shared member data across these
> two sites. In particular, users should only sign onto the Plone site. When
> they enter the shop, they should appear logged in there if they were logged
> into the Plone site (if they're not, there'll be a "log in" link that goes
> back to the Plone site). Member data should only be held in one place, the
> Plone site.
>
> The shop site thus needs some way to:
>
>  - Find out if the current user is logged into the Plone site
>
>  - Retrieve member data for the current user
>
> I'm wondering what the best approach for this might look like. The best
> approach I can think of, is to always pass a unique, time-limited ID from
> Plone site to shop when users click any link in the Plone site that goes to
> the shop. This ID would be mapped to a Plone session. The site then does a
> server-side call-back over HTTP to the Plone site, asking if the user with
> the given ID has a valid session, and if so receiving member data in the
> response.
>
> This may work, but it's a bit clunky. It won't work if users have bookmarks
> to the shop or hit it via some other URL. And it may make session theft
> easier.
>
> What better approaches are there? Do we have any tools for this? Could a
> solution potentially be generalised (in which case I'd like to do so an open
> source it).
>
> Cheers,
> Martin
>
> --
> Author of `Professional Plone Development`, a book for developers who
> want to work with Plone. See http://martinaspeli.net/plone-book
>
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers@...
> http://lists.plone.org/mailman/listinfo/product-developers
>

--
Sidnei da Silva
Enfold Systems http://enfoldsystems.com
Fax [phone] Office [phone] Ext 214

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Rob Miller]

Martin Aspeli wrote:

> Hi all,
>
> I have a Plone site that will maintain a member database and content.
> One part of the site will go off to a "white labelled" (i.e. same style
> sheet and template) shop system hosted by a third party, on completely
> separate infrastructure. The shop will live on shop.domain.com and the
> Plone site on domain.com.
>
> I would like to support single sign-on and shared member data across
> these two sites. In particular, users should only sign onto the Plone
> site. When they enter the shop, they should appear logged in there if
> they were logged into the Plone site (if they're not, there'll be a "log
> in" link that goes back to the Plone site). Member data should only be
> held in one place, the Plone site.
>
> The shop site thus needs some way to:
>
>  - Find out if the current user is logged into the Plone site
>
>  - Retrieve member data for the current user
>
> I'm wondering what the best approach for this might look like. The best
> approach I can think of, is to always pass a unique, time-limited ID
> from Plone site to shop when users click any link in the Plone site that
> goes to the shop. This ID would be mapped to a Plone session. The site
> then does a server-side call-back over HTTP to the Plone site, asking if
> the user with the given ID has a valid session, and if so receiving
> member data in the response.
>
> This may work, but it's a bit clunky. It won't work if users have
> bookmarks to the shop or hit it via some other URL. And it may make
> session theft easier.
>
> What better approaches are there? Do we have any tools for this? Could a
> solution potentially be generalised (in which case I'd like to do so an
> open source it).

you don't state how much influence you have over the 'shop' application, but
you mention having the site make an HTTP call to Plone so i'm going to assume
that it's possible to do some custom coding on that side.

in the OpenPlans stack, which actually consists of several HTTP services all
acting as a single 'site', we accomplish something like this by having all of
our apps honor Plone's authentication cookie.  we have a custom PAS cookie
auth plug-in which creates an auth cookie as a hash of the username and a
secret key.  all of the apps have a copy of the secret, so they can verify
that the cookie is to be trusted.  since your apps are going to be on the same
domain, you can use a domain wildcard cookie and the remote hosted application
will get it.

if you want session timeouts, you could integrate a time component into the
hash key generation, something that each side knows to change every 2 hours or
so.  you can do whatever you want, as long as both apps have all the
information needed to generate the hash key.

of course, you still have the matter of getting the shop app to redirect to
the Plone login page when it needs to present a challenge.

as for sharing more detailed member info, HTTP calls back to Plone is probably
the way to go.  or else use a custom PAS properties plug-in and store the info
somewhere else, where the other app might have more direct access.

-r


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[David Durham, Jr.]

On Mon, Jun 30, 2008 at 6:04 PM, Sidnei da Silva
<sidnei@...> wrote:
> What you describe sounds a lot like what OpenID. Maybe what you want
> to do is to make Plone an OpenID provider, and use an OpenID library
> in your commerce site.

I initially thought about OpenID for this but decided it wasn't a good
fit.  I ended up modifying SQLPASPlugin and plone such that 1) the
login form obtains a session cookie value for my "other site(s)" with
jquery and stores that as a hidden field value to be submitted along
with username and password.  2) Modify SQLPASPlugin to store the
cookie value and associate it with the username.  You don't get all of
the plone security, for instance ACL is not stored in the DB (as I
recall), but you should get roles and groups.

I've obviously skipped a lot of details.  What happens if the JQuery
ajax call for a sessionid fails?


-Davve

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Wichert Akkerman]

Previously Martin Aspeli wrote:

> Hi all,
>
> I have a Plone site that will maintain a member database and content.
> One part of the site will go off to a "white labelled" (i.e. same style
> sheet and template) shop system hosted by a third party, on completely
> separate infrastructure. The shop will live on shop.domain.com and the
> Plone site on domain.com.
>
> I would like to support single sign-on and shared member data across
> these two sites. In particular, users should only sign onto the Plone
> site. When they enter the shop, they should appear logged in there if
> they were logged into the Plone site (if they're not, there'll be a "log
> in" link that goes back to the Plone site). Member data should only be
> held in one place, the Plone site.

This sounds like something where CAS, possibly in combination with LDAP,
provides an out-of-the-box solution.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Martin Aspeli-2]

Sidnei da Silva wrote:
> What you describe sounds a lot like what OpenID. Maybe what you want
> to do is to make Plone an OpenID provider, and use an OpenID library
> in your commerce site.

Yeah, that thought did cross my mind. However, I'm not sure

  a) how to run an openid server

  b) whether this truly provides single sign-on, or if the user still
has to log in twice

I thought openid required re-authentication for each site?

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Martin Aspeli-2]

Wichert Akkerman wrote:

> Previously Martin Aspeli wrote:
>> Hi all,
>>
>> I have a Plone site that will maintain a member database and content.
>> One part of the site will go off to a "white labelled" (i.e. same style
>> sheet and template) shop system hosted by a third party, on completely
>> separate infrastructure. The shop will live on shop.domain.com and the
>> Plone site on domain.com.
>>
>> I would like to support single sign-on and shared member data across
>> these two sites. In particular, users should only sign onto the Plone
>> site. When they enter the shop, they should appear logged in there if
>> they were logged into the Plone site (if they're not, there'll be a "log
>> in" link that goes back to the Plone site). Member data should only be
>> held in one place, the Plone site.
>
> This sounds like something where CAS, possibly in combination with LDAP,
> provides an out-of-the-box solution.

You mean http://www.ja-sig.org/products/cas?

Do we have any examples of this used in Plone?

Thanks!

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Martin Aspeli-2]

Hi Rob,

> you don't state how much influence you have over the 'shop' application, but
> you mention having the site make an HTTP call to Plone so i'm going to assume
> that it's possible to do some custom coding on that side.

It is. I'm not writing it, but I can ask someone else to do some coding.
It's not written in Python, though.

> in the OpenPlans stack, which actually consists of several HTTP services all
> acting as a single 'site', we accomplish something like this by having all of
> our apps honor Plone's authentication cookie.

Will this not only work if all the apps are on the same domain? The shop
is hosted on a completely separate infrastructure and will be DNS'd into
a subdomain.

> we have a custom PAS cookie
> auth plug-in which creates an auth cookie as a hash of the username and a
> secret key.  all of the apps have a copy of the secret, so they can verify
> that the cookie is to be trusted.  since your apps are going to be on the same
> domain, you can use a domain wildcard cookie and the remote hosted application
> will get it.

I see. Any documentation on how those work?

> if you want session timeouts, you could integrate a time component into the
> hash key generation, something that each side knows to change every 2 hours or
> so.  you can do whatever you want, as long as both apps have all the
> information needed to generate the hash key.

Cool.

> of course, you still have the matter of getting the shop app to redirect to
> the Plone login page when it needs to present a challenge.

That's ok, I think. They'll just code it that way, and Plone will
redirect back using a came_from URL parameter.

> as for sharing more detailed member info, HTTP calls back to Plone is probably
> the way to go.  or else use a custom PAS properties plug-in and store the info
> somewhere else, where the other app might have more direct access.

Cool!

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Yuri-11]

Martin Aspeli ha scritto:

> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> Hi all,
>>>
>>> I have a Plone site that will maintain a member database and
>>> content. One part of the site will go off to a "white labelled"
>>> (i.e. same style sheet and template) shop system hosted by a third
>>> party, on completely separate infrastructure. The shop will live on
>>> shop.domain.com and the Plone site on domain.com.
>>>
>>> I would like to support single sign-on and shared member data across
>>> these two sites. In particular, users should only sign onto the
>>> Plone site. When they enter the shop, they should appear logged in
>>> there if they were logged into the Plone site (if they're not,
>>> there'll be a "log in" link that goes back to the Plone site).
>>> Member data should only be held in one place, the Plone site.
>>
>> This sounds like something where CAS, possibly in combination with LDAP,
>> provides an out-of-the-box solution.
>
> You mean http://www.ja-sig.org/products/cas?
>
> Do we have any examples of this used in Plone?

I've tested shibboleth and Plone, works fine.

http://tid.ithaka.org/software

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Laurence Rowe]

My personal favourite for this is mod_auth_tkt (http://www.openfusion.com.au/labs/mod_auth_tkt/), as it seems to me the simplest of the single sign on systems. It is a simple shared secret system with signed cookies.

It installs as an apache module (simple ./configure --with-apxs=/usr/bin/apxs2; make; make install on ubuntu). Works as a dropin substitute for basic authentication, so if the other application is running in apache there is nothing to change. If proxying the X-Authenticated-User header is set. It's possible to set the cookie domain to .domain.com to support shop.domain.com and www.domain.com

I've got a branch of plone.session here that implements the protocol (no apache required, but compatible - I'm using it to log users in apache logs) http://dev.plone.org/plone/browser/plone.session/branches/elro-tktauth

There is space in the cookie for user data, so you could easily put full name in here, or more if you want to extract it with regular expressions to an apache env variable. If you need more than this then I suggest just looking up the metadata in another system (ldap or sql).

OpenID isn't really for this use case (a single system).

Because the non plone site can verify the cookie is valid, no callback needs to be made to the plone site. I don't know of any standards for doing HTTP callbacks for user metadata, LDAP is the standard for this sort of data really.

Laurence

Martin Aspeli wrote:

Hi all,

I have a Plone site that will maintain a member database and content.
One part of the site will go off to a "white labelled" (i.e. same style
sheet and template) shop system hosted by a third party, on completely
separate infrastructure. The shop will live on shop.domain.com and the
Plone site on domain.com.

I would like to support single sign-on and shared member data across
these two sites. In particular, users should only sign onto the Plone
site. When they enter the shop, they should appear logged in there if
they were logged into the Plone site (if they're not, there'll be a "log
in" link that goes back to the Plone site). Member data should only be
held in one place, the Plone site.

The shop site thus needs some way to:

  - Find out if the current user is logged into the Plone site

  - Retrieve member data for the current user

I'm wondering what the best approach for this might look like. The best
approach I can think of, is to always pass a unique, time-limited ID
from Plone site to shop when users click any link in the Plone site that
goes to the shop. This ID would be mapped to a Plone session. The site
then does a server-side call-back over HTTP to the Plone site, asking if
the user with the given ID has a valid session, and if so receiving
member data in the response.

This may work, but it's a bit clunky. It won't work if users have
bookmarks to the shop or hit it via some other URL. And it may make
session theft easier.

What better approaches are there? Do we have any tools for this? Could a
solution potentially be generalised (in which case I'd like to do so an
open source it).

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


_______________________________________________
Product-Developers mailing list
[e-mail]
http://lists.plone.org/mailman/listinfo/product-developers

[Matthew Wilkes]

On Heisei 0020-07-01, at 082743BST, Martin Aspeli wrote:

> Yeah, that thought did cross my mind. However, I'm not sure
>
> a) how to run an openid server

I've been working on circulartriangle.openid (collective) that's  
nowhere near ready as I've not had much time to play but it _does_  
provide a working OpenID server for some simple by-hand testing.

> This sounds like something where CAS, possibly in combination with  
> LDAP,
> provides an out-of-the-box solution.

Indeed, CAS authentication working with Plone is nice and simple, it's  
in use all over bris.ac.uk and ubu.org.uk.

> I've tested shibboleth and Plone, works fine.

Also fine, although shibboleth works very differently, you often don't  
get an assertion of the username, just his privileges.  Bit more  
hassle to set up too, although I was federating through JANET so it  
may be easier to run your own federation.

Also, I've got Stanford webauth working with Plone, although the  
Apache plugin can be a bit flaky.

Matt



_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Rob Miller]

Martin Aspeli wrote:

> Hi Rob,
>
>> you don't state how much influence you have over the 'shop'
>> application, but you mention having the site make an HTTP call to
>> Plone so i'm going to assume that it's possible to do some custom
>> coding on that side.
>
> It is. I'm not writing it, but I can ask someone else to do some coding.
> It's not written in Python, though.
>
>> in the OpenPlans stack, which actually consists of several HTTP
>> services all acting as a single 'site', we accomplish something like
>> this by having all of our apps honor Plone's authentication cookie.
>
> Will this not only work if all the apps are on the same domain? The shop
> is hosted on a completely separate infrastructure and will be DNS'd into
> a subdomain.

if it's on a subdomain, you should be fine.  if it's on a different domain
altogether, it'd be trickier.

>> we have a custom PAS cookie auth plug-in which creates an auth cookie
>> as a hash of the username and a secret key.  all of the apps have a
>> copy of the secret, so they can verify that the cookie is to be
>> trusted.  since your apps are going to be on the same domain, you can
>> use a domain wildcard cookie and the remote hosted application will
>> get it.
>
> I see. Any documentation on how those work?

there's not much to document.  you just set a cookie and explicitly use
".yourdomain.com" as the cookie domain, rather than the FQDN, which is what
the cookie will default to if you don't specify.

here's the code for the OpenPlans PAS plug-in... this generates the cookie
hash value, and sets two cookies, one for the FQDN and one explicitly set to
the domain that the browser_id_manager specifies, which in our case is
".openplans.org".  you can see both cookies in your browser when you're logged
into the site.

http://trac.openplans.org/openplans/browser/opencore/trunk/opencore/auth/SignedCookieAuthHelper.py

hope that's useful,

-r


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[shurik]

hi martin,

authenticating against cas in plone is implemented using CAS4PAS (http://dev.plone.org/collective/browser/Products.CAS4PAS) and collective.castle (http://dev.plone.org/collective/browser/collective.castle). the collective.castle has a stable branch that exposes CAS4PAS configuration as a plone control panel.

note that these two enable plone to authenticate a plone site against a cas server, not to act as one. we have been using the two packages and they work. we do authorization against an LDAP server but i suppose it may be possible to authz against source users as well as long as there's a common user ID.

shurik

Martin Aspeli wrote:

Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> Hi all,
>>
>> I have a Plone site that will maintain a member database and content.
>> One part of the site will go off to a "white labelled" (i.e. same style
>> sheet and template) shop system hosted by a third party, on completely
>> separate infrastructure. The shop will live on shop.domain.com and the
>> Plone site on domain.com.
>>
>> I would like to support single sign-on and shared member data across
>> these two sites. In particular, users should only sign onto the Plone
>> site. When they enter the shop, they should appear logged in there if
>> they were logged into the Plone site (if they're not, there'll be a "log
>> in" link that goes back to the Plone site). Member data should only be
>> held in one place, the Plone site.
>
> This sounds like something where CAS, possibly in combination with LDAP,
> provides an out-of-the-box solution.

You mean http://www.ja-sig.org/products/cas?

Do we have any examples of this used in Plone?

Thanks!

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


_______________________________________________
Product-Developers mailing list
[e-mail]
http://lists.plone.org/mailman/listinfo/product-developers

[Alexander Limi]

On Tue, 01 Jul 2008 03:22:24 -0700, Laurence Rowe <l@...> wrote:

> I've got a branch of plone.session here that implements the protocol (no
> apache required, but compatible - I'm using it to log users in apache  
> logs)
> http://dev.plone.org/plone/browser/plone.session/branches/elro-tktauth

That's very cool, is there anything that would stop us from making the  
slightly different ticket hash the default for Plone? Seemed sane to me  
 from the diffs, but then again I don't know these systems very well. :)


--
Alexander Limi · http://limi.net


_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

[Laurence Rowe]

Alexander Limi wrote:

On Tue, 01 Jul 2008 03:22:24 -0700, Laurence Rowe <[e-mail]> wrote:

> I've got a branch of plone.session here that implements the protocol (no
> apache required, but compatible - I'm using it to log users in apache  
> logs)
> http://dev.plone.org/plone/browser/plone.session/branches/elro-tktauth

That's very cool, is there anything that would stop us from making the  
slightly different ticket hash the default for Plone? Seemed sane to me  
 from the diffs, but then again I don't know these systems very well. :)

Nothing in principle, thoug the plone.session interfaces need reworking a little to support refreshing tickets so you are not locked out mid session.

Laurence