COmanage Developers List

[Scott Koranda <>]

> On 4/12/12 9:28 AM, Scott Koranda wrote:
> 
> >>I don't understand. How can COmanage determine who logged in
> >>if the identifier is not unique?
> 
> The 'login' column needs to be true. I think there's some sort of
> uniqueness that gets enforced somewhere, but I'd need to dig into
> the code.
> 
> >>I guess if an identifier is not used for login then it should
> >>not be included in the identifier that is put into the Grouper
> >>group.
> >>
> >>But in that case I don't know what Subject to make a member of
> >>the Group.
> 
> Minimally, we'd want your connector to be configurable so you can
> select which identifier is used to construct a Subject name, with
> some sort of reasonable default.

I see. A "plugin to a plugin" approach to map co_person_id and
a few other things into a Subject for grouper.

> 
> >It may be that the right thing to do for COmanage + Grouper in
> >general and not just for LIGO is to require that Grouper use
> >COmanage for its Subject source (note this would be a big
> >change for LIGO).
> 
> I think this is probably right. A default mode as you describe, and
> a "legacy interoperability mode" that works more like your original
> proposal.
> 
> >The configuration of how Grouper resolves Subjects (read only)
> >is flexible--you can make it do just about anything. So we can
> >simply say that for Grouper a "Subject" is the CoPerson
> >primary key. Then for the Grouper display we can use the right
> >SQL queries to get givenName, sn, email, and so on.
> 
> I'm not 100% sure we want it to be the primary key (though that is
> what my demo LDAP is doing). It'd probably be better for registry to
> manage a unique ID like the LIGO employee number, and then use that
> instead.

Sure. As long as it is unique. 

> 
> I think we should probably table this until the f2f, and in the mean
> time you just do whatever is easiest for the demo.
> 

Understood. This is a helpful dialogue though...

Scott