Posted by markwk on April 8, 2011 at 6:32pm
I have several sites and potentially more to come (Drupal 6, 7 and possible a mediawiki site) that I would like to share logins and users and cookies. Basically a single sign-on system. Any thoughts / modules / config on best way to have a single sign on?
Comments
CAS may work well for you
It depends on the scale, but CAS might be a good solution. As is LDAP.
Bakery?
For the time being CAS or LDAP might be a bit of an overkill. I was looking at this project that might work fine too: http://drupal.org/project/bakery
Following down this path
CAS, LDAP, WebAuth and more seem like potential good solutions. The original question involved Drupal sites + MediaWiki. While most of the sites I have are running Drupal, I also need a more "generic" solution. I am designing something right now which will include multiple Drupal sites, some photo gallery system (most likely in PHP) and a Django application.
To me, it seems logical to pick some decent generic authentication system and then write modules for each application/system which can use it instead of their default authentication. It seems that here we head down the "best Drupal approach", Django sites offer the best Django solution and so on. If you go to shared hosting provider forums you tend to find what is best for them (which usually discourages or disallows long running processes such is required for an LDAP server.
Well if you think CAS or LDAP
Well if you think CAS or LDAP is overkill, then you might not like my suggestion, which is to use Shibboleth. More info at http://drupal.org/project/shib_auth
Drupal evangelist.
www.CoderintheRye.com
used SSO before
used SSO before with success tho there'd need to be something written to get it to play nice with non-drupal sites so that's probably out :p http://drupal.org/project/sso
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Since we (unt.edu) already
Since we (unt.edu) already had an LDAP/AD infrastructure, we used the ldap_integration module on 500+ sites with good success. We deploy fresh sites with the settings in place, and users almost never have to adjust them.
Bakery looks cool and has good sponsor and maintainer support, D7 upgrade path, etc.
Without sharing tables...
I use Aegir, which doesn't support any kind of shared databases, tables or tables prefixes.
SSO looks like it hasn't been used much or updated lately.
After some searching, I'm still not quite sure I follow what Shibboleth does / is for as well as the hardware/software requirements to make it happen.
I currently don't have enough users to make it worth the effort I think to move towards a LDAP.
I'll probably make an attempt with bakery first, which doesn't share tables but instead creates and syncs users accounts
between the master and slave sites.
Dev Seed Solution:
http://developmentseed.org/blog/2010/mar/02/simple-sign-openid ...Interesting...
Shib and open ID
Shibboleth is for federated identity - its used a lot in Higher Ed - and may be too complicated for most folks to set up.
OpenID is easier at some level, but I've heard about some issues - which led 37signals to drop it from Basecamp. Might still be useful if you can get the users to buy in.
E
Eric Aitala - ema13@psu.edu - f1m@f1m.com - @aitala
www.essp.psu.edu - www.f1m.com
Not much OpenID in China
Unfortunately, the majority of my users are Chinese students and equally unfortunate (as far as I know )is the fact that OpenID is not very well know/used in China.
Aegir support for Bakery (or Bakery support for Aegir)
http://drupal.org/node/1151020
http://community.aegirproject.org/discuss/single-signon-or-aegir-support...
I've been trying to get the Bakery module to work with Aegir and having some troubles
would be interested if anyone has managed to get Bakery working in Aegir and if so, what configurations of site
No luck either
I tried a month ago. No luck either in fact. Love hear about any progress.
I'm actually moving towards trying to to implement the OSSO stuff from Dev Seed.
OSSO provider failed for me on Aegir
I tried that approach too, but got errors with the OSSO Provider site install, was using the OSSO installation profiles, and the idea of basing my security system on unsupported code doesnt do much for my confidence. I am also not keen on spending all my time working out how to maintain it...
what would truley be awesome is to fork that OSSO code and make it contrib on d.o
https://github.com/lxbarth/osso
https://github.com/search?q=osso&type=Everything&repo=&langOverride=&sta...
http://drupal.org/user/53995
I am going to have a look at Shibboleth too
in Wordpress 3.0.x there is the concept of site "networks", also the BuddyPress extenstions which give a social aspect to the network
what a concept !
i.e
http://permaculture.tv/
http://blogs.permaculture.coop/
Here's my 2 cents. That's
Here's my 2 cents.
That's just an experimental package of a fully working system.
If you checkout the pieces themselves, especially http://drupal.org/project/push_hub and http://drupal.org/project/openid_provider you'll see that there are several folks still involved in this stuff. I wouldn't exactly call it unsupported, especially when you consider it as a situation related heavily to how you use Feeds, which is heavily supported and maintained.
I'd look at as a situation that doesn't generalize well for "most folks." WordPress has an advantage in the fact that it is only serving blogging content.
encouraged, will try again
ok, that's useful, will look at it again..
still think it would be good to work-out a way to contrib this code to d.o...
maybe contact dev seed and ask ? I know dev seed are stepping back from drupal for node.js... but they still have some of the greatest experts in the field
StatusNet etc
you are correct that the maintainer of the OpenID_Provider module is a serious player and its very interesting that he is involved in Status Net which is at least partly built on Drupal
will investigate this further...
cheers
-N
the OSSO stuff works with OpenAtrium and D6
have to test it more thoroughly, but creating an OpenAtrium OpenID provider and a D6 relayer works fine.
will test OA provider with these relayers; Drupal Commons, Managing News, Open Scholar, Open Publish, Open Outreach etc
then will make a test provider that is stock D6 then maybe Drupal Commons
not sure if I want OA my "hub" nor DC .. maybe just a stock D6 site
also see a D7 port is in the works..
thanks for the guidance
osso modules as contrib
devseed's lxbarth is ok with the concept of making these modules contrib and upgrading to D7
https://github.com/developmentseed/osso_relying/issues/1
also, tested with Drupal Commons as relying and get stuck in a loop
osso modules as contrib
ok, got permission from lxbarth and will work towards forking and contributing osso to d.o
http://drupal.org/node/1152948
wanna help ?
OmniAuth OpenID Single Signon - OpenID - Single Signon Lives
there is a major update of this work, help needed...
http://groups.drupal.org/node/154879
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
it just works
I got single signon working using these two modules from Development Seed
OpenID Provider SSO module
https://github.com/permaculturecoop/openid_provider_sso
OpenID Single Signon module
https://github.com/permaculturecoop/openid_sso
I spent weeks roaming around various approaches like Bakery, Janrain and explored a lot of the other Dev Seed OSSO stuff.
Turns-out the names of the OSSO modules, features, profiles etc are confusing, there are even two very similar OpenID SSO modules, one has fewer features and works slightly differently to the one above
I haven't tried using the Push_User and Node_Sync modules that run with these but I am having success with;
D6 OpenID SSO Provider and two stock D6 *2 relying and all the best distros, all running OpenID SSO; OpenScholar, UberDrupal, OpenAtrium, DrupalCommons, COD, NodeStream
I guess we (I should push that onto the OpenID group, issue queues and generally let people know its actually rather simple, when you know how !
i wonder what other gems are unpublished by Dev Seed and others...
some gotchas and to do's
relying party i.e. website doing SSO to Provider user registration email verification needs to be off, and users roles need to be set... need to more fully test Push and Sync custom modules that sit in the Osso profile
anyway. it works, single, shared signon, has for over a year, and generally useful, but not really publicly well-known
pretty crazy
The two modules you have
The two modules you have forked on github are the same modules you asked me to publish on drupal.org. The only thing I did was renaming openid_sso to openid_relying_sso, so that it'd be easier to understand.
I'd prefer patches for these modules than forking it in different git services around the planet. Thanks.
Killer.... Will Test Soon.
Killer.... Will Test Soon. Love to See a Nice Point-By-Point Write on Implementation...
I'm assuming you're using Aegir?
Aegir..
yes, Aegir ..
install those two modules in sites/all/modules/custom (also download and install dependencies like OpenID Provider)
DO NOT install other OSSO modules ! from OmniAuth, the OSSO installation profile or the OA as OpenID Provider make file
will have to double check this sequence, am too tired at this moment to remember clearly...
I think you need to set-up provider first, but then the relying which point to provider, and then add relying at provider
i.e. these steps might be a bit off, see bold above....
set-up relying sites .i.e. consumer or sites that will do the signing-on first
relying
0. install Dev Seed OpenID SSO module and dependencies
1. User Registration, registration open, no email verification required
2. User > OPenID registration add provider name and URL
go to provider site
0. install Dev Seed OpenID OpenID Provider SSO and dependencies
1. User Registration, registration open, no email verification required
2. OpenID SSO add relying parties, name and URL
I will write a nice and tidy blog post for this later in the week, maybe mid week
all of these where D 6.2, except for UberDrupal D6.19, no D7.x or D6.22
cheers
-N
Tested as working between two
Tested as working between two Drupal 6.22 sites. Killer...
Great, this is actually
Great, this is actually working. Two thoughts.
Luis
Luis
yes, devil in the detail
yes, it really does
now that SSO actually works, it opens up all sorts of admin and config issues, a cascade of details
thought about doing setting-up a project on d.o, but I don't yet know how, also I couldn't support it, am learning PHP again after about 10 years :<. would do it if had to, or co-maintain or whatever.. this should be on d.o
I made different admin passwords on each, prior to installing modules. you have to get a bit systematic about working with SSO, or else you find your are logged in to one site and it clashes with actions on another, especially with admin. I am running Firefox and Chrome, will get Opera going too !
a big issue will be syncing users and content profiles
I noticed Open Atrium handles the OSSO modules well and allows you to edit your profile on the relying, Drupal Commons doesnt deal and redirects to the provider. Makes sense OA was Dev Seed too
I just sent an email to
I just sent an email to Nicholas (permaculturecoop). I know those projects are a fork but maybe he could take on the project and the community do the rest as usual :)
Can you elaborate a little further on the admin problems? Did you solve the problem by only setting different passwords? My problem is that I can't login on the client site but yes, both passwords are the same.
Luis
I think I just solved the
I think I just solved the "admin login" problem on the client sites.
I'll be using two users:
1. admin (this is the uid=1 that I used to create the site)
2. root (this is the uid=2, don't let the name confuse you, there's nothing special about this user until step 10).
Steps to reproduce
1. Enable and configure OpenID SSO (provider and client) modules on both sites, server and clients.
2. Create a user on the server site
3. Login with that user on the client sites so the user is created on the client sites.
4. Logout
5. On the client site, disable openid_sso, you'll need to do this with drush
6. Login in the client site with the admin (uid1) user.
7. Go to the users administration page and check if the user root was created.
8. Create a new role or install the administrator role module.
9. Give all or at least sufficient permissions to that role.
10. Assign the user root to the role you just created.
11. Enable the openid_sso module
12. Logout
Now, if you login as root, the root user will have admin permissions on the client site making the admin (uid1) user almost useless but still you'll have all permissions to do whatever you want.
Luis
Nicholas (permaculturecoop)
Nicholas (permaculturecoop) is me, sorry about the confusion
the original code "owner" alex barth already gave the ok
https://github.com/developmentseed/osso_relying/issues/1
http://drupal.org/node/1152948#comment-4449858
do you wanna start the project ? i will co-maintain
I could do it - once I work out how - but its probably kind of presumptious
OK, I must be stupid or
OK, I must be stupid or something. This is actually easier than I thought, just go to http://client.example.com/login/direct and you can login as the admin user.
Luis
This is kind of confusing.
This is kind of confusing. @xamanu has created a fork of two of this modules from DevSeed and started a sandbox project at D.o That is good but I see a few problems now:
I tried both modules and the solution didn't work for me, maybe it is because I used openid_relying_sso and not openid_sso. Once I used openid_sso instead of openid_relying_sso it all worked as I mentioned before. I don't know if he forked the wrong projects or if there's something I'm doing wrong and openid_relying_sso does actually work. Personally, I don't know what are the differences between openid_relying_sso and openid_sso.
Both sandboxes are not being developed. Both have only one commit, the first one.
There's also some other guys who are working on a possible solution for this and they also forked the DevSeed modules. They are working on a distribution at https://gitorious.org/omniauth and possibly they know the modules better than anyone.
All of this gives us a less than ideal scenario: too many people working on too many forks of the same project and doing it in 3 different sites (Github, Gitorious and Drupal).
I'm already a maintainer and I have permissions to create full projects, so that would not be a problem for me. But I don't know this project and I would have to invest some time to know them better, in the meantime, I would love to read from the guys who created omniauth, probably they are the ones who should be leading this.
Luis
According to
According to http://drupal.org/user/359937 he renamed openid_sso to openid_relying_sso when he cloned the projects. Now I don't know what's the difference between DevSeed's openid_relying and xamanu's openid_relying_sso
Luis
confusing
also Dev Seed seem to have named two modules that look very similar
https://github.com/permaculturecoop/osso_relying - has about 130 lines of code
https://github.com/permaculturecoop/openid_sso - has 250+ lines of code
I couldn't get the Omniauth to work - at least like the javascript button login approach of https://github.com/permaculturecoop/openid_sso
yes, and there is another fork on github which is in between
https://github.com/guillaumev/drupal_modules/tree/master/openid_sso
part of the problem for me, and probably most people, was getting totally confused by the similar names and overlapping and conflicting module set-ups
thats why, I thought was pleasantly suprised it basically works if you simply use these two modules
https://github.com/permaculturecoop/openid_sso
https://github.com/permaculturecoop/openid_provider_sso
Omniauth is an very interesting architecture by xamanu who has the sandboxed modules, but its too complex for me, doesn't use the Javascript button, and didn't seem to work, or at least I couldnt get it to... I sent issues and emails and am waiting
so when these two worked, with a simple D6 provider and smoothy logged in all those distro's, I thought, fine, thats enough pain for me on this issue
omniauth is xamanu
the gitorious omniauth project is xamanu
see the Omniauth makes http://groups.drupal.org/node/154879
Move to D.O.
I agree move to d.o.
I don't have the status :( to do this, but could someone should cross-post to this group: http://groups.drupal.org/federated-social-web, since this looks like the group where this work is most relevant.
Single Signon g.d.o pending
I applied to create a Single Signon group.. I was told it seemed to duplicate the OpenID group
waddya reckon Luis?
d.o/project/openid_simplesignon ?
contains two modules? openid_simplesignon and openid_simpleprovider ?
I think its important to make it clearly distinct
1. its simple, no bells and whistles which a "single signon" might imply
AND
2. its a working and distinct package from all the other stuff
Keep as two modules with two
Keep as two modules with two projects. More flexible for later modifications / extensions / etc. Just add some helpful notifications within each that they require the other, etc.
the sandboxed osso provider
the sandboxed osso provider and relying modules are similar, but different to the github files (especially the relying sso module with 30% different codebase, the provider sso has only a few percent difference)
compare omniauth xamanu's dev seed clone which doesnt quite work?
http://drupal.org/sandbox/xamanu/1153576
http://drupal.org/sandbox/xamanu/1153574
to
openid_sso my direct dev seed clone, which does seem to work
https://github.com/permaculturecoop/openid_provider_sso
https://github.com/permaculturecoop/openid_sso
I tried to contact xamanu, and after some intial emails all is quiet, not sure, work, travel, projects?
openid-sso is distinct enough to be its own project
I like diferentiating it to openid_simplesignon
A few thoughts: I could
A few thoughts:
If anyone wants to join and be co-maintainers, it would be good idea to post your username here. In the meantime, I guess I'll be reading a lot of code this week :)
Luis
we have; as Drupal.org
we have;
as Drupal.org contrib projects
-OpenID (D6, D7)
-OpenID Provider (D6)
and then a couple of only very slightly different versions of SERVER OpenID Single Signon Providers modules (which work with the above two modules on the "server" or "provider" or "hub" site)
we also have two substantially different versions of OpenID Single Signon Relying modules which work with "clients", "consumers" sites
-the two flavors or sub-types of the CLIENT work differently, the one that does work, has 30+% more code and uses a Javascript button to send a client to the provider. The other flavor has less code, uses regular login dialog form and doesn't seem to work
hopefully xamanu (who sandboxed two of these modules will help us out)
I think we need a wiki page for this
one issue I have with openid_server and openid_client is that it implies a general solution. OpenID is a complex spec, and is co-evolving with OAuth now.
I guess it does make sense to create a project that could expand into the niche (its needed!)
I could help-out on issue queues, testing, documentation etc
I couldn't find any OpenID
I couldn't find any OpenID groups! As suggested by @markwd I posted a discussion at the Federated Social Web (http://groups.drupal.org/node/155674) I also tweeted about this in case anyone wants to jump in and help.
Luis
OpenID Group
it gets a bit confusing all these projects, groups, users etc, the social plumbing needs some work
http://groups.drupal.org/openid
How about D7?
I saw that the modules are for Drupal 6, is there something for D7 as well?
I'm trying the OpenID module integrated in the core but it doesn't seem to work much. It doesn't even recognize gmail as openid. Any idea?
No @SilviaT there's no
No @SilviaT there's no solution for D7, not that I know. As I said, we could actually start working on a D6 Server and a D6 and D7 clients.
Luis
there is a request for a D7
there is a request for a D7 OpenID Provider, although even Drupal Gardens uses D6 version of OpenID Provider, while the sites run D7
presumably there is some unreleased code that facilitates the simplified, single signon at Drupal Gardens
Gábor Hojtsy
http://drupal.org/node/983128#comment-4601040
I think we should start with
I think we should start with this route:
@niccolo I've been reading the emails with the guys of Omniauth, a simple explanation from them about the differences between the modules would be great. Also, Omniauth doesn't seem to work (at least it didn't for me).
Luis
great minds
I think you mean
1.1. D6 OpenID Provider
1.2. D6 OpenID Server (formerly OpenID Provider SSO https://github.com/permaculturecoop/openid_provider_sso or http://drupal.org/sandbox/xamanu/1153574 )
1.3. D6 OpenID Client Simple (Javascript-button version, formerly OpenID SSO openid_sso https://github.com/permaculturecoop/openid_sso )
1.4 D6 OpenID Client Form ( formerly openid_relying_sso http://drupal.org/sandbox/xamanu/1153576 )
lets see what Felix (xamanu) says !!
Wow, my head is just about to
Wow, my head is just about to explode :)
This is the list that is causing all the confusing. I don't know the differences:
I really hope @xamanu could explain.
Luis
I think it was this list that
I think it was this list that caused initially me, then niccolo to lose the thread...
This is @xamanu's explanation
This is @xamanu's explanation about the list:
Using the list:
Hope this help at least a little
Luis
Sorry, my fault:
I'd recommend that you leave Dev Seeds old repositories. I needed quite a lot of time to get through it and I think I organized it in a way that it is way more understandable. Don't make thing more complicated as they are right now. Please have a look at the module overview table below.
You can just see the state of
You can just see the state of development of Omniauth with the screencast at vimeo: http://vimeo.com/25103388
I explain some modules there as well.
I would not recommend to use Development Seeds sources without knowing what you are doing. Their code is one year old and does less than Omniauth and is less structured. Please watch the screencast and you'll see that Omniauth is working quite good. Of course there is a lot of room for improvement but I'd prefer to keep them in the issue queues of the modules (openid_provder, openid_profile, openid_provider_ax, openid_relying_ax and the two modules in my sandbox openid_provider_sso (http://drupal.org/sandbox/xamanu/1153574) and openid_relying_sso (http://drupal.org/sandbox/xamanu/1153576).
Regards. Felix
Module overview
Since there exist a lot of doubts and a little jungle. I'm posting a little matrix that should explain all use of modules and why I renamed some of them, so that there is a little bit more consistency.
I hope I could clarify some doubts.
I am super happy you've been
I am super happy you've been working on this, I didn't really want to have to use orphaned code.
have you tested using these modules to create a site network with commons distros: Drupal Commons, OpenAtrium, UberDrupal etc? the Dev Seed openid_sso works well with OpenAtrium and I've used it to link OpenAtrium, Drupal Commons, UberDrupal, OpenScholar, Conference Organizing Distribution (COD) and Nodestream
could you edit the above list to state Modules, Features, Profiles ? you might want to also include the makes?
but, other than some quibbles I am super happy this works
what will it take to get these modules fully published on d.o ?
I just update the table in
I just update the table in the other post related to this but inside of the OpenID group: http://groups.drupal.org/node/154879#comment-521049
To get this modules fully published as modules to d.o we would need a lot of improvement in several things inside the code, a Drupal 7 port, and a real base of contributers - in any sense - to get this to a level to be really worth to publish and warranting sustainability
That sounds like a
That sounds like a responsible position.
For the time being, you are proposing to keep these in your sandbox?
Can the issue queue be kept there as well?
-A good starting point to moving this a full project is clarifying the current issues so everyone knows what's up and issues can be tackled when developers got time and post patches.
Any plans to move the OmniAuth stuff to D.O?
-One problem is that there really isn't a turn key / install profile setup on d.o. where we can judge if all the pieces are working together and report accordingly on the "whole" issue.
Muchos gracias xamanu...
Hello Markwk, yes that issues
Hello Markwk,
yes that issues can be kept there as well. I would like to see some more contributers (at least patches) for this modules to get them pushed to real d.o projects. It is a solution that is working for us now. But I don't see right now how we can push this to a worthy level without help of the community or clients who want to finance it.
Omniauth is even less generic yet (see niccolos tries with Aegir - http://drupal.org/node/1188886). When it is ready we could talk about that. I haven't really thought about if d.o would be the best place. For the modules of course it is, but distributions (like OpenAtrium, OpenPublish) are not necessarily hosted on d.o
We'll see how things go.
First priority is to get the SSO modules (in the sandbox, right now) working smoothly. Because Omniauth is at the end just configuration on top.
Saludos.
AWESOME, but change the broken login !
ok, looks awesome, thank god !
please remove the broken login from the relying/client profile... that made me think the whole thing was flawed ...
I would suggest you change the login box on the frontpage of the relying profile, change it to the "Login using ProviderNAME as your OpenID provider. "
as in the OpenID SSO module from Dev Seed implementation https://github.com/permaculturecoop/openid_sso/blob/master/openid_sso.mo... from line 82
/*** Implementation of hook_form_alter().
*/
function openid_sso_form_alter(&$form, $form_state, $form_id) {
switch ($form_id) {
// Redirect user to front page after login, otherwise she will be pushed to
// OP when using the login/direct form.
case 'user_login':
$form['#redirect'] = '';
break;
// Don't allow the user to login using the login block. Direct her to OP
// instead.
case 'user_login_block':
// Show a modal message when user clicks on log in (there may be a wait).
$path = drupal_get_path('module', 'openid_sso');
drupal_add_js(array('openid_sso_wait_message' => t('Please wait...')), 'setting');
drupal_add_css("$path/openid_sso.css");
drupal_add_js("$path/jquery.blockUI.js");
drupal_add_js("$path/openid_sso.js");
// Remove all child elements.
foreach (element_children($form) as $key) {
unset($form[$key]);
}
$form['#action'] = url('user');
$form['#validate'] = array();
if ($provider = variable_get('openid_sso_provider', array())) {
$form['message'] = array(
'#type' => 'item',
'#value' => t('Login using @provider_name as your OpenID provider.', array('@provider_name' => $provider['name'])),
);
$form['submit'] = array(
'#type' => 'submit',
'#value' => t('Login'),
'#submit' => array('openid_sso_user_login_submit'),
'#attributes' => array('class' => 'login-submit'),
);
}
break;
}
}
I filed an issue about that:
I filed an issue about that: http://drupal.org/node/1189620
Thanks for reporting. Patches are very welcome ;-)
Got you! This is a pretty
Got you! This is a pretty small thing. We usually just set a link to the
/userwithin the menu. I can easily implement this. No problem.Why do I always find these
Why do I always find these things so late? Sorry guys for not finding this earlier.
I would suggest using the same system that you use to log into eg. Twitter. It's very easy to expose such an API in Drupal - you just install the OAuth Login Provider and you're all set: http://drupal.org/project/oauthloginprovider
You then use a simple OAuth client on all sites you want to be able to log in through the central site. I'm currently building such a module that supports any kind of OAuth API: http://drupal.org/project/oauthconnector For those wanting a less complicated solution one can use the OAuth module (http://drupal.org/project/oauth) directly or just use any OAuth library one can find out there.
Here's an old screencast of how the OAuth Connector works: http://vimeo.com/14334118
Drupal to Drupal OAuth example exports?
just had a chance to watch your tantalizing video, very nice, but how to set-up a Drupal-Drupal OAuth single-sign-on approach ?
are you able to provide example features? or the demo code ? or, shudder, documentation?
thanks for the input
Here's a short guide written
Here's a short guide written from my memory:
is it possible? see a), b) and c)
I seem to be close to getting this working, but something isn't quite right
few points, see a), b) and c) below;
a) in 3 above, do I create a consumer that authorizes all others? i.e. do I create one user consumer that allows Site A and Site B to talk and trust each other? or do I need to create a trusted connection for each user? if so, how is that single-sign-on?
b) am getting some permissions error when not admin 1
access denied 07/19/2011 - 00:09 user/register oauthaccess denied 07/19/2011 - 00:09 oauth/authorize oauth
user 07/19/2011 - 00:09 Session opened for oauth. oauth
user 07/19/2011 - 00:08 Session closed for oauth. oauth
and
access deniedDate Tuesday, July 19, 2011 - 00:09
User oauth
Location http://oauthp/oauth/authorize?oauth_token=bY6XECGFDXATM8us8KKmtnYUweMdnD46
Referrer http://oauthp/user/login?destination=%2Foauth%2Fauthorize%3Foauth_token%...
Message oauth/authorize
Severity warning
c) but need to check, is this use-case possible
so, OpenID?
hi voxpelli,
I haven't checked the oauth approach - I will - but does this mean that the oauth solution is more elegant than the OpenID approach ?
http://groups.drupal.org/node/155799
http://groups.drupal.org/node/154879
I actually requested a new g.d.o group called Single Signon but was refused and told that OpenID was active and maybe should be renamed
could we shift the conversation to the Federated Social Web group ? what is the place for single signons; OAuth, OpenID etc etc
I am a bit confused by the fact that Drupal Gardens has an OpenID signle signon, d.o does not and that OpenID is languishing in core
one of the advantages of OAuth is that its active contrib, keep it out of core as long as possible imho
I don't think single signon
I don't think single signon is a topic for the federated social web group. Single signon is an issue beyond the social web.
As far as I see it OpenID doesn't deal with arbitrary API access. It has been extended to share some specific data and it can be hacked/extended to support more. OAuth however was built as a solution for authorizing API:s without relying on usernames and passwords (as that was impossible for OpenID users). So OAuth was born out of the need for OpenID users to authorize API access.
So - yes - I would say that in most situations I've gotten the impression that OAuth would be a better solution than a semi-hacked/extended OpenID.
Add to that that the next version of OpenID (OpenID Connect) also seems to be based on OAuth - so if even OpenID feels that OAuth would be better than the current OpenID then surely it's no crazy idea at least :)
OpenID and OAuth are pretty different
OpenID and OAuth are pretty different in their behavior and, yes, OpenID doesn't provide arbitrary API access. Nevertheless it can exchange attributes and this is not hacking since it is standard of the protocol. This is a very limited functionality and OAuth can provide a lot more of real functional exchange between provider and relying party sites, but it can be confusing (under certain circumstances) for users of your sites. On the other side, IMHO, OpenID is just nicer to use for a Single Sign On solution, since it could give you a better perception as an integrated service because of less necessary steps for the user to get authenticated on the relying parties.
At the end, like in almost all cases, it depends on the requirements of the project, which could be the better solution for this purpose. Both are completely valuable. And I hope that both are getting a lot of love to provide better authentication methods for the web and drupal.
ok, if my limited tests of
ok, if my limited tests of Oauth (not sure I have it completely working) and more extensive tests of the OpenID single-signon solution are correct, then for my use-case of a simplified, single-signon, the OpenID is more appropriate ?
as above, it seems that the Oauth requires each user to create a provider account and then manually link that to their account on the consumer site? the Omniauth/OpenID approach allows a relatively simplified single-signon, where once the admin connects to sites (provider-consumer) any new users will then be able to login to the others by just logging into the provider..
am I missing something about OAuth? I was hoping as an admin I could create a provider-consumer trust between two sites which would be seemless to any user on those sites... but it seems with Oauth there are extra steps of Oauth setup, keys, apps, etc that you dont need for OpenID
I'd be interested to understand how they might compliment each other, xamanu's Omniauth and the Oauth suite of modules
if the next version of OpenID is hybridizing with OAuth doesn't make sense for Drupal to lead in this?
I could be wrong about this
I could be wrong about this one but I think OAuth is great to authenticate apps, that's why authenticating users requires more steps for the user. OpenID is easier.
Luis
thats the impression I got
thats the impression I got too... it would be great to see an install profile - Omniauth ? - which folds OpenID AX + OAuth together, so you can create single-signon for users, and integration with apps
I'll do some more testing with OAuth and Services but my priority is the simplified, single signon
btw, will you release your version of the install profile ?
Yeah, well it's here
Yeah, well it's here https://github.com/lelizondo/openprofiles for anyone who wants to give it a try.
Luis
wow, nice one
great work luis !
within Aegir 1.x created a new platform with OpenProfiles and created a site from that, configured that site as a provider. Next I created a D6 client/relying using xamanu's openid_sso_relying (and required modules), installed Profile and mapped the AX.
couple of questions
did you base your theme on Omega ? why fork?
do you have a preferred client/relying set-up?
how is the username created? from the email address? is there a way to turn that off?
will try the Facebook, LinkedIn, Twitter next
-N
No, Omega was one of the base
No, Omega was one of the base themes I've been trying, I know why you're asking, there is a theme screenshot I never replaced. But no, Omega was a test but it had nothing to do with the final base theme I've been using.
There is a make file that will download everything you need for an existing site that you want to connect. Nothing really special, probably the only thing is that the make file will apply this patch http://drupal.org/files/issues/1218198.patch to the openid_sso_relying module and also download a module that will help you with the migration.
The username is created by everything that comes before "@". If you want to read more about this, you can go to http://drupal.org/project/email_registration. If you want to disable this, just disable the module, but, I must say that if you're been using this and then disable the module, you could end up with users not knowing their username. If your site is new, you shouldn't have any problems.
One more thing, if you have any comments or questions about OpenProfiles please post them at https://github.com/lelizondo/openprofiles/issues or create a new post and just invite me. Let's try to keep this post clean.
Luis
Killer...
Luis--
I'm finally getting to the single sign on and authentification stuff and it's nice to see the work you've done here. I'll need to do some more digging on what is going on here, but I think you are on the right track with providing potentially an easier integration with various logins as a "hub" to other drupal sites.
I'll have to see what will need to be changed since my relaying sites use content_profile.
Thanks for the this great contribution.
Basic Question
Hello Everyone,
My apologies if this is covered in this thread and I've missed it.
My question:
How are groups.drupal.org and drupal.org connected?
Looking at my own account:
- Different ID#s
- When I logged into groups.drupal.org and then went to drupal.org my login had persisted.
- On Drupal.org, there is a tab/link to My Groups on groups.drupal.org
How is the login (what module or approach) persisting?
Is the tab http://groups.drupal.org/groups/my solely going to the generic logged in link for my profile? Or is there a connection that carries over that I have Groups membership?
Is there a way to put the Groups membership user form (from groups.drupal.org) on to an edit or sign-up form on drupal.org?
I ask because I want to replicate that behaviour on a site I am working on.
All the best,
Mike
Work - https://www.shawndewolfe.com/
Education - https://cinchacademy.com/
Etc. - https://shawn.dewolfe.ca
My First Drupal site - http://www.comminit.com
D.o is using
D.o is using http://drupal.org/project/bakery for the SSO solution.
The problem with bakery is that it was a solution developed for D.o so it will not have any fancy features, an example of one of the things that will never work with Bakery is Aegir.
Luis
Thanks!
Thanks, Luis,
I thought there was something that was making Bakery non-fit-for-general use. What you've said about fancy features and Aegir fits with that.
All the best,
Mike
Work - https://www.shawndewolfe.com/
Education - https://cinchacademy.com/
Etc. - https://shawn.dewolfe.ca
My First Drupal site - http://www.comminit.com
So what is the current status?
I've been reading, like to know where this project is.
Is there any updated documentation?
Any rough documentation?
If it really works, and someone provides even some rough info as to current status and how to implement, I'll be happy to update documentation to make it more clear, including screen shots.