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