Research and Scholarship and filter by relying party
Jeffrey Crawford
jeffreyc at ucsc.edu
Wed Mar 5 18:32:55 EST 2014
On Tue, Mar 4, 2014 at 1:39 PM, Tom Scavo <trscavo at gmail.com> wrote:
> On Tue, Mar 4, 2014 at 4:18 PM, Jeffrey Crawford <jeffreyc at ucsc.edu>
> wrote:
> >
> > On Tue, Mar 4, 2014 at 11:47 AM, Tom Scavo <trscavo at gmail.com> wrote:
> >>
> >> Current wisdom is that the
> >> SP should be able to handle the lack of attributes:
> >>
> >> https://spaces.internet2.edu/x/m42KAQ
> >> https://spaces.internet2.edu/x/xa6KAQ
> >
> > Well okay so if an SP doesn't even get NamedID it's supposed to handle
> that?
>
> Yes, but why can't you release Transient or Persistent NameIDs by
> default? There's no privacy leakage there.
>
This particular case is more of a support issue than being concerned about
releasing attributes. By listing relying parties we get errors for
unsupported apps, as opposed to what look like valid logins. Lot of history
behind that at this institution.
>
> > there are various reasons for controlling what our IdP allows logins to,
> the
> > simplicity of simply saying that we don't support an SP unless it's
> > authorized covers most if not all those reasons.
>
> Seems like you're talking about campus policy (which is fine of
> course, campuses can do anything they like) but in a cross-domain
> scenario, authorization is not the IdP's responsibility. Your job is
> to authenticate the user and provide attributes (or not, subject to
> policy). The SP decides what to do next.
>
> (Sorry, you asked about an InCommon use case, so I'm giving an
> InCommon perspective.)
>
Understood and perhaps it should be looked at again but this all started
because of the policies of how we utilize Shibboleth and InCommon. We like
the idea of RandS and want to support it, now it's a question about how to
best do that with the existing self imposed restrictions.
>
> Tom
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140305/f11c7a41/attachment-0001.html
More information about the users
mailing list