Single sign-on between Java and Python app

[Parag Shah]

I am making a DIY learning web app which is powered by Java. This webapp also needs forums, and I was thinking of using a StackExchange clone (maybe OSQA) made in Python. 

I am planning to use OpenId, Twitter, FB, and regular user accounts for authentication on my website. Is it possible to cleanly implement single sign-on between the main website and the various forums powered by OSQA?

Here is a typical scenario. A user comes to www.myapp.com and logs in. Then if she visits forums.myapp.com she should be automatically logged in.

I have been reading up possible solutions to this problem, and the one which seems smoothest is to use domain level cookies. I will not be able to use this solution across domains (which seems to be fine for now at least). I am not very keen to use session id's encoded in url's or as form data.

Has anyone had any experience implemented single sign-on across domains? Am very interested in knowing what sort of hiccups I might have to deal with, if I implement single sign-on. 

--
Thanks & Regards
Parag Shah
http://blog.adaptivesoftware.biz

[Dhananjay Nene]

Parag,

I would strongly suggest using OAuth for the same. Its the most comprehensive standard mechanism out there. You could of course use some home brew logic - but nothing beats using the defacto standard.

The initial digest computation and encryption and their counterparts (verification, decryption) can prove to be a bit of a hurdle. But usually once your handshake is stable, the rest of the things fall into place.

Dhananjay

--
You received this message because you are subscribed to the Google Groups "Python Pune" group.
To post to this group, send email to pytho...@googlegroups.com.
To unsubscribe from this group, send email to pythonpune+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pythonpune?hl=en.

--
--------------------------------------------------------
blog: http://blog.dhananjaynene.com
twitter: http://twitter.com/dnene

[Parag Shah]

Thanks Dhananjay,

I am going to read up more on OAuth. I understand it conceptually, and know that Twitter authentication is now OAuth based. 

However, would OAuth by itself support multi-site federated login? Perhaps a combination of OAuth and domain level cookies would be needed ?

-- 
Thanks & Regards
Parag Shah
http://blog.adaptivesoftware.biz

[dexterous]

If memory serves me well, OAuth is the protocol (much like OpenID) that you would implement from the consumer end and then wire to OAuth providers like Twitter, et al. That said, from whatever I've heard, you want to stay clear of OAuth v1 and stick to OAuth v2; much simpler to implement while simultaneously more secure.

Would love to see your findings/results.

- dexterous

[Dhananjay Nene]

On Sat, Dec 11, 2010 at 10:50 PM, Parag Shah <adap...@gmail.com> wrote:

Thanks Dhananjay,

I am going to read up more on OAuth. I understand it conceptually, and know that Twitter authentication is now OAuth based. 

However, would OAuth by itself support multi-site federated login? Perhaps a combination of OAuth and domain level cookies would be needed ?

Parag,

OAuth allows one authentication provider and multiple consumers. When you say multi-site federated - do you mean multiple authentication providers ? If so, I would certainly explore condensing them to a single authentication provider if all the sites are under single control. If it is that many sites are providers and consumers and each needs to respect authentication credentials provided by the other - that would imo be also better be implemented by culling out the provider functionality into a single common provider. If not, would need to understand more by what you mean by multi-site federated. 

Dhananjay

[शंतनू]

Few useful links:
1. http://stackoverflow.com/questions/3376141/openid-vs-oauth
2. http://www.clauswitt.com/openid-and-oauth-for-sso/
3. http://portalzone.blogspot.com/2007/12/openid-oauth-complimentary-or-competing.html

From [3]
===
In theory, OpenID and OAuth are complimentary. OpenID helps determine who you are (“authentication”) and OAuth defines how you give access to protected data (“authorization”). A site that supports OAuth could also support OpenID for authentication.

However, my view is a little different. Given that the current trend amongst the internet giants (Google, Yahoo and MSN) is to : (a) increase their user base (b) make more people use their services, OpenID might not excite them. It works against (a). Even AOL, which has 63 million OpenIDs does so by being an OP. They are still not a relying party (RP). It will be interesting to see how they support it. Will you be allowed access AOL services with any OpenID ? Will you be asked to fill a whole bunch of profile info after login?

