preventing attribute release for a class of users

[Cantor, Scott]

On 9/15/11 9:28 AM, "Liam Hoekenga" <liamr at umich.edu> wrote:

>Here's my situation.  Our shib installation uses our campus SSO for
>authentication.  Our campus sso has a guest account system.  We don't
>want our guests getting out into the wild appearing to InCommon SPs as
>"real" UMich users.

Then don't assert member@

You aren't under any obligation to do more than that.

>Our current solution is disallow guest access to the IdP.

I see no reason for that.

>Enter some new campus SP, that want to use Shib, but have a need /
>desire to allow both real and guest users, and are adamant that their
>users don't know that they're being logged in through shib.  So.. they
>won't update their landing page to have different login links for
>"Uniqnames" vs "Friends", and don't want to be directed to a WAYF (or
>DS acting as a WAYF) because it would destroy the illusion.

Leaving the guest point aside, allowing that kind of misguided nonsense
will always come back to bite you.

>My boss's proposed solution was to bring up a separate IdP for our
>local federation, separating the InC aware IdP from the local fed, and
>the local IdP from InC.  That's a second installation we'd need to
>maintain, and I'd rather not do it unless it's necessary.

I don't blame you.

>My idea - our SSO identifies the guest accounts via an environment
>variable in the server's environment.  If I pass that to tomcat, could
>I base an attribute on that, and use that to prevent any attribute
>assertion for guest accounts outside of our local federation?  (maybe
>using AttributeRequesterInEntityGroup?)

So your goal is in fact just to make sure you don't assert the wrong
attributes? What other attribute but affiliation (and things based on it)
would you be concerned about?

-- Scott