COmanage Users List

[Scott Koranda <>]

Hi,

> Setting up separate provisioners for the different account types is easy
> enough. We already have separate account entries in LDAP (Active Directory,
> in our case) when a person has both student and staff accounts. Mapping
> those accounts into separate Grouper subjects is just fine.

Understood.

> We're a small university. It has been a lot easier for us to manage access
> control if we give people separate student and staff accounts, as needed.

Understood.

> I was hoping to use COUs and other groups in Comanage to provide some basic
> grouping (such as department, en) to feed into Grouper as basis groups
> before more fine-grained grouping is done for provisioning. 

That is a common deployment pattern.

> I still have to
> write the integration from our ERP and SIS systems into Comanage to provide
> that information. Would it make more sense to forgo that and write those
> integrations to target Grouper directly?

Since this is the COmanage mailing list, you will not be surprised that
I think that integrating the upstream SOR systems with COmanage Registry is 
the best approach. I think you will have flexibility with how the
Organizational Identity Source (OIS) ingests the information, how
Pipelines translate it into CO Person records, and then how the other
Registry tooling allows you to mint identifiers and the like before
provisioning into Grouper.

That being said, I usually think about the question like this: COmanage
Registry is a person registry with some group management capabilities.
Grouper is a group registry with some person registry capabilities. So
you need to decide if your primary goal/issue/task requires a person
registry or a group registry.

Depending on the particular details I have made different choices over
time.

HTH,

Scott

> 
> On Wed, Sep 29, 2021 at 1:05 PM Scott Koranda <> wrote:
> 
> > > 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
> >
> 
> 
> -- 
> Randall Smith
> Sr. Systems Administrator / Architect
> Adams State University
> http://www.adams.edu/
> 719-587-7741