Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] secure Shibboleth - Grouper integration

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] secure Shibboleth - Grouper integration

Chronological Thread 
  • From: Keith Hazelton <>
  • To: Chris Hyzer <>, 'Shibboleth Users' <>,
  • Subject: Re: [grouper-dev] secure Shibboleth - Grouper integration
  • Date: Thu, 03 Sep 2009 10:20:59 -0500

On Sep 3, 2009, at 07:44, Chris Hyzer 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?


No, doesn't make your job easier. 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.


-----Original Message-----
From: Keith Hazelton
Sent: Wednesday, September 02, 2009 1:45 PM
To: Chris Hyzer

Subject: Re: [grouper-dev] secure Shibboleth - Grouper integration


Another issue: Have you considered and rejected the idea of
expressing group memberships via the "isMemberOf" attribute rather
than via ePEntitlement?

Basic edu* spec for groups:

Shib details:

Regards, --Keith
On Sep 1, 2009, at 23:35, Chris Hyzer wrote:


Maybe this is a topic for a shib list, but I am just curious if
anyone on this list knows the answer.

We have talked about securely exposing membership information from
Shib IdP to SP, and I am wondering if it is possible to do this

Ie. at some point in the Shib workflow, have a (custom?) plugin run
a query against a Grouper SQL interface (since our LDAP/WS cant do
this) which says:

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.

Anyways, is this possible/desirable in shibboleth? If so can
someone tell me how to accomplish this? Am I on the wrong list?


Ps. I read Shilen's post, and I think he was saying configuration
is needed at the IdP. Is that correct?

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

Archive powered by MHonArc 2.6.16.

Top of Page