Bug 34737 - [Patch] LDAPAccreditableManager
Summary: [Patch] LDAPAccreditableManager
Status: NEW
Alias: None
Product: Lenya
Classification: Unclassified
Component: Access Control (show other bugs)
Version: 1.2.3
Hardware: Other other
: P2 enhancement
Target Milestone: 2.0.1
Assignee: Lenya Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-04 13:40 UTC by Maxim Wasiliev
Modified: 2007-07-16 02:38 UTC (History)
1 user (show)



Attachments
implementation (87.10 KB, patch)
2005-05-11 17:40 UTC, Maxim Wasiliev
Details | Diff
sample configuration (1.54 KB, text/plain)
2005-05-12 06:48 UTC, Maxim Wasiliev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim Wasiliev 2005-05-04 13:40:14 UTC
it should load and authenticate users/groups/ipranges from ldap database.
Comment 1 Maxim Wasiliev 2005-05-11 17:40:07 UTC
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.
Comment 2 Maxim Wasiliev 2005-05-12 06:40:20 UTC
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>
Comment 3 Maxim Wasiliev 2005-05-12 06:48:22 UTC
Created attachment 15005 [details]
sample configuration

This is configuration to use LDAPAccreditableManager with nis.scheme
(posixAccount, posixGroup, ipNetwork)
Comment 4 Torsten Schlabach 2005-05-12 23:03:50 UTC
(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.
Comment 5 Gregor J. Rothfuss 2005-05-15 22:10:44 UTC
jwk, can you review?
Comment 6 Joachim Wolfgang Kaltz 2005-05-17 09:55:00 UTC
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.
Comment 7 Joachim Wolfgang Kaltz 2005-05-23 14:23:07 UTC
added dev to CC list (otherwise IIUC dev list no longer gets notified, as is
assigned)