[ckan-dev] integrating login between ckan and drupal

[David Read]

Thanks for the heads up on that Toby. We'll certainly track this to
see if this offers advantages, although I wonder if it might be better
to get Drupal going as a SAML Authenticator itself, instead of this
custom route.

David

On 26 March 2013 14:53, Toby Dacre <toby.okfn at gmail.com> wrote:
> On 26 March 2013 14:34, David Read <david.read at hackneyworkshop.com> wrote:
>> (cc'ing ckan-dev as others may be interested)
>>
>> At data.gov.uk, users can log in and the account is used across both
>> Drupal and CKAN. We tried to have as few integration points between
>> Drupal and CKAN as possible because it really adds to the complexity,
>> but this was a key one to allow both the public and our hundreds of
>> publisher users to interact seamlessly. I wrote more about this
>> general Drupal/CKAN integration approach here:
>> http://data.gov.uk/blog/integrating-ckan-and-drupal
>>
>> The design works nicely with CKAN 1.7.1 and Drupal 6, and I expect it
>> to work fine with CKAN 2 and Drupal 7, but haven't tested it. It was
>> not possible to do this functionality as a repoze.who plugin, and it
>> man-handles repoze somewhat to get the desired outcome.
>>
>> Essentially, a user logs into Drupal as normal. Then when the user
>> clicks on a CKAN page, a new piece of middleware sees the Drupal
>> cookie in the request, and if it is valid then it tells CKAN's
>> auth_tkt to log the user in (creating a CKAN cookie). CKAN needs its
>> own User object, so if it doesn't exist then one is created. The
>> user's name, email address and roles (permissions) are copied from the
>> Drupal world to the CKAN User object. By setting the REMOTE_USER
>> variable, the request continues, now logged in. Subsequent requests
>> will be logged in by auth_tkt.
>
> David,
>
> Just to say that as part of the work I've been doing we will be
> introducing an IAuthenticator Extension point that could also be used
> here.
>
> It essentially adds a few methods
>
> identify_user() called in lib/base to identify the user
> login() called during the login
> logout() called during logout
> abort() called when 401 pages get called
>
> this could well work for this too.  It is currently experimental and
> being used in saml2 authentication for one of our clients.  It may
> well be in 2.1 but will not be in 2.0
>
>
>>
>> When checking the Drupal cookie, it checks it is for the correct
>> hostname and then makes a call to a Drupal XMLRPC API (that was put
>> together by our Drupal team and I don't know anything more) with the
>> session ID: get_user_id_from_session_id(). From the Drupal "user ID"
>> (node ID) we then ask Drupal get_user_properties() to get name, roles
>> etc.
>>
>> Logging out of Drupal causes the cookie checking to fail and it logs
>> out out of CKAN too.
>>
>> There are a few caveats to the system as it stands:
>> a) when roles are given to a user in the Drupal world, the CKAN user
>> needs to relogin to receive them. We only use it for sysadmin role
>> (others are pure-CKAN roles), so that is not really an issue for us.
>> b) https is not covered yet, but shouldn't be difficult
>> c) CKAN doesn't create the user object until that user clicks on an
>> CKAN page. This may not happen before an admin tries to give them CKAN
>> permissions, which causes problems. Currently we have a warning
>> message, but this could be solved with a bit more work.
>>
>> There are several data.gov.uk-specific assumptions in the code: the
>> names of the roles we are interested in, users copied from Drupal are
>> called user_d<number>. And of course the Drupal and CKAN sites are on
>> the same hostname to share the cookies.
>>
>> The code is here:
>> https://github.com/datagovuk/ckanext-dgu/blob/master/ckanext/dgu/authentication/drupal_auth.py
>>
>> As far as configuration goes, in our ckan .ini we set the values for:
>> dgu.xmlrpc_username
>> dgu.xmlrpc_password
>> dgu.xmlrpc_domain
>>
>> and add 'dgu_drupal_auth' to ckan.plugins
>>
>> You can see in our plugin.py how to create the DrupalAuthPlugin to
>> allow the middleware to be inserted into the request handling stack:
>> https://github.com/datagovuk/ckanext-dgu/blob/master/ckanext/dgu/plugin.py
>>
>> We also added a repoze.who plugin to ensure that 401 'not allowed'
>> requests sends the user to a custom 'not_authorized' web page, rather
>> than the CKAN log-in form. To achieve that we added the plugin in
>> who.ini:
>>
>> [plugin:dgu_auth_tkt]
>> use = ckanext.dgu.authentication.auth_tkt:make_plugin
>>
>> In [plugin:friendlyform] and [plugin:openid] sections:
>> rememberer_name = dgu_auth_tkt
>>
>> and in [identifiers]:
>>     dgu_auth_tkt
>> instead of
>>     auth_tkt
>>
>> David
>>
>> On 26 March 2013 10:54, Irina Bolychevsky <irina.bolychevsky at okfn.org> wrote:
>>> Hey David,
>>>
>>> Hope you're well. We were wondering if you have any documentation on how you
>>> guys set up the shared login for the drupal and ckan parts of data.gov.uk
>>> (or, how is this actually configured?).
>>>
>>> If not, any chance we can pick your brain on this? A post somewhere would
>>> likely be popular!
>>>
>>> Cheers,
>>> Ira
>>>
>>> --
>>>
>>> Irina Bolychevsky
>>> CKAN Product Owner
>>>
>>> The Open Knowledge Foundation (http://www.okfn.org)
>>>
>>> More information on CKAN: http://ckan.org/
>>>
>>> Follow me on Twitter: http://twitter.com/shevski
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev