the single-signon options for mere-Drupal-mortals seem to be pretty thin, which is rather suprizing considering the flagship Drupal Gardens uses OpenID
I am looking at setting-up a network of sites within Aegir hosting and I've been spending a lot of time spinning my wheels with Bakery and OpenID type "solutions" - I've been annoying people and arguing and basically struggling through up the learning curve
the out-dated but sophisticated OSSO (OpenID Simple (Not Single) Sign On) solution on github from Development Seed has been reworked and there are now two modules in sandbox and two install profiles thanks to http://drupal.org/user/359937 xamanu who is working on an installation profile called OmniAuth OpenID Single Signon
the Central American Drupal meetup just happened and there is a presentation in Spanish about this
http://drupal-centroamerica.org/en/sesion/proveedor-de-openid-con-drupal
http://drupal-centroamerica.org/sites/default/files/proveedor-openid.odp
I've asked for paid support, but also looking to work with others on a peer-to-peer basis, looking for helpers here to work through this with me
I've personally reach a blocker with my project based on site-networks because of single-signon or even simple signon
the sandboxed modules
http://drupal.org/sandbox/xamanu/1153576
http://drupal.org/sandbox/xamanu/1153574
drush make http://gitorious.org/openid_sso/makefiles/blobs/raw/master/osso_provider...
drush make http://gitorious.org/openid_sso/makefiles/blobs/raw/master/osso_relying_ax.makecustom hacks of user tables just dont seem right (especially after all the hype around Drupal's core inclusion of OpenID)
Comments
slightly similiar situation, but are trying another way....
Niccolo, very interesting, we have had similar frustrations.
I'm posting some stuff in my Blog (http://www.robgdarwin.com/?p=121) and we have posted an initial job on odesk (
https://www.odesk.com/jobs/Preliminaries-for-shop-site-redevelopment-wit... )
This may not be exactly what you are looking for, but maybe we are trying to achieve the same thing.
Our user experience is a central site, where the user is registered, and then auto registering them and auto logging them in on all the other sites. On all the other sites we do not bother the user with their id, they log in either through a cookie that was previously set, or a "federated session key" that is communicated around with various links. We spent a couple of weeks playing with various standards and decided that it would be quicker with a home grown approach.
Would be happy to compare notes.
Regards from sunny London...Rob
Bakery uses Cookies
see my blah on Bakery, its used for Drupal's site network - like you the Drupal inner-circle bypassed OpenID and baked their own cookies
http://drupal.org/node/1151020
a very long OpenID thread
http://drupal.org/node/556380#comment-4584432
"Build It and They Will Come"
Salut RobD-London et niccolo--
I am also in a similar situation looking to get a federated network of Drupal sites to work. Even got an o-desk job that I am planning on posting in a couple weeks. I've been busy with other stuff (i.e. life), but looking to re-engage in this project in the coming weeks.
niccolo, after reading some of your postings, I can understand some of the frustration you are feeling. If it had been me battling these problems (as I will be soon), I'm sure the frustration is justified. That said, I feel our needs and use cases align enough that it would be good to pool our resources on this and attempt to move this issue forward. I'm in the position to provide some coding, lots of testing, documentation and (some) funding.
One question, have you brought this issue up with the Aegir folks for what they think is the best approach? I think using Bakery would be impossible due to the way Aegir works. I'm open to building from scratch but it's surprising nothing has worked out just yet.
"Build It and They Will Come"
Mark
I've been having this problem
I've been having this problem too and no solution fits my needs. Right now, I'm trying the LDAP approach, I don't know if I'll even make it work or if is a viable solution for all of us, but at least, if you're using Aegir, it means you have at least a VPS and you should be able to install any package required to make this work.
I'm not an expert in cookies and all that stuff but I could help write something with PHP. The goals, I think, should be:
Am I missing something? Add it please.
Luis
Single Signon g.d.o pending
what is kinda annoying, is that 2008/2009 there was a lot of activity around OpenID within Drupal and out, for single signon and other simpler identity management experiences
since then, OpenID providers have welcomed the giants like Google and Wordpress and Drupal Gardens and other Drupal-based businesses seem to have made implementations, but for whatever reasons Drupal.org itself didn't do a single signon with OpenID, instead it handrolled a cookies, single or sub-domain solution called Bakery
so, Drupal Gardens has OpenID-based indentity management, but Drupal.org does not. Dev Seed which did the best implementation have totally left Drupal development, over the smallcore issue - which is very directly related to OpenID in core
one could speculate, that maybe if OpenID was contrib, and more responsive to community needs, the rest of us, not just Drupal Gardens would be using it today for Single Signon
http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted=&participant=&component[]=openid.module&issue_tags_op=or&issue_tags=
I am about to upgrade to D6.22 and see if that helps, maybe its much better in D7.2. If so, they modules associated with Omniauth might need an upgrade
at the moment I am putting my money on
https://gitorious.org/omniauth
https://gitorious.org/~xamanu
will post an update if/when the new Single Signon group is authorized
Drupal Gardens OpenID Provider
from the source
https://www.drupalgardens.com/user
<link rel="openid2.provider" href="https://www.drupalgardens.com/openid/provider" /><link rel="openid.server" href="https://www.drupalgardens.com/openid/provider" />
weirdly, there is no public domain D7 OpenID Provider, only a proprietary Drupal Gardens one...http://drupal.org/node/983128#comment-4587406
makes me wonder what constitutes a conflict of interest, what's the decision making factor for open vs closed code etc
I guess we should petition for the release of the codebase
Drupal Gardens uses D6 for OpenID Provider
see http://drupal.org/node/983128#comment-4589286
its actually very simple
not using the above approach, doing a much easier system, with a different version of the OpenID SSO module
I got OpenID Single Signon working, with a D6 OpenID Provider allowing all the major distro's to login; OpenAtrium, Drupal Commons, Nodestream, COD, Uber Drupal, see list http://groups.drupal.org/node/140874#comment-518904
doesn't work for D7 - modules need update, no D7 OpenID Provider yet
also, havent got Push_User and Node_Sync modules running...
its amazing, the solution has been sitting in github and no-one has posted about it, I fail to understand why its not wildly popular
Where on github? You didn't
Where on github? You didn't mention any github repository. Do you mean the repositories at gitorious you posted?
https://gitorious.org/omniauth
https://gitorious.org/~xamanu
Luis
try this
sorry, some comments and explainations
http://groups.drupal.org/node/140874#comment-518904
http://groups.drupal.org/node/140874#comment-518979
OpenID Provider SSO module
https://github.com/permaculturecoop/openid_provider_sso
OpenID Single Signon module
https://github.com/permaculturecoop/openid_sso
Thanks. Great, this is
Thanks. Great, this is actually working. Two thoughts.
Luis
good point luis. I think the
good point luis.
I think the broken login box and this admin issue combined - in amongst my openid sso haze - to throw me off the trail
how do we admin client sites?
By visiting
By visiting
http://yourdomain.x/login/direct;-) Here you can login as user 1.that doesnt work for me
just installed again, within Aegir and on relying get this admin login problem, I created a sandbox issue, http://drupal.org/node/1188878
when installing a provider site, the site install fails
http://drupal.org/node/1188886
also noticed Jquery not found in contrib, copied into modules root and it worked I think, havent looked into that
I think luis got the first problem http://drupal.org/node/1188878
the second one http://drupal.org/node/1188886 is Aegir specific I think
Omnia WORKING
I got Omniauth working with xamanu's help - CHEERS DUDE !
I am now running a stock Drupal 6 OpenID Provider with the SSO modules, and as relying parties I have
- 2 D6 stocks - no problems
- OpenAtrium 10 (a workaround, had to turn-off clashing Atrium Profile feature long enough so I could install and enable to the osso relying feature, also had to turn off the profile image)
- Drupal Commons 1.6 (had to disable password_policy module)
- UberDrupal - no problems
- COD 1.3 - no problems
and I can happily report Omniauth does a great job of integrating all of these in a single signon experience !!
Thank you Niccolo for this
Thank you Niccolo for this deeply testing in a real scenario!
We might have to think about a Omniauth-Lite version, that would not include automated fields for profiles with preconfigured exchange attributes. This version would more likely run with OpenAtrium and other distros that you had need to disable some profile modules/features. Actually it might be easier to just install the modules needed (openid_relying_sso, openid_client_ax and openid_profile or openid_cp_field) to achieve your desired functionality for the distros instead of using the whole Omniauth package. This way you'd have to configure the fields on each site. Unfortunately, Features itself and the whole configuration in code for Drupal is not at a level to handle this overridden states of configuration over another, like it is when trying to install Omniauth over OpenAtrium.
this is kind of the approach
this is kind of the approach i used.
I installed both the provider and relying installation profiles using the make files into Aegir. Created sites, then copied the modules across to D6, COD, OA, DC, UC etc... and then used the Feature to set-up everything. On Atrium the feature clashed and so i turned off the Atrium feature (leaving the modules enabled) and then turned on the Omnia feature. Then I turned off the Omnia feature, leaving the modules enabled and turned on the Atrium Profile feature again.
I tried again to do the manual config as you suggested, still working on that, although, right now, I am thinking of leveraging your profiles and just tweaking OpenAtrium for the present. If I ever need to roll-out lots of OA I'll work out a better fix. Right now, it works fine. CHEERs
Omniauth is exactly that (and
Omniauth is exactly that (and some good improvements and available on drupal.org). You can learn how to get it to work with this screencast: http://vimeo.com/25103388
Please don't double work. This would be a pity.
Actually all essential modules are already on d.o (at least in a Sandbox for now). See the module overview table:
Table modified at 4th of July 2011
no duplicate effort from me.
no duplicate effort from me. I am too busy with my day job for competitive efforts
how do we help you get this published?
Great clarification!
Great clarification!
awesome it would be worth
awesome
it would be worth creating a NEW Discussion thread, without all this noise...
testing now in Aegir, will try common distros as relying (UberDrupal, OpenAtrium, Drupal Commons etc)
install, Jquery and Aegir errors
see sandboxed issues
Yes please. All direct issues
Yes please. All direct issues into the issue queues of the modules.
Further, I created a post as a summary, so that it would be easier to find information about Omniauth: http://groups.drupal.org/node/155799
could you also update the
could you also update the .info files?
this was also a place of confusion for me... so many variants, so little qualifications. for instance, the provider still has the old info, the exact same description as in the Dev Seed modules..
suggestion, use the OmniAuth name space
name = "OpenID Provider SSO - OmniAuth"description = "Set up a trusted web of sites and use OpenID to provide simple Sign-On - OmniAuth"
core = 6.x
package = "OpenID"
dependencies[] = openid_provider
I created an issue for that:
I created an issue for that: http://drupal.org/node/1189616
Thanks for reporting. Patches are very welcome ;-)
First, thanks to Felix,
First, thanks to Felix, you've done an amazing work with this, I actually think this is a great start point, I now see that the problem was that this wasn't documented and it was causing all kind of confusions, but the screencast made it really clear for all of us.
Second, I'll be installing this without the Omniauth dist to see if I can make it work (I'm sure I will), I already have my sites setup so I can't use the Omniauth dist as a starting point.
Finally, I really think that going to a full size project instead of a sandbox would be easier for everybody. The projects might not be ready for production sites, but definitely are ready to be full projects. You could create only dev releases or even a first alpha, even an unstable version if you wish. If you don't have permissions to go full project, I think I could help with that.
Luis
Thanks Luis for documenting
Thanks Luis for documenting on how to install the SSO functionality without Omniauth! (http://groups.drupal.org/node/155799#comment-522029)
This is really useful and a first starting point for documentation for the openid_provider_sso and openid_relying_sso, which is one important step to get this modules out there. I encourage you to do even more specific documentation (maybe on a real node and not just a post) that we could use for those modules. Great work!
I have the permissions to promote the modules to full projects, but this would involve a lot of responsibility for my person, and I'm not sure if I can get enough time to do all the work. So, to get this officially published, we'd need more contributers (f.e. like you in documentation, but as well CODERS!!) and/or clients who finance further development. It is a pretty big project to do in free time and alone.
I can understand that it is uncomfortable to not have a full project, in a sense of upgrading, obtaining the module, etc. But it is just not ready for everybody and this is probably a good filter, in oder to make sure that not pure end users use this work in progress. On the same time it enables people who are seriously interested to work on it. And what can I say: It's ready when it's ready.
It's great to have you guys testing it and hopefully documenting it nicely. Let's use the issue queues and give OpenID a little importance again :-)
To be honest, I haven't had
To be honest, I haven't had time to try this, but everything is clear now that I know that every project needed is hosted on d.o.
About the full project issue, I could help co-maintain this, like you, I'm doing a hundred things at the same time but once I get to know the module maybe I could help. But not at the time, first, I have to test it.
Luis
Omniauth should be a project
I agree, it should be a project, there are too many moving parts, the use-cases too many, to have the issues scattered across full release and sandboxed modules on d.o and gitorious projects
I've posted issues for the profiles to the sandboxed modules issue lists, which is not good form, some of these issues need to be pushed over to the Hostmaster (Aegir) project and how do we do that when we are on gitorious or using the wrong project?
So I just tested the
So I just tested the installation without the Omniauth dist and I can report that it works. Amazing, Thanks to Felix for the hard work on this.
One small bug.
In my relying site, I had this block with a login button. If I click the login button, I get redirected (as I should) to the provider site, if I'm already logged in, it will just ask me if I want to login in the relying site (as it should), if I say yes, I then get redirected to the relying site (as it should). But, I get an access denied page, although I'm logged in, an access denied page is not a good thing.
The way to solve this is to create a new link to the http://relying.example.com/user path and problem solved.
Edit: I didn't test this in aegir, but it shouldn't be a problem.
Edit 2: It seems that the problem is the fact that I'm already logged in the provider site.
Luis
try this
/*** Request authentication.
*/
function openid_relying_sso_request() {
$provider = variable_get('openid_relying_sso_provider', array());
$front = drupal_get_normal_path(variable_get('site_frontpage', 'node'));
$values = array(
'openid_identifier' => $provider['url'],
'openid.return_to' => url('openid/authenticate', array('absolute' => TRUE, 'query' => "destination=$front")),
);
openid_begin($values['openid_identifier'], $values['openid.return_to'], $values);
}
Great Luis! Cool that it is
Great Luis! Cool that it is working now.
Please file bugs into the respective issue queues (http://drupal.org/project/issues/1153576 or http://drupal.org/project/issues/1153574). Thank you.
yes, the bugs luis reported
yes, the bugs luis reported do not now exist !
a very smooth user experience
why not promote those projects?!
Those seem to be mature projects with good code bases. Why not promote them to real projects?!
I opened an issue about this in one of the projects, it can migrate between the different projects as they are promoted. :) http://drupal.org/node/1197026
Also, just a hint: i'm one of the maintainer of the openid_provider project so I am curious to hear a) if the stack uses that project and b) if you need help! ;)
Let me know in the openid_provider issue queue...
These are full projects
These are full projects now:
* http://drupal.org/project/openid_sso_provider
* http://drupal.org/project/openid_sso_relying
Bakery problem thoughts
It seems to me that the bakery problem may be introduced through Aegir's settings.local breaking the settings.php cookie_domain. Has anyone on the Aegir team tried this out to see if it interrupts the cookie_domain variable?
Dominic Thomas, PhD
Systems Design and Architecture Consultant
Assoc. Prof. of IS
Co-Director Center for Innovative Collaboration Leadership
Suffolk University, Boston, MA, USA
how does this relate to CAS?
Hi, likely a dumb question, but why not a CAS approach?
http://drupal.org/project/cas
I thought that was going to be the best solution, until I read these posts. Would someone be able to explain the differences?
I can only talk for my
I can only talk for my experience, but there are several reasons why I didn't choose CAS. I must tell you first that while I tried to configure CAS, I couldn't make it work and I moved to OpenID.
Having said that, I can tell you that CAS is not a Drupal solution, it doesn't integrate perfectly with Drupal. Profiles integration was a dream with CAS and the login experience was not the same as Drupal.
Speaking about OpenID, one of the main advantages of OpenID is that you can use OpenID with Facebook, twitter, Google, Linkedin, etc. This is not possible (not that I know) with CAS.
There are probably more differences between CAS and OpenID but right now, and since I wasn't able to make it work, is all I can say about CAS.
Luis
informative, thank you
Thank you, Luis, this is hugely informative to me.
I was about to waste a lot of time, or so it looks. I have about four sites on different domains where I would like single signon, but even better would be if the initial account could be from Facebook. I have one site using Facebook for Drupal (/project/fb) and creating accounts from Facebook is working acceptably in testing. It isn't perfect, and the site frequently has timeout errors when trying to contact Facebook.
I will follow along here, and help out if I can.
Where I work, we have
Where I work, we have multiple sites in multiple servers and we need to connect all this network of sites with a shared user database. I've been working in our own distribution to solve this mess, it is really simple, nothing really fancy.
This is a distribution that does not go very far in features, it just do logins with a nice UI and has a single page to administer all users from a central location. I haven't tested it as much as I need, and there are some things I still need to work out, specially theme related but is kind of working right now.
I must say that this distribution has nothing to do with Omniauth, another distribution, although it uses the some of the same modules, it is way more simpler and adds a couple of extra features that we needed, first, it works with core profiles, not with content profiles and it starts with just a very common set of profiles fields; second, I'm also adding a module of my own, which is PUX that is kind of an experiment that allows you to easily theme the profile page using contexts and blocks and also separates the 'edit account' into a different whole section named 'user settings'.
I must mention that the main reason for not using Omniauth was because I didn't have control of the code and I needed to modify it a lot for our own purposes. We're currently in the process of creating several more networks of sites with their own users base, so this distribution will allows us to save time in the feature.
Also, this dist uses a theme that is based on two base themes that I use and they are not on D.o. Since I've been working with my own base themes for a while now, and they are built for maximum flexibility and not with easy-to-use in mind, I prefer to use them over other solutions.
As I said, this is a work in progress and it has been built to suit our needs but I wouldn't mind to open source it.
For the relying sites, I'm not working in a distribution, I rather have a make file that has all the modules you need to connect an existing site to the provider site and if you have existing users in that site, there is even a module that can do the migration for you to the OpenID approach, I just need to document this better.
If you're interested, I'll be glad to give you more info.
Luis
OAuth as alternative / compliment
see these comments from voxpelli the author of some of the key OAuth work
http://groups.drupal.org/node/140874#comment-544684
http://groups.drupal.org/node/140874#comment-544689
Passing on Group Membership back to Hub?
So, I've gotten the OpenID Single Sign On stuff working between a Hub Site at several OpenAtrium subsites. What I'd like to do is try to push / link all of a user's memberships in the subsites to their hub profile. Any thoughts on the best way to do this?
The hope is to provide a block with the user memberships on every networked site they are on.
Your help would be terrific
Hi Mark,
I appreciate your offering to help on my projects related to referendum.com. I have eight D6 sites needing SSO, and I would like help, but also I am sure others would appreciate your recipe here. As far as I can tell, you knowledge would be the most recent. Please let me know if you have a bit of time.
Thanks, Jerry
Scattered Info, Code Probably needs Updating...
@js: the info out there is a bit scattered but while the code for SSO probably needs updating and greater participation, the code does indeed work and is quite mature. It actually isn't terribly hard the single sign on (SSO) stuff to setup but extending and twisting it to other purposes is (in my opinoin) probably not recommended. I successfully got user profile pictures to sync, but had lots of trouble with syncing group memberships trying various approaches.
My one recommendation is that your provider site should be relatively simple and focus mostly on the sign on / profile stuff. You can indeed use basically any site but being that the provider holds the whole setup together, best keep it simpler so problems are more apparent.
Send me a private message if you need some more assistance. I'll probably be doing another SSO setup for a client in the next week or two, so I should be relatively fresh with the code/technique.
Getting endless loops
I'm trying to implement the openid_sso_relying module and have tested w/ several public OpenID providers, Google, Yahoo, etc and I keep getting caught in an endless loop. (http://www.example.com/openid/authenticate?destination=home has resulted in too many redirects) (right now using https://me.yahoo.com/ as the provider)
Is there something that I am just missing?
This seems like it should be straight forward, enter the provider url, login to the provider site and then my site checks for a valid login w/ the provider, but that doesn't seem to be occurring.
Anything I should look for to troubleshoot?
Thanks,
Jerry
bakery ?
it seems like Oauth and Bakery are where all the SSO energy is
its seems like a hybrid approach is becoming standard in the wider-world, its weird Drupal would focus on a internal to Drupal only solution
the big identity integrators use OAuth + OpenID hybrids
Acquia & Jainrain
and our overlords have done a deal for Drupal Gardens Enterprise
http://janrain.com/about/newsroom/press-releases/janrain-partners-with-a...
Seems like my error had to do
Seems like my error had to do with the endpoint url. "www.myopenid.com/" seems to work. Now to replicate these results w/ own provider. :)