[GeoNetwork-devel] LDAP planning: a sample implementation?

Hi Everyone,

We've implemented an OpenLDAP solution with geonetwork 2.0.2/3 that might be of interest to the community.

The basics are:

1. Uses the intrinsic JNDI interface
2. Integrates existing directories into a specific geonetwork directory:

    - using an OU or organizationalUnit with children that are referrals to existing LDAP directories for authentication (can be any number)

eg. ou=authentication in our geonetwork directory has three referrals to remote ldap servers:

- ou=adpeople (active directory people) slurped from Windows domain A/D
- ou=extpeople (external people)
- ou=ftp (people from our ftp server)

3. Admin overhead is removed by authenticating against each child of ou=authentication and then adding users from those existing LDAP directories to an ou=geonetworkusers and groups in ou=geonetworkgroups. Specifically:

- new user to a child ou of ou=geonetworkusers eg. a user geoff authenticated against ou=adpeople would be added as uid=geoff,ou=adpeople,ou=geonetworkusers,..... - given a profile of RegisteredUser and a generated userid

- a group representing the ou they logged in from is created if not present and/or the user is added as a member

- an invisible group with just the new user as the only member for use when creating new metadata records

4. I've removed the user admin interface (coz ldap users do these kinds of things elsewhere and we don't need the userPassword field in the geonetwork directory) and changed the groups interface to just a show and list (still need to add a group mod interface)

5. You can have a group as a member of a group eg. my registeredusers group has three group members: adpeople, extpeople and ftp

6. ldap replaces users, groups and usergroups tables in geonetwork database implementation - rest of the geonetwork db implementation remains the same

It's kind of a minimalist approach but it works well and draws on some of the strengths of the ldap hierarchy. But I think the lack of an admin overhead is helpful - the geonetwork user and group stuff is built from existing directories.

Anyways its a suggestion about how an LDAP implementation could be done. I did add some simple schema objectclasses (geonetworkUser and geonetworkGroup) which use built in ldap attributes (eg uidNumber and gidNumber) and use OIDs from the experimental range.

Cheers,
Simon

Hi Simon,

we are very interested into your patch and I would be grateful if
you could send me a diff with geonetwork 2.0.3.

LDAP implementation is scheduled for next months and it will be
probalbly different from yours because we have to keep both
working modes (with and without LDAP) and some other choises
will differ. Anyway, your implementation will still be very usefull to
us and as far as I can, I will try to add it "as is".

Cheers,
Andrea

Hi Everyone,

We've implemented an OpenLDAP solution with geonetwork 2.0.2/3 that
might be of interest to the community.

The basics are:

1. Uses the intrinsic JNDI interface
2. Integrates existing directories into a specific geonetwork directory:

    - using an OU or organizationalUnit with children that are referrals
to existing LDAP directories for authentication (can be any number)

eg. ou=authentication in our geonetwork directory has three referrals to
remote ldap servers:

- ou=adpeople (active directory people) slurped from Windows domain A/D
- ou=extpeople (external people)
- ou=ftp (people from our ftp server)

3. Admin overhead is removed by authenticating against each child of
ou=authentication and then adding users from those existing LDAP
directories to an ou=geonetworkusers and groups in ou=geonetworkgroups.
Specifically:

- new user to a child ou of ou=geonetworkusers eg. a user geoff
authenticated against ou=adpeople would be added as
uid=geoff,ou=adpeople,ou=geonetworkusers,..... - given a profile of
RegisteredUser and a generated userid

- a group representing the ou they logged in from is created if not
present and/or the user is added as a member

- an invisible group with just the new user as the only member for use
when creating new metadata records

4. I've removed the user admin interface (coz ldap users do these kinds
of things elsewhere and we don't need the userPassword field in the
geonetwork directory) and changed the groups interface to just a show
and list (still need to add a group mod interface)

5. You can have a group as a member of a group eg. my registeredusers
group has three group members: adpeople, extpeople and ftp

6. ldap replaces users, groups and usergroups tables in geonetwork
database implementation - rest of the geonetwork db implementation
remains the same

It's kind of a minimalist approach but it works well and draws on some
of the strengths of the ldap hierarchy. But I think the lack of an admin
overhead is helpful - the geonetwork user and group stuff is built from
existing directories.

Anyways its a suggestion about how an LDAP implementation could be done.
I did add some simple schema objectclasses (geonetworkUser and
geonetworkGroup) which use built in ldap attributes (eg uidNumber and
gidNumber) and use OIDs from the experimental range.

Cheers,
Simon

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork