search

eclipse-archived / packagedrone

Eclipse Package Drone
http://eclipse.org/package-drone
Eclipse Public License 1.0
66 stars 39 forks source link

Feature LDAP support #54

Open nfalco79 opened 8 years ago

nfalco79 commented 8 years ago

A big feature to agree this application in our organisation is a connetor to LDAP or Active Directory. This feature permit avoid take a census again of all employeers, external resources, groups and permissions to access the channels.

Do you have in the roadmap an LDAP integration in the near future? Are there a pluggable system with spi interfaces to develop authentication modules?

ctron commented 8 years ago

There is indeed a pluggable system behind all that. I am not 100% sure it works the way it should, but this is definitely planned to be that way. But there is no LDAP support on the roadmap. Since there is no real roadmap ;-) It is mostly a community driven project.

But I would really like to see LDAP support. I fully agree that it should be there.

ctron commented 8 years ago

The UserService is the one authentication users. There can be multiple present with OSGi. All registered services will be considered.

nfalco79 commented 8 years ago

I had a look to UserService interface. It's fine to integrate, if I understand it you had implement a realm similar JAAS that cycles all security declarative services (ds) and if one return null try with next one. The difficult is on the UserStore. While the SecurityServiceImpl supports multiple UserService, the web ui and some other classes support only one UserStore (cardinality 1..1) and some web page cast directly to DatabaseUserInformation. So if I implement the LDAP UserService with own UserStore it's uncert which UserStore service will be used and the UserStorageModelProvider it's not exported by own plugin.

Many years ago I use an eclipse plugin originally developed by IBM Lotus Notes guys that implement an OSGi realm based on JAAS that use LoginModule and User/Role Principal, but it uses eclipse extension point.

I'm also considering to use third party implementation for LDAP connection that support various LDAP, but some of those (for example apache directory) has a lot of dependencies :-1:

ctron commented 8 years ago

Yes, you right. The UserStorage is only allowed once and pretty much related to a database backend.

However, it should not be necessary to actually use it, since the UserStorage is currently only used to create users, which you wouldn't want to do using LDAP. There is the GodModeService, which does implement the "admin token" logon, using a different UserService implementation.

I do know this implementation JAAS based implementation. And the current implementation is a simple mixture of that and Spring Security. The problem with all those is, that they bring in too many dependencies and especially Spring is a beast when it comes to OSGi.

I would say the an LDAP security module should not be able to actually create LDAP users. So maybe you need to store some preferences at some point, but then we would some sort of PreferenceService which works independently of the actual UserService implementation.

ctron commented 8 years ago

I think it would be interesting to look at Apache Felix JAAS Support. [1]

[1] https://felix.apache.org/documentation/subprojects/apache-felix-jaas.html

nfalco79 commented 8 years ago

In the classic LDAP integration scenario users are registered at login (if not already present) on the fly in the storage using informations that comes from LDAP as mail, first name and last name. User data syncronization could happens in some manner: never, every login or scheduled.

After user logged in, the administrator could setup its roles, not possible for in-memory user as in godmode. In many system users could also setup some own attributes as mail (or other) different from LDAP. The password attribute and some key attributes (as user id) are not permitted to be changed. This is the reason usually LDAP users are persisted.

Depending on the plugin of LDAP integration (and from LDAP) it could discover also groups, typically by memberOf LDAP attribute but not all LDAP server fully support it (for example OpenLDAP). It's not best practice using LDAP groups to match its role on the group name because the role/group ADMIN or MANAGER could give special grant in other software (that matches that role name) you do not want to. Typically LDAP group is used in LDAP filter to subset users that could access this software.

Sorry for bad english