Shibboleth Developers

["Alistair Young" <>]

> And I think people should just stop trying to offload discovery and do it
> in
> the application where the decision can be made with the most information.
is that not against the SOA movement these days? Having a big blob of an
SP, with duplicated functionality in each one, all needing updated to keep
up with profile changes?

Yes the SP will have most of the information but the DS will have some too
and the decision will be based on rules that could change all the time.

The discovery service as a service that, given enough information, could
make a decision on a likely source of identity. e.g. the simplest piece of
information could be the IP address that the original request came from.
That would have to be metadata lookup. I wouldn't want an SP to have that
sort of metadata, to be updated across all SPs. Rather have it in the
discovery "service". A "web service". An authenticated, authorised web
service. A brick in the eFramework. It wouldn't need a ui if the SP does
this next:

If nothing came back from the service then the SP just spews out it's
metadata for IdPs and says "ok, find it yourself".

I think the "find it yourself" bit is what you say SPs should do
themselves but cutting down on the options based on info a user can
produce at the time (IP, perhaps resource uri etc.)

A semantic discovery service (SDS) would be an interesting creature.
Client from 10.192.3.2 wants to access /medicalimages/gore.jpg. hmmm says
SDS, I know that that IP block has several IdPs and that one of them is in
the Faculty of Cutting Things Up. Ontological references equate cutting
things up with medical images. "That's your best bet" it says to the SP.
SP says, is this your IdP? If yes, SP can communicate back to SDS saying
"well done" and SDS learns...

Alistair


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

>> What was the thinking behind the discovery service? other than a beefed
>> up
>> WAYF, with more metadata to manage?
>
> I explained at length last year that my design for a multi-protocol SP (I
> don't build gateways) requires that the SP be the actual request issuer,
> not
> the WAYF. That means the flow has to be SP->WAYF->SP, which is what this
> protocol does. It also divorces it from the complexity of authentication
> requests, which are extremely rich now.
>
> We could have done this the way other products do, privately, and locked
> everybody else out, but obviously people wouldn't have appreciated that
> very
> much. Not only am I publishing this, I'm doing the extra work to make it
> an
> OASIS standard.
>
> The additional endpoint in the metadata is a phishing issue. I tried to
> avoid it, but I see no way around that. It might make sense to have an
> option for those running it closely associated with specific SPs to just
> hardcode some of the checking instead of requiring metadata, but I'm not
> sure there's any difference, it's the same information.
>
> Always keep in mind...I think this is completely unnecessary. I think all
> SPs should run their own discovery UI, and the simplest one is probably
> the
> one that OpenID forces on its sites...you just enter your IdP. I would
> urge
> people to consider that instead of this approach.
>
> But that's not what people seem to want, so I'm giving them what they
> asked
> for.
>
>> 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'm not sure what you mean by more metadata. This has no particular
> implications for the volume of Shibboleth metadata apart from the
> extension,
> and that's just one more defaulted endpoint in the software.
>
> As far as filtering is concerned, I think in practice that's not likely to
> be metadata-driven. Rod's code supports it, but so far I haven't been able
> to see how it would work in most cases.
>
>> 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.
>
> Nobody seems to want to stop doing this, but no, I don't see this proposal
> as "fixing" anything like that. The centralized WAYF concept is still
> broken
> and can't be fixed.
>
> The most that this does is allow for silent redirection through many of
> them
> at once using isPassive, without having to maintain many common domains.
> Once you get back nothing from that process, you're just as stuck as you
> are
> now.
>
>> > There was particular concern about products not working
>> > with Shib sites if we do this
>>
>> How do you define "product"?
>
> Other SAML 2.0 implementations, particularly the ones we get asked about,
> which are mainly commercial and wouldn't be as likely to widely implement
> this if it wasn't published at OASIS.
>
>> > multi-protocol sites, which of course all the products have to handle.
>>
>> can you explain what you mean by this?
>
> SAML products all support SAML 1.x and SAML 2.0, and usually ADFS to boot.
> In the future that may also include Cardspace. That's 4 protocols and
> probably 12+ bindings to handle at once, most all of them based on knowing
> who the IdP is before you can issue a request properly (Cardspace is the
> exception of course).
>
>> 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".
>
> As Ian said, the SP has nothing to do with this. The DS is talking with
> the
> user, it has the same address the SP does. (Ignoring NAT, but NAT breaks a
> lot of things.)
>
> This is not a protocol between the SP and the DS alone. The browser is
> still
> in the middle.
>
>> Once past the initial metadata check, the more the sp can give the
>> service
>> to allow it to make a passive decision the better?
>
> Yes, and that also makes the whole thing more complex. There is a balance
> here.
>
>> 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.
>
> And I think people should just stop trying to offload discovery and do it
> in
> the application where the decision can be made with the most information.
>
> -- Scott
>
>
>