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]

You are correct. As already mentioned, sync of groups itself is missing (not the group membership of a user if the group is created by hand) and maybe this is a worthwile feature.

Even if this could by accomplished by using the FirstSpirit API, e.g. in a periodic task.

The other missing feature is the periodic sync of user attributes cached in FirstSpirit (like email, phone, clear name) against the LDAP server.

But in my opinion these are the only features worthwile a discussion. No "live" access of LDAP, no storing of FirstSpirit specific data in LDAP etc.

[der_sk]

I "hacked" together a simple script for a periodic creation of AD-(LDAP) groups - it´s not pretty, but it works and could help for further development. See https://community.e-spirit.com/docs/DOC-1561
Please note: This script DOESN´T work if started in project settings - due to locking.

(and sorry for my lack of experience in English :smileygrin:)

[king]

Replication of common:

• user
• group

LDAP objects to FirstSpirit makes absolutely no sense! Just because of data actuality and duplicates.

Imagine, a new user is added to LDAP: the current solution requires a login of this user to allow the FirstSpirit editors to attach this user to a FirstSpirit store node and give him editing rights. Reason: only after the 1st login, the user is replicated in FirstSpirit.

Even bader for the groups: here the groups have to be created manually in FirstSpirit - named identical to the LDAP name. What a duplication horror.

Why not:

• directly browsing the configured LDAP-tree and allowing the user/group selection in FirstSpirit AdminClient directly out of it?
• writing directly to the LDAP directory in case of new user/group creation in FirstSpirit AdminClient?
• writing directly to the LDAP directory in case when a LDAP user is added/removed to a LDAP (external) group?

BUT:

It makes sense to store FirstSpirit specific right/project assignments within the FirstSpirit persistence layer directly, like - as long as FirstSpirit does not offer LDAP specific schema enhancements to store the information in LDAP (what is discussable😞

- when assigning a user/group to a FirstSpirit project

- when assigning a LDAP user/group to a store node and giving them FirstSpirit editing permissions (only project assigned users/groups are available for selection -> not directly LDAP)

The problem in FirstSpirit: groups are only available project-locally. Via the "New group" dialog within a FirstSpirit project the groups is created and in parallel assigned to that project.

That's the way, we expect a proper LDAP solution.

[Peter_Jodeleit]

I totally disagree with the first paragraph. If you use LDAP, than you should configure permissions based on groups. Otherwise use of LDAP "makes absolutely no sense!".

I suspect that you argue in the role of a FirstSpirit user / admin. You really should look from the perspective of a administrator of central administrator, what this person has to do when a new employee is hired or when some FirstSpirit administrative says: "Hey, we need a new role could-edit-stuff-x and these people should initially have this role".

Concernig "Even [worse] for the groups": I already commented on it. But you can argue that the current implementation also makes sense at least in some scenarios. And if you need some "auto group creation" you can still use the script provided by Sascha in the posting above.

I don't comment on the rest of your post as see no new facts or arguments there.

[der_sk]

If I undestood you(r demands) correctly, the only thing missing is the possibility to add a user who didn´t log in at the time.

FirstSpirit doesn´t "replicate" users or groups (as in copy) - it is more like a mapping. With Beanshell-Scripts you can realize (almost) everything of your needs (even the first-user-login-"problem" from above).

Personally I wouldn´t attach any user to a FirstSpirit Node, ever. We use groups for this all the time - if this groups are AD groups you wouldn´t have to manually add users to this groups.

If you add LDAP-writing capabilities to FirstSpirit, you make FirstSpirit a ldap-edit-client. User/group-management should be at ONE place - the ldap-server (or the central administration of that). In my opinion the FirstSpirit-ldap-user shouldn´t even have edit rights to a ldap (for security concerns).

[king]

Okay Peter and Sascha,

I understand for sure, that FirstSpirit is currently not an edit-enabled LDAP client and that user/group-management should be done at ONE place. That's why the "add user", "add group" functionality in FirstSpirit AdminClient just allows the creation of local FirstSpirit users/groups without writing to the central LDAP directory (optionally enhanced with a flag "external").

This approach could be proven when taking a look on the following screenshot, where FirstSpirit users could not be "added"/"removed" from an externally marked group.

It is even okay from my point of view, to save FirstSpirit related data in FirstSpirit, like the assignments of users/groups to FirstSpirit projects. Because FirstSpirit specific attributes are not available in LDAP (to realize that, FirstSpirit specific LDAP schema enhancements might be necessary).

I just wondered, why - in case of an available FirstSpirit LDAP connection - the user/group selection does not allow browsing the LDAP directly. And I wondered, why the user/group creation does not directly write to LDAP. But, there are tools, that do allow that - SAP Netweaver Portal. When you set the LDAP connection in "write" mode, it's possible. Here, our expectation differs.

Now, I understood and learned more - regarding FirstSpirit. What might help, is the dynamic creation of groups. But: in which FirstSpirit projects to create such groups - as long as there are not system-wide FirstSpirit groups (like users) available?  Here, we have a consensus .

Thanks for the patience and the feedbacks.