[medpri] expanding LDAP functionality to include authorisation

[cleary]

The Problem:

dotProject currently uses ldap for "authentication" (ie you can point to an LDAP server to check password hashes against a username), but by default a user does not have access to anything until they have gone through a manual "authorisation" setup (eg being given access to certain companies, or be assigned a certain dP user type).

A subset of this problem occurs when:

1. users leave the company (off-boarding) - users must be manually set inactive, or
2. change roles internally (cross-boarding) - users must have their permissions manually updated (which currently ends up with users getting way more access than they perhaps should)

The Proposed Outcome:

Scenarios:

1. A new user starts, and is given authorisation attributes in LDAP as part of their onboarding process
   The user logs into dotProject for the first time, and the user account is created automatically (this is current behaviour):

• the user account then has it's Company and Department fields populated based on LDAP group membership (or some other definable attribute)
• the user is authorised to access (view/edit etc) Company/Department (perhaps even, to project level?) based on required attributes

2. An existing user changes role and has some permissions added, and some removed:

• the user logs into dP after these changes are made, and the dP user account should update it's authorisation fields for this user automatically

3. A user leaves De Bortolis:

• the way we handle this in LDAP at the moment is to remove the user from the "Active Users" ldap group - I'm not sure how industry standard this is
• the dP user account should be in the dP inactive users group now, and should no longer be available for selection as project contact/resource etc

Looking for proposals on how we can enhance the existing authorisation system in dP so that we can define and check ldap based require attributes.
I'm wondering if the plugin interface gives us enough access to hook in to Company and Department configs to add extra fields? As a plugin/module, this seems like the least generally invasive way to implement

[ajdonnison]

The authentication suite has a fixed LDAP authenticator, but does support auto-loading other authenticators so if you saw this as being something specific it might be worth creating a different LDAP authenticator that adds the authorisation you require. From memory it will look for a file of classes/auth..class.php and expect it to define a class of Authenticator. So you could, for instance, create ldap_extended if you didn't want to change core code.

One failing of the current authenticators is the fallback code. At the moment it is all or nothing, so that you either always authenticate via the authenticator or you allow it to try the SQL authenticator first. This was originally designed so that you can drop back to SQL for the admin user - but it doesn't really need to be like that - and it is specific to each Authenticator, so rolling your own replacement means you could, for instance, only use the SQL auth when LDAP fails (rather than the other way around), or even only if the user is the admin user. Something I need to think about for the core authenticators anyway.

With the authentication filter, you should be able to limit the login to only those that have certain characteristics - which you can do now with the LDAP auth. Using something like (&(uid=%USERNAME%)(loginAllowed=TRUE)) for the LDAP filter would check that both the uid existed and that some flag field called loginAllowed is set to true. That field is arbitrary so you can build as complicated an expression as you require.

On authorisation, I can't see any impediment to that as there is very little separation of the core modules - so the authenticator could update other tables and set up the user as required. If you wanted to have it configurable then probably you'd need to identify what fields on the LDAP schema provided the information - you could use groups, or have specific fields - it would depend on how your internal schema was set up.

[cleary]

@ajdonnison thanks for this, it looks like you've done half the work already!

I think this will give us a good base to start designing from - a replacement authenticator as a separate module called ldap_extended works for me (I expect it's not something that a lot of people will want, so the ability to disable it is important).

I went through some existing implementations we have internally with the guys, and the general consensus is that a Role based access control model is the preferred method, which dP already implements.
At a broad level, the only parts I think are missing are:

• Roles need a field mapping to one or more LDAP attributes to define membership
• Users on login need to query LDAP attributes in order to determine role assignment/membership

I'll try and spend a bit of time on this in detail over the next week and present some detailed ideas shortly -

[cleary]

Initial brainstorm, the only change here is doing automatic Role Creation based on an LDAP query filter - the next stage will be making sure we've got fields handling user LDAP group (and therefore, dP Role) membership:

[cleary]

Ok, last piece of the mapping puzzle, the User Role Attribute field:

[cleary]

Hi @mattbell87 @rafaelqg -

1. I've created an ldap_extended branch for working on this feature
2. I've discussed your LDAP experience briefly offline - both of you have some familiarity with it, so it would be great to have you working together on this -

How did you want to begin?

@ajdonnison - do you have any comments on the current state of my proposal?
Is it doable as a module, or would it require core modifications?