COmanage Developers List

[Scott Koranda <>]

> > On 4/12/12 8:11 AM, Scott Koranda wrote:
> > 
> > >I propose that I do the following:
> > >
> > >- use the co_person_id to find all org_identity_id via the
> > >   co_org_identity_links table that the CoPerson might have
> > >
> > >- use the org_identity_id to find all identifiers associated
> > >   with the org_identity_id
> > >
> > >- also use the co_person_id to find all identifiers that might
> > >   be associated with CoPerson directly
> > 
> > I think we may need to discuss this further. 
> 
> Yes.
> 
> > My initial reaction is
> > that org identity data shouldn't be exported by the registry, but I
> > may not be understanding Grouper's needs 
> 
> Grouper needs a source of Subjects. People use either a
> relational database or LDAP and point at a particular column
> or attribute as uniquely identifying that Subject.
> 
> LIGO uses LDAP and the krbPrincipalName as the unique
> attribute.
> 
> Subjects are members of Groups.
> 
> > and how we should be
> > modeling this data.
> 
> It may be less about Grouper's needs then about the VOs needs.
> 
> If I am using the COmanage interface to add 'Scott Koranda' to
> the group 'wiki editors' for the CO 'LIGO collaborators' then
> what I expect at the end of the day is that in LDAP I find
> 
> employeeNumber=882,ou=people,dc=ligo,dc=org
> uid: scott.koranda
> krbPrincipalName: 
> 
>  
> isMemberOf: cn=wiki editors, ou=LIGO collaborators,ou=grouper,dc=ligo,dc=org
> 
> This should happen via
> 
> COmanage -> Grouper -> PSP -> LDAP
> 
> In order for that to happen COmanage has to put the Subject
> ''
>  into the Group 'LIGO
> collaborators:wiki editors' (here 'Subject' and 'Group' are
> the Grouper terms).
> 
> ''
>  is the 'Subject', which is usually an
> organizational identifier.
> 
> Putting some other tag into the Group will not result in what
> is needed in LDAP. It needs to be what Grouper is using as the
> 'Subject'.
> 
> > 
> > >- make sure the list of identifiers does not contain
> > >   duplicates, and then add those identifiers to the
> > >   represenative Grouper group (and attach the co_group_id,
> > >   co_person_id, member, and owner attributes to each of those
> > >   memberships)
> > 
> > There are currently no uniqueness constraints in the datamodel for
> > identifier, although I vaguely remember that some controller
> > somewhere may enforce some constraint. Even then, it's possible for
> > two different people to have the same identifier -- but of different
> > identifier type -- so you may want to consider that as well.
> 
> I don't understand. How can COmanage determine who logged in
> if the identifier is not unique?
> 
> 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.
> 
> Scott
> 

(Just thinking out loud here...)

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

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.

Then something (PSP?) does COmanage -> LDAP provisioning in
order to populate the ou=people,dc=ligo,dc=org part of LDAP
and PSP does Grouper -> LDAP provisioning to populate the
ou=grouper,dc=ligo,dc=org part of LDAP.

Hmmmmm....

Scott