Grouper Developers Forum

["Michael A. Grady" <>]

In the past I've had the thought that, as federated apps "catch on",  
and thus the number of ARPs an IdP admin would need to manage grew,  
that managing the ARPs in some way in something like Grouper might  
make sense. And my concern about who has the right to release what  
would seem to apply more with external partners than internal ones. I  
could imagine that with proper naming constraints, both in the names  
of groups and the entityIds of the SPs, that one could potentially do  
this. Generate the ARPs (at least some of them) from Grouper, and in  
that generation one could apply business rules such as the Group name  
prefix has to match a level of the entityId or some such, which could  
basically translate into your desire for someone to able to release  
the group memberships for groups they manage to their own apps/ 
services (i.e. their own SPs).


On Sep 3, 2009, at 9:38 PM, Chris Hyzer wrote:

> Thank you everyone for your interest in this discussion, and excuse  
> my Shib ignorance.
>
> Let me frame this topic a little better.
>
> Again, we would like the IdP administrator not to have to make  
> changes for each SP who needs a different group released (as  
> attribute or entitlement), and we would like that group not to be  
> released to all SP's, only the one(s) who need it.
>
> I picture the people who would want to expose memberships are  
> application developers/integrators, who are building applications,  
> integrating with shib as an SP, and creating/admining some groups  
> (used as roles) for the application.  I had hoped they could expose  
> their group information to their own SP, and it is safe and private.
>
> But, since this doesn't seem convenient to do in Shib, we are going  
> down a path that was criticized at the educause CAMP where group- 
> admins in grouper can mark groups as shib-enabled or not.  If shib- 
> enabled, then all penn-internal SP's will see the membership.  We  
> will not have a way to mark a group as shib enabled for non-Penn SP's.
>
> It just seems that with this, SP admins might decide that using  
> Shib is easier that using shib and figuring out how to be a grouper  
> ldap or web service client, and might make a group public when it  
> shouldn't be (for convenience sake).  Though our documentation will  
> say that exposing groups in Shib is only for membership data which  
> is not sensitive.
>
> I had thought putting memberships in shib attributes/entitlements  
> would make things easier for application developers, and could be  
> done securely, and without central administrative work, but maybe  
> they shouldn't be used the way I had hoped.
>
> If anyone wants to discuss this offline at the member meeting in  
> San Antonio, I would be interested.
>
> Thanks,
> Chris
>
> > -----Original Message-----
> > From: Michael A. Grady 
> > [mailto:]
> > Sent: Thursday, September 03, 2009 9:04 PM
> > To: Grouper Dev
> > Subject: Re: [grouper-dev] secure Shibboleth - Grouper integration
> >
> > It seems to me that this also raises some interesting questions about
> > the *right* to release a group membership. If I create and maintain a
> > group in which membership implies a person is a student, do I and the
> > person running the IdP have the right to release that group
> > membership without checking with the authoritative source for all
> > things "student"  -- the Registrar? Managing group memberships can
> > delegate the management of who has what entitlement, but I don't see
> > that it helps much with the management of the ARPs within the IdP --
> > that would still take explicitly deciding to release a specific value
> > (or set of values) to a specific service, and getting any and all
> > necessary approvals ahead of time.
> >
> > Of course, the "easy solution" to that will be user consent for
> > everything.  :-)
> >
> >
> > On Sep 3, 2009, at 1:40 PM, Brendan Bellina wrote:
> >
> > > One of the issues to bear in mind in either case though is that a
> > > person may be a member of groups that have nothing to do with the
> > > application and should possibly not be shared with the
> > > application.  So you will need a way to restrict which values are
> > > returned.  ARP's can do that but how you name your groups or
> > > populate your entitlements will have a bearing.
> > >
> > > We populate both entitlement and the eduCourse attributes.
> > >
> > > Regards,
> > >
> > > Brendan Bellina
> > > Univ of Southern California
> > >
> > > On Sep 3, 2009, at 8:49 AM, RL 'Bob' Morgan wrote:
> > >
> > > > > > I don't know, but I will ask our Shib people.  Quick question
> > > > > > though, does that make what Im talking about easier?  :)
> > > > > > Do you know some of the pros cons?
> > > > > > Thanks!
> > > > > > Chris
> > > > >
> > > > > No, doesn't make your job easier.
> > > >
> > > > It probably doesn't make the access control job easier but I
> > > > definitely think it can make the overall job easier.  In my
> > > > experience entitlements have to be created and supported one by
> > > > one by IdP staff, including deciding on the value and mapping it
> > > > to some way of determining membership.  By contrast, the whole
> > > > point of a groups service like Grouper is that creation and
> > > > maintenance of groups can be delegated to the people who are close
> > > > to them.  So if groups have a standard expression as Shib
> > > > attributes, a group can be defined and consumed by an app with no
> > > > IdM-team involvement at all, which seems like a big win to me.
> > > >
> > > > > My implicit question was, "Is it worthwhile to try to get to a
> > > > > situation where there's a 'predominent community practice' on the
> > > > > attribute expected by both IdPs and SP/RPs to carry group
> > > > > membership information?" I imagine opinions vary.
> > > >
> > > > I suppose they do.  I think it's unfortunate that the entitlement
> > > > notion has impeded us from what seems to be a clear win in having
> > > > a standard group attribute practice.
> > > >
> > > > - RL "Bob"
> >
> >
> > --
> > Michael A. Grady
> > Executive Program Officer for Cyberinfrastructure
> > Office of the CIO, University of Illinois at Urbana-Champaign
> > 2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801
> > 217.244.1253 phone, 217.244.4780 fax


--
Michael A. Grady
Executive Program Officer for Cyberinfrastructure
Office of the CIO, University of Illinois at Urbana-Champaign
2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801
217.244.1253 phone, 217.244.4780 fax