Question

hi *

after reading a lot of LDAP-Twiki-Support-Pages i still wonder if:

i could do a 'simple' authentication against an authentication-ldap-satellite which gives back only 'true/false' depending on login-credentials

for 'true' i'd like to map the authenticated user to a default wiki-user like UserFromLDAP

for 'false' a secondary authentication manager should check if local-twiki-user matches

due to the description in LdapContrib

"Note: This package downloads all relevant records from your LDAP server into a local cache the first time you use it."

i'm not sure, if this isn't 'oversized' for my requests, also since i would face more than 25.000 users that way ...

Environment

-- BernhardMaier - 01 Nov 2007

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Your use case is not as simple as you may think:

1. authentication against an LDAP directory
2. generation of WikiNames for logged in users
3. fallback to a secondary password manager

You might also want to install the NewUserPlugin to generate the home topics automatically, a thing that the normal TWikiRegistration process would have done.

Caching all user records is a performance feature. Without, TWiki would query your LDAP directory for every user and group object it creates internally. LdapContrib has been tested with a couple of thousand users and groups and should also work fine for you. Just give it a try.

-- MichaelDaum - 01 Nov 2007

thank you for answering

seemingly i was not able to sufficiently explain my problem ...

• the LDAP-directory allows only ldapcompare on login and passwd (only authentication-satellite!)

• compare is not equal to read (you can send credentials, but never get them returned)

• i am not allowed to store user-data from ldap on my twiki-server (privacy protection, Datenschutz)

• the only information i get from the directory is 'ldap_compare_true' or 'ldap_compare_false'

• there should be a group of local users with local authentication and one twiki-user with LDAP-authentication

• • that means: all the users from LDAP should be mapped to the same twiki-user (e.g. LDAPguest)
  • this twiki-user is not allowed to edit, attach or anything else than view
  • access-control on webs and topics should be managed by twiki (plugins should identify context)

• in case LDAP-authentication fails, the second auth-manager should try versus local twiki-user

imho this scenario is typical for schools and universities, where a group of teachers is able to edit content and a lot more students are allowed to read it. the reason for student's-authentication derives from rights managment on content and exclusiveness ...

because of the given requirements i think, the LDAPContrib is not appropriate (not offending at all!)

as this usecase seems quite reasonable, i believe support on this could be helpful to a lot people ...

homework

reading about twiki, perl and ldap i got a little familiar to these topics - so i'm thinking about programming a contrib myself ... but i was not able to find out, how i can switch the status of the requesting user to authenticated and mapp him to LDAPguest (probably a simple session-thing ...)

would be nice, if someone could collaborate

-- BernhardMaier - 02 Nov 2007

Authentication using LDAP is typically not done by comparing attributes for a couple of reasons:

1. comparing attributes, i.e. user passwords means sending them over the network, which is only secure if you use LDAPS
2. even in order to compare LDAP attributes you still have to bind to the server using a kind of proxy user in the directory
3. binding to the directory using a proxy user is already requiring authentication
4. sou you can use binding to LDAP directly to authenticate

To implement your authorization scheme you don't necessarily need to map all LDAP users onto one TWiki user. In general you bundle users in groups and use the group to define access rights. This will always be more flexible. You still can use LdapContrib out of the box to map them all onto the same user. However, if caching is considered a privacy breach you are very much stuck in the mud using any two systems that share user information even if it is only credentials.

-- MichaelDaum - 03 Nov 2007

Seems to be aswered. Please feel free to re-open with more details if necessary.

-- PeterThoeny - 11 Dec 2007