Grouper Users - Open Discussion List

[Chris Hyzer <>]

Ø  When you say "…clients which can speak attributes…" you're really talking just about the grouper client, right? 

 

Well, I mean WS.  Could be the grouper client.

 

Ø  I guess another way of asking this is, how are attributes handled by the PSP, if at all, when provisioning to LDAP?

 

I think you can provision attributes to LDAP, though it takes some work, not sure how many examples of this there are

 

Thanks,

Chris

 

 

From: Earl Lewis [mailto:]
Sent: Friday, August 23, 2013 12:40 PM
To: Chris Hyzer;
Subject: Re: Traditional one-many relationships in Grouper

 

Chris,

 

When you say "…clients which can speak attributes…" you're really talking just about the grouper client, right? 

 

I guess another way of asking this is, how are attributes handled by the PSP, if at all, when provisioning to LDAP?

 

Earl

801-581-3635 (office)

801-554-3596 (mobile)

 

On 8/22/13 1:00 PM, "Chris Hyzer" <> wrote:

 

If you have clients which can speak attributes, that it probably the best design.  If you have clients that have to do LDAP or something without attributes, using groups might be best…

 

From: Earl Lewis []
Sent: Thursday, August 22, 2013 1:59 PM
To: Chris Hyzer;
Subject: Re: Traditional one-many relationships in Grouper

 

Chris, 

 

Thanks very much for your thoughts and suggestions. I thought about the admins group for each exec but that sounded like overkill. Not sure which one of these will be easiest to setup/maintain so I'll give them both a shot and see what seems to work best. In all likelihood I'll be back with a few questions before I'm gonna be able to get this setup/working. ;) Thanks again.

 

Earl

801-581-3635 (office)

801-554-3596 (mobile)

 

On 8/22/13 8:58 AM, "Chris Hyzer" <> wrote:

 

Ive been thinking about this to keep track of supervisors at penn…

 

Two things off the top of my head are:

 

1.      The new attribute framework

 

If you have an exec named John Smith (jsmith), and they have an administrator Kevin Johnson (kjohnson).  Then you could have a group:

 

school:community:execs:execs and jsmith is a member, and there is an attribute on that membership: administrativeSupport, which has a value type of subjectIds (multi-assign, single valued), and one of the subject ids is kjohnson

 

2.      Group for each exec

 

If you have an exec named John Smith (jsmith), and they have an administrator Kevin Johnson (kjohnson).  Then you could have a group:

 

school:community:execs:execs and jsmith is a member, and you could have a folder:

 

school:community:execs:execAdministrativeSupport

 

which has groups for each exec

 

school:community:execs:execAdministrativeSupport:adminsFor_jsmith   which has member: kjohnson

 

Then you could rollup all of those groups (maybe with a rule) to get a group of all exec admin staff.  If you did a query for who is in what group in that folder, you could look at the group name, and see which exec the person is an admin of, etc

 

Thanks,

Chri

 

 

 

 

From: [] On Behalf Of Earl Lewis
Sent: Thursday, August 22, 2013 10:48 AM
To:
Subject: [grouper-users] Traditional one-many relationships in Grouper

 

Does anyone know of a way to represent traditional one-to-many relationships between people, within a group, in Grouper?

The use-case is this. We would like to have a group for all of our executives across campus. We would like to include those execs administrative support staff. Most of the time this is a one exec <-> one admin relationship, and sometimes it's one exec <->> many admins.

As far as I can tell Grouper isn't really designed to handle relationships between people within a group, except to say that they are members of the same group. Can anyone shed any light on this type of use-case in Grouper?

Earl