Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] cookbook for protecting Grouper UI using Shibboleth

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] cookbook for protecting Grouper UI using Shibboleth

Chronological Thread 
  • From: Rob Gorrell <>
  • To: David Langenberg <>
  • Cc:
  • Subject: Re: [grouper-users] cookbook for protecting Grouper UI using Shibboleth
  • Date: Fri, 10 May 2013 10:27:23 -0400
  • Authentication-results:; dkim=neutral (message not signed) header.i=none

No, i'm not using InCommon metadata. I've done a direct peering (no federation) with my development IdP by copying over metadata and using file backed metadata. So, is the correct EntityID for my IdP. But you are right, what grouper is showing me in the error message comes from the persistent-id attribute, which seems to be the only attribute my SP is passing through. I've confirmed on my IdP that I'm pretty confident I'm sending eppn, but have no idea why its not winding up on my Grouper SP. i've got eppn defined as I think it should be in attribute-map and shibboleth2. I'm at a loss for why my SP isn't passing it along in the shibb session and ultimately to grouper.

    <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    <Attribute name="urn:oid:" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>

    <ApplicationDefaults id="default" policyId="default"
                         REMOTE_USER="eppn persistent-id targeted-id"
                         signing="false" encryption="false">


On Thu, May 9, 2013 at 4:36 PM, David Langenberg <> wrote:
I'd check your metadata.  Is your Grouper install using the InCommon
metadata for your IdP?  According to that error message your IdP is
claiming it's EntityID is rather than  That'd lead me to suspect that it's also sending the
wrong scope.  ePPN is a scoped attribute and if the scope your IdP is
sending is not the one the SP is expecting, then the SP will drop it.


At 2013., in <>,
        "Rob Gorrell" <> wrote:
>    David,
>    I think you are right... I checked my IdP's attribute-filter and files,
>    I'm releasing eppn.
>    I checked my grouper SP, and its attribute-map has a definition for
>    urn:mace:dir:attribute-def:eduPersonPrincipalName
>    and I checked my shibboleth2.xml and i have REMOTE_USER="eppn
>    persistent-id targeted-id"
>    but, looking my shibd logs on the grouper SP, I see:
>    2013-05-09 16:03:05 WARN Shibboleth.AttributeFilter [1]: removed value at
>    position (0) of attribute (eppn) from
>    (
>    2013-05-09 16:03:05 WARN Shibboleth.AttributeFilter [1]: no values left,
>    removing attribute (eppn) from (
>    This means my SP is dropping eppn, correct? Can you offer any wisdom, my
>    skills on the SP side of the house are rather week, we are mostly an IdP
>    here and don't currently run any SP's though I'm trying to become more
>    familar with the SP concepts.
>    Thanks,
>    -Rob
>    On Thu, May 9, 2013 at 3:54 PM, David Langenberg <>
>    wrote:
>      Hi Rob,
>      Looking at it, it seems your IdP has not released ePPN to your SP.  That
>      looks more like an eduPersonTargetedId.  I'd first take a look at your
>      attribute-filter.xml on the IdP to ensure your Grouper SP is getting the
>      necessary attributes.  Then ensure that your attribute-map.xml in the
>      Grouper SP is setup to properly map them.  Finally be sure that in the
>      Grouper SP shibboleth2.xml you define remote_user to include the correct
>      attribute.
>      In our install here, we send UID from the IdP and map that to
>      REMOTE_USER in the SP.
>      As for grouper-shib.jar in maven.  What that does is provide a way to
>      plug grouper into the Shibboleth IdP Attribute Resolver.  It's used
>      primarily by the Grouper PSP (and can be used by the Shib IdP).
>      Dave
>      At 2013., in
>      <CAOE6Pzz9Xaoggz42y6z4LzthOF2x5P=>,
>              "Rob Gorrell" <> wrote:
>      >    I was wondering if there were any good soup-to-nuts references for
>      the
>      >    novice Grouper user in controlling Grouper UI authentication using
>      >    Shibboleth? I'm working on a first time Grouper deployment and was
>      >    interested with the notion of using shibb as the authentication
>      mechanism
>      >    to the UI. I had hoped the path would be a little more
>      straightforward
>      >    with where these two products come from, but then again, Grouper
>      (and even
>      >    shibb) are still pretty new to me.
>      >
>      >    I found the Newcastle wiki material
>      >
>       (
>      >    as well as the notes in the Grouper Hosted on a Cloud
>      >
>       (
>      >    about using shibb with grouper and with this, have been successful
>      in
>      >    setting up an SP that is protecting my Group UI instance,
>      redirecting me
>      >    to my IdP, authenticating me and dumping me back at the Grouper UI
>      with an
>      >    established shibb session, but then Grouper UI is telling me
>      "Error: Cant
>      >    find login subject
>      >
>      >    ADMIN_UI".
>      >
>      >    What I seem to be missing (and doesn't seem explained in the
>      Newcastle
>      >    article) is how to map the shibb eppn + attributes into the Grouper
>      >    $REMOTE_USER so that shibb user is identified and matched to a
>      grouper
>      >    subject? I also was stumbling across some information about
>      >    grouper-shib.jar over at Maven... is that possibly where this
>      component
>      >    comes into play?
>      >
>      >    I was hoping someone might be able to give me a conceptual high
>      level
>      >    direction of whats involved in shibbolizing the UI geared at those
>      that
>      >    aren't experts in either grouper or shibboleth... or is this road
>      I've
>      >    embarked down not for the faint of heart?
>      >
>      >    Thanks,
>      >    -Rob
>      >
>      >    --
>      >    Robert W. Gorrell
>      >    Middleware Engineer, Identity and Access Management
>      >    University of NC at Greensboro
>      >    336-334-5954
>      [End of excerpt from
>      <CAOE6Pzz9Xaoggz42y6z4LzthOF2x5P=>]
>      --
>      David Langenberg
>      Identity & Access Management
>      The University of Chicago
>    --
>    Robert W. Gorrell
>    Middleware Engineer, Identity and Access Management
>    University of NC at Greensboro
>    336-334-5954
[End of excerpt from <>]

David Langenberg
Identity & Access Management
The University of Chicago

Robert W. Gorrell
Middleware Engineer, Identity and Access Management
University of NC at Greensboro

Archive powered by MHonArc 2.6.16.

Top of Page