Bug 34737

Created attachment 14998 [details]
implementation

This is implementation of LDAPAccreditableManager.
It works in read/only mode: could only read users/groups/ipranges/roles from
ldap database, but not create new.
IPRanges are not groupable, because groups are oriented to ldap posixGroups of
users.
Roles are also stored in ldap, just for fun.

Documentation is in javadoc.

Required setup
cocoon.xconf:
<accreditable-managers>
    <component-instance logger="lenya.ac.accreditablemanager"
class="org.apache.lenya.ac.file.FileAccreditableManager" name=
    <component-instance logger="lenya.ac.accreditablemanager"
class="org.apache.lenya.ac.ldap.LDAPAccreditableManager" name=
</accreditable-managers>

lenya.roles:
  <role name="org.apache.lenya.ac.AccreditableManagerSelector"
        shorthand="accreditable-managers"
       
default-class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector">
    <hint shorthand="file"
class="org.apache.lenya.ac.file.FileAccreditableManager"/>
    <hint shorthand="ldap"
class="org.apache.lenya.ac.ldap.LDAPAccreditableManager"/>
  </role>

Created attachment 15005 [details]
sample configuration

This is configuration to use LDAPAccreditableManager with nis.scheme
(posixAccount, posixGroup, ipNetwork)

(In reply to comment #3)
> Created an attachment (id=15005) [edit]
> sample configuration
> This is configuration to use LDAPAccreditableManager with nis.scheme
> (posixAccount, posixGroup, ipNetwork)

Thank you for the clarification. We should point this out in the 
documentation. There is two kinds of LDAP schemes beeing widely used:

1. posixAccount / posixGroup

usually found in environments that use LDAP for Unix type of user admin

2. SimpleSecurityObject / GroupOfUniqueNames

often used if there is no Unix around or if LDAP is not the OS user DB but 
just used for authentication in webapps.

jwk, can you review?

What I understand regarding this patch is :
the patch replaces the current LDAPUser mechanism to use the NIS scheme of an
LDAP directory. That means that other usage scenarios would no longer work, such as:
- MS Active Directory, which constructs principals quite differently
- scenarios where the LDAP directory may not be changed for Lenya, i.e. it is
not possible / wanted to store any additional information in LDAP for Lenya. In
these scenarios, LDAP is just used to check for username/password to avoid users
having multiple passwords within an organization.
It looks to me that the patch would break these features. So what we would need
instead is maybe a PosixLDAPUser, as something separate from the current LDAPUser. 
In addition, we would need a configuration mechanism saying whether to use
FileAccreditableManager (meaning Lenya user confs are located in Lenya) or
LDAPAccreditableManager (meaning they are located entirely in LDAP), and where
to use them: e.g. for the whole publication or for individual users. If it's for
individual users, we would need a sort of authorization stack (as for example
Linux's PAM), for example:
- if a user tries to log-in, first check whether she is a Posix LDAP user
- if not, check if she is defined in a Lenya file

Bottom line: applying this patch replaces the Lenya user handling from Lenya
config files to LDAP Posix entries. As it stands the patch can not be applied to
core, more work would be needed so that current Lenya features are still supported.

added dev to CC list (otherwise IIUC dev list no longer gets notified, as is
assigned)