COmanage Developers List

[Benn Oshrin <>]

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.

> 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.

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

-Benn-