[ckan-dev] Announce: LDAP auth plugin

Mon Jun 23 11:35:19 UTC 2014

Hi,

On 23/06/14 10:32, Sean Hammond wrote:
>>
>> We've implemented an LDAP auth plugin.
>
> I'm currently working on a very similar plugin:
>
> https://github.com/ckan/ckanext-oauth2waad
>
> It's also an auth plugin for WAAD, but for OAuth 2.0 not LDAP. I've
> already written tests for it, so they might give you some ideas when you
> come to writing your own tests

Thanks, I'll take a look.

> It's interesting that you use a database table to map LDAP users to CKAN
> users. I've always just implemented this mapping in logic. For example
> in ckanext-persona I use the email address to uniquely identify the user
> both in Persona and in CKAN and to connect the two. In
> ckanext-oauth2waad I use the WAAD OID's which uniquely identify users in
> WAAD as the usernames in CKAN.
>
> In both of my cases I felt the chances of a name conflict (where
> there's a Persona or WAAD user with the same email address or OID as an
> existing CKAN user who is not the same person) was small. Two different
> people shouldn't have the same email address, and WAAD OIDs are these
> long randomised strings so the chance of a conflict is small.
>
> But I guess with LDAP this assumption doesn't hold?

Well the more I looked into this, the more I realised that it's not 
possible to make any assumption in the mater. Note that we have two 
important requirements :

1. We want to support internal users via LDAP, but also allow external 
users to create accounts;
2. We want a single login form for both types of users (and they 
shouldn't have to select which type of account they're using - we should 
work that out from the credentials they enter).

The two possible identifiers that we could use to map our LDAP user id 
to a user stored in CKAN's user table are the user name and the email.

CKAN imposes restrictions on the user name (/[-_a-z0-9]{2,100}/), so to 
use that to store our LDAP user id means it would have to conform to 
these restrictions. This is quite limiting, and would exclude, for 
example, Active Directory's sAMAccountName attribute (the "short windows 
user name") which can use characters beyond those allowed by CKAN.

When it comes to the email, CKAN itself does not enforce that email 
addresses should be unique - if you look at the default user schema [1], 
you will see the only restriction is that their should be an email 
address (which doesn't even have to be a valid one). So to use the email 
I would have to override user_create to ensure the email address is 
unique, otherwise an external user could create an account with the same 
email (and thus ldap id) as an internal user.

Even if CKAN did enforce the email address to be unique, that would mean 
that the LDAP directory would have to map each user to an email address 
- and that each email address should map to one user only! Given that 
Active Directory users can have more than one email address, I'm not 
sure the latter is true - and I don't want to find out the hard way :-)

And of course LDAP itself is not used only by Active Directory - anyone 
can make their own schema which makes it impossible to make any assumptions.

So all in all, it just felt safer to store the ldap user id to ckan user 
id map - even if that requires an extra database table to do it.

Cheers,
Alice

[1] https://github.com/ckan/ckan/blob/master/ckan/logic/schema.py - 
search for 'default_user_schema'

>
> Anyway I think that provides a good example of how to map users from
> elsewhere to users in CKAN, in a situation where you can't simply match
> up the usernames or email addresses and ignore the possibility of
> conflicts.
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev