Grouper Developers Forum

[Peter Schober <>]

* Chris Hyzer 
<>
 [2009-09-02 06:35]:
> select group_name from shib_groups_v where sp_id = ? and 
> person_logging_in_id = ?
> 
> Then have the sp_id and person_logging_in_id (login id) dynamically
> bound, and the groups returned.  The view would see which groups the
> SP subject_id is a READER or ADMIN of the group, and the
> person_logging_in_id is a member of the group.
> 
> So in order for someone on campus to expose group information to
> their SP, they just add their SP service principal subject as a
> reader to the group, and dynamically it will work securely (no other
> SP's will see that group membership unless authorized, and no extra
> configuration is needed at the IdP).  This is for an eduperson
> entitlement.

Well, the Shib IdP does not support bind variables currently
(SIDP-290), but this impacts DB performance mostly. The other thing is
that the IdP has no knowledge of the "SP service principal subject",
unless you mean the SP's SAML entityId (which it does have access to
at that point), which is a URI (URL mostly).

One thing to consider is the direct feeding of user input to the DB --
http://xkcd.com/327/ ;) -- but I guess this isn't news for grouper.

How will variants of adding more/additional entityIds to one's own
groups (by mistake or malice) play out, depending on one's role in
those other groups? Only those with ADMIN rights on a group can
"opt-in" to release membership info to any number of SPs -- so for
users to get all their memberships released they'd be requesting group
admins to add arbitrary URLs (i.e. entityIds) as READERs (for each
group they're a[n] [effective/direct/whataver] member of)?
Do SP admins care about which group's memberships they recieve and how
would they find out about it? (Grouper admin and IdP admin could look
this up.)

> Ps. I read Shilen's post, and I think he was saying configuration is
> needed at the IdP.  Is that correct?
> https://wiki.internet2.edu/confluence/display/GrouperWG/Exposing+Groups+Through+Shibboleth

Since you're doing the "filtering" in the attribute resolver the IdP
admin would still have to create an explicit filter rule to release
/any/ resolved group info to /all/ SPs (the IdP won't release anything
unless there's a rule to do so). But "other than that" no other config
at the IdP would be needed.
I doubt any IdP admin would do this lightly.

> Pps. I also saw this thread, and it also didn't seem to answer my
> question, it seemed like you first get all, then filter that list
> for the SP.  It also seemed like it was against this type of
> approach.  :)
> 
> http://groups.google.com/group/shibboleth-users/browse_thread/thread/3b293432912f5c49

I guess the criticism concerning the conceptual mixing of the resolver
(collecting, transforming, encoding data) and the filter (applying
policy) will be the same, yes.
-peter