Shibboleth Developers

["Alistair Young" <>]

> The ones I can think of are support for multiple authentication request
> and response profiles at the same SP (even non-SAML ones), and support
> for encrypted and signed authentication requests.
ok. I just get confused now and again as this is a "shibboleth" list!
I have to keep reminding myself that shibboleth means a lot of things
these days ;)

> local to an SP or group of SPs
ok, I see. SPs are obviously going to know what IdPs you're likely to be
coming from. according to their metadata. If your institution doesn't have
an agreement with an SP, you won't see your IdP at all.

So instead of the SP sending you off to the WAYF to pick from thousands of
IdPs, it instead says "here's the reduced list of IdPs I talk to, which
one are you from?". A pool of IdPs if you like.

Can we have support for clearing your selection? For users who have
multiple IdPs for the same SP and consequently different levels of access
to resources.

thanks,

Alistair


-- 
mov eax,1
mov ebx,0
int 80h

> Alistair Young wrote:
>
>> What was the thinking behind the discovery service?
>
> The ones I can think of are support for multiple authentication request
> and response profiles at the same SP (even non-SAML ones), and support
> for encrypted and signed authentication requests.
>
>> Presumably the initial contact with the
>> service will be the same as the WAYF? You still have to work your way
>> through the hundreds/thousands of Identity Providers in a federation. I
>> can see how metadata can cut that down, using the SP's entityID but it
>> means even more metadata for a federation to manage.
>
> I think you're confusing the discovery service as an abstract thing
> associated with a protocol, with the user interface that service might
> present.  There's no reason a discovery service needs to look like a
> present-day WAYF, particularly if it is local to an SP or group of SPs.
>
>> Do you think the discovery service should use the same metadata file
>> that
>> drives the federation? So it would be one discovery service per
>> federation.
>
> That doesn't follow.  It makes a lot of sense to deploy something
> following the new discovery profile local to a particular SP rather than
> centrally.  That was true for the old discovery profile too, of course.
>
> For the record, the UK Federation runs multiple WAYF configurations
> already from the one set of federation metadata: one "everything and the
> kitchen sink" configuration and a reduced version with test IdPs left
> out for everyday use.  Just because a federation provides you with
> metadata doesn't mean you need to present all of it.
>
>> I've seen a lot of talk of IP address matching at WAYFs. Is this a
>> viable
>> addition to the discovery service? i.e. if you're on campus, the
>> discovery
>> service can be passive if the sp knows your IP address. i.e. SP tries a
>> passive query to the service and if nothing comes back it says to the
>> user
>> "no idea, go find it yourself".
>
> Again, this is independent to the discovery service protocol; we've
> thought about doing things like this in the context of the existing WAYF
> code.  Rod has a proof-of-concept implementation that allows IP address
> ranges to be used as one selection heuristic among perhaps many.
>
> I think we're in a good position in the UK to take advantage of some
> heuristics like this because address space within education is mostly
> allocated through UKERNA.  It can only ever be a heuristic, though.
>
>> I can see semantic type decisions coming into play. i.e. SP tells the
>> service "I'm a medical records service and someone from uhi.ac.uk is
>> trying to access me. Where is their IdP likely to be?". A semantic
>> discovery service? It could drastically reduce the likely list of IdPs
>> from thousands to a handful. Given enough data it could match it. But
>> the
>> metadata doesn't support that just now. Maybe it should in future.
>
> It's technically possible, but I think it is unlikely that large
> federations would want to take on the job of administering selection
> metadata on behalf of SPs.  If your SP wants that level of choice over
> who gets presented and who doesn't, you should just deploy your own
> discovery service; you'll give your users a much better experience than
> any central service can ever hope to.
>
>       -- Ian
>