OAuth on the other hand ought to please these companies. They can keep their entire use base and data to themselves and yet allow third parties to integrate into their services. The more the number of external websites that integrate with them, the more their services will be used (Almost all popular websites today release a "developer” API for the same reason).
===

I would go with OpenID. SSO is more like authentication than authorization, IMO.

[Dhananjay Nene]

2010/12/17 शंतनू <shan...@gmail.com>

Few useful links:
1. http://stackoverflow.com/questions/3376141/openid-vs-oauth
2. http://www.clauswitt.com/openid-and-oauth-for-sso/
3. http://portalzone.blogspot.com/2007/12/openid-oauth-complimentary-or-competing.html

From [3]
===
In theory, OpenID and OAuth are complimentary. OpenID helps determine who you are (“authentication”) and OAuth defines how you give access to protected data (“authorization”). A site that supports OAuth could also support OpenID for authentication.

However, my view is a little different. Given that the current trend amongst the internet giants (Google, Yahoo and MSN) is to : (a) increase their user base (b) make more people use their services, OpenID might not excite them. It works against (a). Even AOL, which has 63 million OpenIDs does so by being an OP. They are still not a relying party (RP). It will be interesting to see how they support it. Will you be allowed access AOL services with any OpenID ? Will you be asked to fill a whole bunch of profile info after login?

OAuth on the other hand ought to please these companies. They can keep their entire use base and data to themselves and yet allow third parties to integrate into their services. The more the number of external websites that integrate with them, the more their services will be used (Almost all popular websites today release a "developer” API for the same reason).
===

I would go with OpenID. SSO is more like authentication than authorization, IMO.

I think there are good reasons why OAuth adoption has far exceeded OpenID. Sure a large number of automatic open ids exist out there - but in terms of actual usage OAuth is rocketing up the charts. And thats because once you get shared authentication - you often want more - and OpenID lets you down there. OpenID is not an open ended journey which will allow you to build on your shared authentication story and then build a more integrated set of capabilities across federated applications sharing the same id.

While most articles do talk about OpenID = authentication and OAuth = authorisation, my individual view is that that is not correct. Open ID = explicit id based authentication and OAuth = implicit id based authentication + authorisation. When I use twitter OAuth, everything does get tied down to my id, and I do get logged in as my id (dnene). Its almost equivalent to me using an OpenID URL like http://twitter.com/dnene . The only thing that happens is that an "explicit user id" does not get exchanged in the handshake (though it would be trivial to implement it using an additional API call). I would today use OpenID instead of OAuth only under very careful set of restrictions (can't imagine what they would be) which would force my hand. Cos I can get everything with OAuth that I can get with OpenID and then a lot more. 

Especially read the last paragraph here: http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing

 

On 10-Dec-2010, at 11:06 PM, Parag Shah wrote:

> I am making a DIY learning web app which is powered by Java. This webapp also needs forums, and I was thinking of using a StackExchange clone (maybe OSQA) made in Python.
>
> I am planning to use OpenId, Twitter, FB, and regular user accounts for authentication on my website. Is it possible to cleanly implement single sign-on between the main website and the various forums powered by OSQA?
>
> Here is a typical scenario. A user comes to www.myapp.com and logs in. Then if she visits forums.myapp.com she should be automatically logged in.
>
> I have been reading up possible solutions to this problem, and the one which seems smoothest is to use domain level cookies. I will not be able to use this solution across domains (which seems to be fine for now at least). I am not very keen to use session id's encoded in url's or as form data.
>
> Has anyone had any experience implemented single sign-on across domains? Am very interested in knowing what sort of hiccups I might have to deal with, if I implement single sign-on.
>
>
> --
> Thanks & Regards
> Parag Shah
> http://blog.adaptivesoftware.biz

--
You received this message because you are subscribed to the Google Groups "Python Pune" group.
To post to this group, send email to pytho...@googlegroups.com.
To unsubscribe from this group, send email to pythonpune+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pythonpune?hl=en.

[Parag Shah]

A very quick thought before I read the links you guys have suggested.

As a comsumer, I have used both OATH (through Twitter) and OpenId (through Blogger) and from a pure consumer standpoint, I do not think there are many differences.

My application will be using openid and/or oauth purely for authentication and not authorization (well almost... unless I provide the feature to update a users Twitter timeline with what they are learning). The benefits I see are:
1. Users are not hassled with creating yet another account
2. Outsourced authentication
3. A third party authentication will (I think) make it easier to implement single sign-on across multiple sites

From a pure consumer standpoint, most people will not understand the difference openid or oath, but "login with Twitter", or "Login with Facebook", or "login with Blogger" makes sense to most poeple.


As a user of either protocols my biggest concern would be:
1. Ease of use to users
2. Ability to provide federated authentication
3. Security

I will read the links you guys have suggested and post back.

--
Thanks & Regards
Parag Shah
http://blog.adaptivesoftware.biz

[Parag Shah]

Hi Dhananjay,

By multi-site federated authentication, I mean, once a user has authenticated (let's say using oauth) on any of my sites, they are automatically authenticated on all other sites within the same domain.

So for example if a user goes to www.myapp.com and authenticates using Twitter oath, subsequently if they visit discussion.myapp.com, that website which is powered by another application should automatically identify that user.

Along with 3rd party authentication, I also have the challenge of how discussion.myapp.com knows that a user has already been authenticated by www.myapp.com I think domain cookies (cookies which will belong to myapp.com and can be read by all sub domains) might be the answer. The only other alternative I can think of is url re-writing which I am not very sure will even work seamlessly if both sites are powered by different applications (especially when I do no totally control at least one of them). I probably need to read up a bit more on this.

Has anyone tried this kind of monkeying around successfully  :-) ?

--
Thanks & Regards
Parag Shah
http://blog.adaptivesoftware.biz

[Chetan Pungaliya]

I have used cookies to implement SSO between our site and a partners site that were on separate sub domains and using separate software stack. We had the following logic:

On login at any the subdomain level: set a signed auth cookie for the top level domain along with the login for the app for the subdomain.

For each request for the app on the subdomain: if user is not authenticated, check for TLD auth cookie. If found and verified, set auth for the app.

The above assumes that you are able to extend the auth process for each subdomain and intercept all request.

Chetan

[Parag Shah]

Thanks Chetan, for sharing your sso workflow. This is a very good idea.

I have been doing some research on this over the weekend, and it looks like there are a few ways to handle SSO.

1. As Chetan suggested with top level domain cookies
2. sso links. This needs an app to provide a special link for federated sites (this link will identify the user). This has some security risks and also will not work if the user enters the new url in the adress bar instead of following the special link. There is a django project for this, In case anyone is interested (http://code.google.com/p/django-sso/).
3. Redirection (first time when a user comes to a federated site, redirect her to the login site. If the user is already logged in then the login site will redirect her back to the original site with an id). This will work, but may detract from the user experience.
4. Javascript (a little JS code on all federated sites can contact the main login site with it's own cookies) and determine if the user is logged in
5. Django seems to support REMOTE_USER which is an environment variable set by Apache when the web server has logged in someone. I think this can be used also, but I need to figure out how a login webapp can set the REMOTE_USER variable in Apache. I also think this will break down if the federated sites are spread over multiple web servers.

From these approaches I like #1, and #4 since they offer the smoothest user experience and also (to me) seem the most secure.

Any further thoughts on security and user experience?

--
Thanks & Regards
Parag Shah
http://blog.adaptivesoftware.biz

[dexterous]

you want to be careful with #4 'cause certain browsers might just block those requests as XSS

- d

[Parag Shah]

Thanks, I totally missed that aspect. I plan to try out OSQA soon. Will report my findings here. Thanks to all for the help.

-- 
Thanks & Regards
Parag Shah
http://blog.adaptivesoftware.biz

On Mon, Dec 20, 2010 at 12:59 PM, dexterous <saager...@gmail.com> wrote:

you want to be careful with #4 'cause certain browsers might just block those requests as XSS

- d