COmanage Users List

[Scott Koranda <>]

Hi,

Comments inline below.

> This behavior surprised me, I think it's by design 

The behavior is by design, yes, but subject to evolution. 

It should have been documented better. I have added a note to this wiki
page on configuring the Grouper Provisioner:

https://spaces.internet2.edu/display/COmanage/Grouper+Provisioning+Plugin%3A+Configure+Plugin

> but maybe it
> shouldn't be since it messes with what seemed like the most logical
> use-case I could come up with.  Maybe someone can enlighten me as to a
> better way to avoid this issue.
> 
> When I update any CO person information it triggers a provision action
> to the Grouper provisioner which ultimately ends up calling
> provisionCoPerson in CoGrouperProvisionerTarget.php.  At the end of
> the function the CoPerson is deleted from any Grouper groups which
> they do not belong to in Comanage - even groups which do not exist at
> all in CoManage.
> 
> My expected use was that I'd be able to manage identities in Comanage,
> and create no groups in COmanage except the core/automatic CO_COU
> groups which are provisioned to Grouper.  

That is a common use case...

> I then do any further group
> management under the COU sub-stems in Grouper.  

That is not.

Most deployers do any "mixing" in a different stem. A common pattern is
to have a stem for COmanage to provision into that represents the
organizational structure of your CO, but then to have another stem for
managing authorization to services. So the two stems might be

MyCO:Organization

MyCO:Services

That is the common pattern that we have seen and used ourselves, so the
current Grouper Provisioner just fits that pattern.

But there is no reason the GrouperProvisioner needs to act this way.
Grouper supports your use case and so should the COmanage
Grouper Provisioner.

I have created JIRA CO-1531 for the issue:

https://bugs.internet2.edu/jira/browse/CO-1531

I have currently set the fix version for 3.1 but I need to talk with
Benn and do some more serious resource planning to know if I can make
that change for that release.

> This doesn't exactly
> work if Comanage deletes memberships from Grouper groups it isn't
> responsible for, and as far as I am concerned that behavior is really
> only appropriate when we are deleting a CO person and want their
> subject taken out of Grouper groups entirely (but I imagine we could
> catch that by deleting unknown subjects from Grouper groups with a gsh
> job).
> 
> In my case a small workaround in the php code only matches the COU
> default groups for this variable which is used later to loop through
> and delete group memberships not found in CoManage:
> 
> (line 618)
>  // Filter the returned groups by the stem that this plugin is
> configured to control, but only match groups that Comanage is
> responsible for.
>     $grouperGroups = array();
>     $stem = $coProvisioningTargetData['CoGrouperProvisionerTarget']['stem'];
>     // change this preg pattern to only match relevant groups
>     $pattern = "/^" . preg_quote($stem, '/') . ".*" . "CO_COU_.*/";
>     foreach($allGrouperGroups as $g) {
>       if (preg_match($pattern, $g)) {
>         $grouperGroups[] = $g;
>       }
>     }
> 
> This of course wouldn't work if any other groups are created in
> Comanage and not named by the CO:COU convention that default COU
> groups use, but I'll never be creating any groups in COmanage except
> those 3 it creates automatically for every COU (CO top-level groups
> don't seem to make it to Grouper, which is preferable anyways).

Right. I think I will prefer a solution that is less dependent on the
naming convention but I will have to put some more thought into it
first.

Thanks for the note.

Scott