[dancer-users] Dancer2 Dancer2::Plugin::Auth::Extensible::Provider::LDAP

[Alex Mestiashvili]

Hi,

On Wed, Oct 10, 2018 at 3:42 PM Attila Bárdi <attila.bardi at gmail.com> wrote:

> Hey,
>
> I used Ldap with Dancer and it works pretty fine. Now I want to develop a
> new microsite, I thought it would be better with Dancer2(0.206000). But I
> cannot make the Ldap (0.702) authentication to work.
>
> I turned on the ldap logging. By the log It looks working, because it
> found the user, but the page says login failed. The second search for the
> groups has 0 match, the user doesn't member of any group. But I can log in
> with the user foo, and he is not a member of any group neither. The result
> is LOGIN FAILED.
>

As far as I understand You'd like role-based access control for your app,
where roles are actually ldap groups. I.e. uid belongs to a group <=> has a
role.
Now you have to decide what exactly will contain the roles. In unix a user
can have 1 primary group and multiple secondary groups.
IMHO it is more flexible to check for members of the secondary groups,
which may have the following format in case of openldap:

objectClass: posixGroup
displayName: powerusers
description: "members have role users"
gidNumber: 1001
cn: powerusers
memberUid: user1
memberUid: user2
memberUid: ...

If you'd like to check for the primary group then you'll probably will need
to check for gidNumber..


>
> In the Dancer2 log says:
>
> Odd number of elements in anonymous hash at
> /usr/local/share/perl/5.24.1/Dancer2/Plugin/Auth/Extensible/Provider/LDAP.pm
> line 279.
>
> OpenLdap log:
>
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 fd=106 ACCEPT from
> IP=a.b.c.d:47724 (IP=0.0.0.0:389)
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=0 BIND
> dn="cn=Administrator,dc=gothamcity,dc=example,dc=com" method=128
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=0 BIND
> dn="cn=Administrator,dc=gothamcity,dc=example,dc=com" mech=SIMPLE ssf=0
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=0 RESULT tag=97
> err=0 text=
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=1 SRCH
> base="dc=example,dc=com" scope=2 deref=2
> filter="(&(objectClass=inetOrgPerson)(uid=battila))"
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=1 SEARCH RESULT
> tag=101 err=0 nentries=1 text=
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=2 SRCH
> base="dc=example,dc=com" scope=2 deref=2
> filter="(&(objectClass=groupOfNames)(member=uid=battila,ou=people,dc=gothamcity,dc=example,dc=com))"
>

This seem to be the problem, this LDAP plugin as far as I see is intended
to be used with WindowsAD.
The searchfilter above is simply not applicable for your case. In case of
openldap
 rolefilter would be rather memberUID: $uid instead of
member=uid=$uid,ou=blabla,dc=....
It is also hardcoded into the plugin:
https://metacpan.org/source/SYSPETE/Dancer2-Plugin-Auth-Extensible-Provider-LDAP-0.702/lib/Dancer2/Plugin/Auth/Extensible/Provider/LDAP.pm
Lines 256-264:

        # now get the roles

        $mesg = $ldap->search(
            base   => $self->basedn,
            filter => '(&'
              . $self->role_filter . '('
              . $self->role_member_attribute . '='
              . $entry->dn . '))',
        );

But the good thing is that you can simply change that :)


> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=2 SEARCH RESULT
> tag=101 err=0 nentries=0 text=
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=3 UNBIND
> Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 fd=106 closed
>
> User entry in the openldap:
>
> dn: uid=battila,ou=people,dc=gothamcity,dc=example,dc=com
> cn: Attila Bardi
> gidNumber: 1901
> givenName: Attila
> loginShell: /bin/bash
> description: example
> objectClass: top
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: inetOrgPerson
> shadowInactive: -1
> shadowLastChange: 14284
> shadowMax: 99999
> shadowMin: 0
> shadowWarning: 7
> sn: Bardi
> uid: battila
> uidNumber: 43821
> homeDirectory: /home/battila
> mail: battila at example.com
> structuralObjectClass: inetOrgPerson
> entryUUID: d3a89750-5a5e-1038-9b9a-dbf2c7148bb9
> creatorsName: cn=Administrator,dc=gothamcity,dc=example,dc=com
> createTimestamp: 20181002071629Z
> userPassword:: e1e1ee1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e
> entryCSN: 20181002075005.324787Z#000000#000#000000
> modifiersName: uid=battila,ou=people,dc=gothamcity,dc=example,dc=com
> modifyTimestamp: 20181002075005Z
>
>
> Dancer2 config.yml
> plugins:
>        Auth::Extensible:
>                realms:
>                        config:
>                                provider: Config
>                                users:
>                                        - user: 'foo'
>                                          pass: 'secret'
>                        users:
>                                provider: LDAP
>                                host:   'openldap01'
>                                binddn:
> 'cn=Administrator,dc=gothamcity,dc=example,dc=com'
>                                bindpw: 'secret'
>                                basedn: 'dc=example,dc=com'
>                                user_filter: '(objectClass=inetOrgPerson)'
>                                username_attribute: "uid"
>
> I tried *disable_roles: 1 *after this but the result is still LOGIN
> FAILED.
>
>
Another thing which in my opinion is plain wrong is that you need to
provide admin binddn and bindpw.
In openldap world normally a user can bind itself and get all the necessary
attributes.
Also in many setups it is just not secure to give admin access to ldap tree
to a web app.

Here is the plugin for Dancer1 which works with openldap without admin
access:
https://pastebin.com/vy9ea9P8
May be it will give you some hints, though it is easier to fix the original
Dancer2 plugin.

Best,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20181010/c03cf9dd/attachment.html>