Feature Discussions

[king]

Dear FirstSpirit community,

we just read about the current existing solution when trying to integrate FirstSpirit with LDAP. Details might be found within the current FirstSpirit Admin documentation.

There, it seems to be evident, that all externally administrated LDAP users will be added physically to FirstSpirit. This happens the first time, the user logs in.

Consequence: the user, does not stay external within LDAP - no, it will be imported to FirstSpirit With all sideeffects this behaviour offers, like:

- users cannot be administrated centrally in LDAP

- groups have to be created physically in FirstSpirit marked as "external" (their name has to match the name in LDAP)

- changed attribute values will not be replicated to FirstSpirit (only at 1st login time)

Even the dialog boxes for:

- administrating users (creation, modification, deletion)

- administrating groups (creation, modification, deletion)

- the editing rights (JavaClient -> Extras -> Rights)

do not allow a direct LDAP read-browsing - no, they just maintain local FirstSpirit user/group objects. This should be changed, to allow a central storage and to prevent duplication.

So, the current FirstSpirit LDAP solution guarantees just LDAP authentication but no LDAP authorization.

When comparing with other LDAP solutions like "mod_auth_ldap" in Apache or "pam_ldap" in Linux, users never will be created physically on the corresponding system environment - due to the above mentioned side-effects.

Our requirement:

- allow assigning FirstSpirit projects one or more configured LDAP connection configuration

- offer a solution where FirstSpirit users/groups are really maintained centrally

- prevent storing users/groups offered via LDAP in FirstSpirit directly

- enhance the user/group administration dialog boxes within FirstSpirit to allow browsing and mainting the central LDAP

- enhance the FirstSpirit rights dialog in JavaClient to allow browsing the LDAP target system and assigning (FirstSpirit) users/groups out of LDAP

[Peter_Jodeleit]

Some annotations:

1) The user is not "copied" from LDAP, there will be just a pointer stored in FirstSpirit and some caching of informations (therefore "deleting" a user flagged as LDAP user in FirstSpirit would just lead to a re-creation the next time the user logs in)

2) The cached informations are updated at every login process of the external user, including group memberships

3) I do not unterstand why you want to administer your LDAP data in FirstSpirit? That would contradict the idea of a centralized user administration!?

Perhaps you could comment on this.

[king]

Dear Peter,

(1) your answer regarding the update of changed LDAP user attributes seems to contradict the FirstSpirit Adminstrator Documentation in chapter 4.4.2 where it is just mentioned, that only attributes are synchronized with LDAP at 1st login time of the FirstSpirit user.

(2) externally marked FirstSpirit group names have to be created physically on FirstSpirit side, having the identical Distinguished Names (DN) compared to the group membership of the user within LDAP to allow a proper user <-> group assignment after the user login.

(3) it is not requested to administrate the LDAP directory service itsself, but to access it in read-mode. This would allow referencing LDAP users/groups in FirstSpirit directly. Up to now, it is needed to create the groups manually in FirstSpirit. Why not omitting the group creation in FirstSpirit and taking the user -> group assignment directly out of the LDAP directory. This would prevent manual efforts and duplication.

[Peter_Jodeleit]

Holger,

you are correct, in the documentation the phrase "initial import" is used. It seems I'm mistaken at this point. So the desired feature here is that the user attributes are updated on every login.

Concerning 2) and 3): The desired feature here seems to be that ldap-groups should be automatically "in sync" with FirstSpirit? The question arising here is: When should the "sync" take place? Let me assure, you really don't want a "read only view" into the LDAP. For performance and availibility reasons

[king]

Dear Peter,

well, the ideal way in case of an FirstSpirit-LDAP integration would be:

- preventing the creation of user/group objects in FirstSpirit again (reason: duplicates), either by just referencing the user/group objects available in LDAP or by completely relying on LDAP itsself

The following use cases could be identified:

1. adding a user to a project, either: the LDAP user refence is stored in the FirstSpirit project, or: the FirstSpirit project the user has been assigned to is stored in one of the (FirstSpirit custom schema) user attributes in LDAP directly
2. when adding a group to a project, either: LDAP group reference is stored in the FirstSpirit project, or: the FirstSpirit project the group has been assigned to is stored to one of the (FirstSpirit custom schema) group attributes in LDAP directly
3. when assigning a user to a group, either: the information is stored in the group reference, or: written to LDAP directly
4. setting permission editing rights on user/group level for a FirstSpirit tree node, either FirstSpirit stores the information using the already mentioned user/group LDAP references locally, or: writes it to LDAP directly

Consequences:

-> read/write access to LDAP needed!

-> intelligent FirstSpirit caching logic needed in case where everything is stored in LDAP

Am I right?

[Peter_Jodeleit]

I don't think the suggested write access to LDAP is practical. And i don't see the advantages of storing permissions directly in LDAP. Neither I know of a tool which does that.

[king]

Well, the advantage of storing the information centrally in LDAP is:

- no duplicates and no synchronization

- administration is done just towards LDAP (no need to administrate authentication/authorization credentials in a 3rd party storage)

What about the synchronization of LDAP groups with FirstSpirit? Currently, only users are synchronized - not the groups itsself.

[Peter_Jodeleit]

Well, the advantage of storing the information centrally in LDAP is:

- no duplicates and no synchronization

- administration is done just towards LDAP (no need to administrate authentication/authorization credentials in a 3rd party storage)            

Don't get the point. This is already provided by the current (*) integration.

What about the synchronization of LDAP groups with FirstSpirit? Currently, only users are synchronized - not the groups itsself.

See abvove, where I posted the question "when" to sync group informations whith FirstSpirit.

I'll try to suggest an answer: Everytime a login takes place and the user logging in has a "matching" group (according to some filter) and this matching group is not yet present as "external group" in FirstSpirit.

* Edited

[king]

Peter Jodeleit schrieb:                   

Well, the advantage of storing the information centrally in LDAP is:

- no duplicates and no synchronization

- administration is done just towards LDAP (no need to administrate authentication/authorization credentials in a 3rd party storage)            

Don't get the point. This is already provided by the current (i.e. "poor") integration.

Why? The users are synched and dynamically re-created in FirstSpirit, the groups even have to be created in FirstSpirit before a user (that is synched with LDAP) could be assigned to it. So, where is a central administration?

Administrators have to create the group in LDAP and ADDITIONALLY create the group in FirstSpirit.

Peter Jodeleit schrieb:

What about the synchronization of LDAP groups with FirstSpirit? Currently, only users are synchronized - not the groups itsself.

See abvove, where I posted the question "when" to sync group informations whith FirstSpirit.

I'll try to suggest an answer: Everytime a login takes place and the user logging in has a "matching" group (according to some filter) and this matching group is not yet present as "external group" in FirstSpirit.

Yes.

[Peter_Jodeleit]

You wrote:

> no need to administrate authentication/authorization credentials in a 3rd party storage

This is exactly what is achieved by the current implementation.

Assuming FirstSpirit is the "3rd party storage".

[king]

But Peter - then I have a misunderstanding. Can you help me?

I thought, that FirstSpirit groups have to be created physically and are currently not synched to FirstSpirit.

Is that right?