[jira] [Commented] (WHIMSY-298) create/maintain meta-groups for PMCs in LDAP

["Sam Ruby (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WHIMSY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965205#comment-16965205 ] 

Sam Ruby commented on WHIMSY-298:
---------------------------------

> both the ou=projects and the PMC-based ou=meta groups

That, unfortunately, would be necessary, otherwise we will break the ability to allow PMC members to update their own membership.  Take a look at the following:

[https://github.com/apache/infrastructure-puppet/blob/763ef5a69f24e2b15a0ad1f4c99556c4064bec55/modules/ldapserver/templates/slapd.conf.erb#L293]

In particular, line 300.  When I last looked into this, it was possible to do one of two things: enable an attribute within the same LDAP entry to control access, or enable a fixed path to determine access.  The problem was that the latter is neither "relative" nor does it provide wildcards (or if it does, I couldn't figure out how).

What that means is that if you wanted cn=whimsy,ou=meta to be able to control cn=whimsy,ou=group you would need to have a separate entry in slapd.conf for that.  And that would need to be repeated for each PMC.

P.S.  I presume that this has moved to infra-p6, but I haven't figured out how to link to such.

> create/maintain meta-groups for PMCs in LDAP
> --------------------------------------------
>
>                 Key: WHIMSY-298
>                 URL: https://issues.apache.org/jira/browse/WHIMSY-298
>             Project: Whimsy
>          Issue Type: New Feature
>            Reporter: Chris Lambertus
>            Priority: Minor
>
> Infra discovered a downside to the owner/member paradigm of the new LDAP group management style, in that most commercial LDAP-based tooling doesn't have the ability to set specific queries for various authentication parameters. This is most notable in our Atlassian Crowd implementation, in that Crowd only "sees" the members groups and has no way to parse out the Owners for additional privilege scope. Infra has currently created a manual workaround, which is documented in this (currently non-canonical, non-functional) script:
> [https://github.com/apache/infrastructure-p6/blob/9813eacad87fcac69f21e7b7c3233541685bd789/modules/cwiki_asf/files/refresh_meta.sh]
>  
> As you can see, this script would create a new LDAP OU called 'meta' which ETLs the existing owner attributes into a $project-pmc DN which is then visible to Crowd and can be used to apply PMC permissions to Jira and Confluence. We're currently doing this manually "on-demand" until we finish some necessary back-end work for the script to function.
> I realize it's a step backwards to once again have to manage multiple LDAP groups, but unfortunately, this separation is required due to a lack of support for the owner/member attributes for Crowd. 
> It may be worth Whimsy considering patching to update both the ou=projects and the PMC-based ou=meta groups. If this is something you'd like to do, I would recommend a new OU, as Infra will be continuing to do this purge/ETL for the ou=meta group for the foreseeable future.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)