RE: [saml-dev] Metadata, IdP Disco, AuthnRequest, etc...

["Scott Cantor" <cantor.2@osu.edu>]

> I'll put something together; I found the templates buried on the
> OASIS website.  Y'all prefer OOo, yes?

At the moment, yeah. Note that a formal submission has to come from OASIS
members or be contributed under a specific grant.

> Incidentally, how is the Shib 2 world doing this?  I noticed on the
> wiki that it was planned for Shib 2 to shift from the AA model to a
> push -- is it doing something else, or did I misunderstand, or... ?

What, you mean deciding what attributes to send? Today that's 99% done OOB
anyway, so nothing changes. We can also use metadata. I see few cases where
the attribute set will depend on anything more dynamic because with SSO you
really just get that one chance to create a session, so it's not like you
get different attributes per page anyway.

Where it's really useful to have is for stand-alone clients requesting
assertions, such as the ID-WSF specs include. There's no metadata for the
requesting client, typically a user, so you'd definitely find this useful, I
agree. Really in retrospect it's just something that fell off the table
while 2.0 was getting done.

> Well, the idea is that it wouldn't necessarily be ultra-useful for
> the assertion, but it would be tremendously useful for the
> AuthnRequest. 

Meaning you send your SP metadata with your request? Yeah, I can see that.

> Assuming you have a trusted third-party signer (eg,
> the federation, that which theoretically signs the metadata anyway,
> and which changes extremely infrequently),  IdPs never have to know
> anything about SPs to do basic authentication.

It's that assumption you're making about getting the metadata signed while
still hosting it piecemeal that's a bit tricky for me to accept yet.

> My big issue managing
> metadata is that there are relatively few IdPs out there, but ideally
> lots and lots of SPs -- at least in the traditional model that Shib
> 1.x attempts to solve.   The Liberty-style NameID mapping management
> is a different kettle of fish, and clearly metadata as part of the
> exchange is less useful in that model.

Yeah, but you can look at that from two ends...with fewer IdPs, there are
simply fewer boxes that need to collect up all that metadata. Most people in
fact say that the hard end is having the SPs get the IdP metadata, that's
why I was pushing back on your thoughts a little.

> Incidentally, there (Shib 1.x) is where a lot of my scars come from
> in terms of managing metadata, particularly trying to do local stuff
> where one can't just download the metadata from the federation
> because you ARE the federation.

And the problems were...?

> IMHO it's not necessarily the most comfortable thing in the world for
> an IdP to make a back-channel communication with a third-party web
> server during the process of authentication.

Not every time, but once up front and then cached?

> Maybe it's irrational, but that bothers me.  I'd rather get the metadata
for
> the requester signed by a third party, the authentication request, and the
> attribute query, all in one go, so that the transaction is simpler.
> Adding steps to the process is adding complexity.

I don't disagree that push is better than query, and I'm not arguing for
more steps instead of less, I just think some of them are more practical to
change. If I thought it was likely that a model of having signed metadata
present at all the SPs was viable, I'd be on board, but I'm not there just
yet.

> Oh, interesting.  That would clearly work for XMLSig-signed enclosing
> requests (again focusing on the IdP PoV of metadata management).  I
> hadn't really thought of putting it into the ds:KeyInfo element --
> that seems like a bit of a kludge, but so does everywhere else I'd
> considered putting it, particularly in the request (eg in
> samlp:Extensions).

KeyInfo is where WS-Security puts things like SecurityTokenReference
wrappers that are used to house assertions that get used as signing
material. So that's just the precedent.

> > I think it's turtles all the way down. I don't think you can
fundamentally
> > sidestep it. The best way, IMHO, to do the dynamic thing today is to
start
> > with the existing exchange specs, because that's also consistent with
how
> > the non-SAML world that is completely mistaken about what SAML requires
is
> > doing.
> 
> What do you mean by that?

I couldn't tell from your original note whether you were still thinking in
terms of having a third party signature or not.
 
> Also, why do what everyone else is doing if it's fundamentally broken?

A valid point. Unfortunately the evidence in front of me suggests my opinion
about the value of pulling unsigned metadata is in the minority.

> I agree with your point about trust and dynamic lookup -- you need
> the third-party signer, and without it, it's sketchy at best.  I
> always had in mind that any of the metadata exchanges would require
> signed metadata for any real purpose.  Managing a small list of third-
> party signers (ie, federations) is much easier than managing a huge
> long list of all the SPs in a large federation, and that's the world
> I'd love to live in...

I guess I still don't get it...the "list" I manage for a federated context
is the list of metadata locations and signing keys for my cron job, exactly
what you're trying to get to. The internal SPs I manage directly are because
I am the federation operator, as you said earlier.

If I had to re-sign their metadata every time it changes, that is not any
less work for me than maintaining the metadata directly like I do now. Quite
a bit more in fact.

> As far as "some people can't just post their metadata", I was being
> generous.  To be frank, "some people WON'T just post their
> metadata."  I can't necessarily force everyone to dedicate a URL
> inside their application (or near it, and having the requester
> identifier be a URL that is completely unrelated to the application
> (ie a central repository) seems to defeat the purpose).  If I can do
> anything to ease and aid adoption, I'd like to do that.

Understood.

> Authenticating with an assertion places more of a role on the trusted
> third-party issuer, but I feel more comfortable with it in terms of
> exchanging the metadata, since it has time-limits and other
> saml:Conditions on validity.  Or, metadata could sprout a
> saml:Conditions-like element, and not rely on CRLs or a complex
> matrix on the IdP of "this metadata is no longer valid when signed by
> this key..."

Metadata already has an option for validUntil, so it's about the same. The
CRL part is really your choice, I favor no PKI and just trusting the key in
the metadata, no other conditions on it.

FWIW, just to wrap this up, Shib 2.0 is also including a plugin that will
download metadata from a publishing point and cache it locally so that the
"refresh" can move from a cron job set up (or not set up) by the admin to
the software. Basically you get the advantage of real-time fetch of a
bulk-signed file with the reliability of the local copy if the file isn't
there at start up time.

> Elaborate on that, if you don't mind -- I was under the impression
> that once an assertion was baked, it was baked, and while you could
> ship it around as XML, as a base-64 blob, or what have you, it wasn't
> essentially (ie, ignoring c14n) modified.

That's my point, you can't ignore c14n, and that's what makes XMLSig hard.
If you take that out, what's hard about it, assuming no use of XPath?

You were saying "other signing methods" and I guess I assumed from that you
meant "because we hate XML Signature...".

-- Scott