COmanage Users List

[Scott Koranda <>]

> You can add types via "Extended Types" in the CO Configuration.
> 
> In terms of Grouper, others might be better able to chime in on the Grouper
> side, but it sounds like what you're trying to do is map a single CO Person
> to multiple Grouper subjects. The immediate question would be how to
> populate a Grouper subject source in a way that would permit this.
> 
> While we typically see LDAP as the Grouper subject source, I'm not sure this
> would be the best option. AIUI, you would need to provision two LDAP records
> for the same CO Person, one with each uid. Although technically possible
> (probably using two LdapProvisioners, one with a Provisioning Group
> associated with a CO Group holding the students, and another associated with
> a CO Group holding the staff), I don't think we've seen anyone do that, and
> it might be more trouble than it's worth.
> 
> Another option could be to use the SqlProvisioner, and then build a view on
> top of the provisioned tables that generates one row per uid using
> appropriate JOINs.
> 
> We could also consider an RFE to the GrouperProvisioner if we could figure
> out what exactly the enhancement would be.

The GrouperProvisioner has a configuration option to specify which
COmanage Registry Identifier should be used to label the user when it
invokes the Grouper web service (WS) call. As a deployer you need to
coordinate that Identifier with your Grouper subject source.

For example, if you provision CO Person records to LDAP and put the UID
Identifier value into the LDAP uid attribute, then you would want to
configure a Grouper subject source that reads from LDAP and uses uid as
the primary key, and also configure your GrouperProvisioner to use UID
when it invokes WS calls.

The same idea can work with SQL.

If you want a single CO Person record with two Identifier values to be
treated as two different subjects in Grouper then as Benn notes, you
basically need two different LDAP records or two different rows in an
SQL table so that the Grouper subject source sees them as two distinct
subjects. Then you could probably play the same trick with the
GrouperProvisioner that Benn mentions for the LDAP Provisioner (two
different provisioning groups configured for the two different
provisioner configurations).

Again, we have not seen it done.

I think an enhancement to the GrouperProvisioner could be functionality
so that it chooses which Identifier value to use when invoking Grouper
WS calls based on something like CO Group membership?

Just a quick thought...

Scott