OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] How does Shib WAYF work? (was: Re: [security-services] IdP Discovery)


> 0. A WAYF is a distinct service and implementation thereof 
> that is run on some network node. (yes?)

What it actually is today, formally, is a request proxy. It takes a Shib
AuthnRequest (a very simple GET) and forwards the redirect along to the
chosen IdP. Once the SP sends the browser off, the WAYF is in control. It
can prompt, lookup a cookie, guess, whatever it wants.

As Bob said, it doesn't have to be a different node. When it is a separate
node, you hit the major problem with the old WAYF design, it traps the user
at a single federation's WAYF. That's the reason we're working on a wire
protocol to route back to the SP, so an SP can passively probe many
federations or if the user needs to say "forget it", they can do so.

Can the CDC do this? Sure. By maintaining hundreds of DNS entries and
dedicated vhosts per federation. Not gonna happen.

> 1. So each SP that is Shib-enabled is configured with one or 
> more WAYFs to use?

As a last resort, yes.

> 2. The only info the WAYF gets from an SP, at time of redirecting a UA to
> the WAYF, is the SP's entityID, yes? Is the Shib notion of an 
> entityID congruent with SAMLv2's ProviderID?

It's the same, but if you check, you'll see that SAML actually calls this
entityID. ID-FF used both terms, SAML primarily sticks with entityID.
Shibboleth uses providerId a lot today, and we're changing that, but our
SAML 1.x model is 2.0-flavored, as in the area of uniquely naming everybody
like ID-FF did.

> 3. My understanding of Shib's conventions are that individual users are
> not supposed to have to manually type in anything wrt identifying 
> their IDP.

I would say rather that we don't see that as the most attractive model.
Different people have different opinions about it, and enough of them don't
like that model to influence the direction we're taking. We didn't consider
it very likely to work initially, no.

> 4. The Shib WAYF isn't necessarily wedded to SAML profiles as the
> subsequent SSO protocol vehicle, yes?

Today it is completely wedded to the Shibboleth 1.x "request" protocol,
which we grafted on to SAML 1.1. It really doesn't know anything about the
SAML SSO profiles at all. In the future, it will be totally agnostic, yes,
just a protocol unto itself.

> It's interesting to compare the Shib WAYF to Yadis -- both do IDP 
> discovery/introduction, and both supply IDP metadata to the SP.

As Bob said, this is something the WAYF does not do. We separate these two
functions, which IMHO is the right approach.

> D1. Yadis isn't a distinct service (WAYF is), rather it's a methodology
> for an SP to dereference a user-supplied identifier and obtain a 
> pointer to an IDP and metadata thereof.

I would put it entirely in the metadata exchange and format bucket, it seems
to me. Discovery is being ignored, IMHO.

> D2. In Yadis the user (or his browser ;) is responsible for supplying the 
> user's (IDP) ID that is subject to the dereferencing, and SPs are
> responsible for prompting for this, and performing subsequent
> dereferncing.

Yes, which I term "ignoring the problem".

> Any other salient differences?

I think they're basically two very different things. The WAYF is an idea
that does basically something similar to the CDC profile, and in the future
will be more like it.

Yadis seems a direct alternative to the SAML metadata schema and metadata
lookup/resolution, which is perfectly reasonable since that part of SAML is
highly tactical in nature. It does what was needed to make SAML more
deployable but doesn't preclude new work in that space, nor does anything in
SAML depend on it in a tightly coupled way.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]