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

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

> We would really like to have the samlp:AuthnRequest include
> saml:Attribute queries as well.  I've seen this mentioned on the list
> in a positive light by TC members, so I'm sure it's not anathema to
> everyone.  Has there been any work on defining this (extremely
> trivial) extension?  If not, I could certainly put together a document.

No work done.

> Has there been any discussion of in-band metadata exchange?  That is,
> metadata about the issuer/requester included inside an assertion or
> request?

No, but that's a good idea, sort of. It solves distribution, I guess, but
not trust management. The problem with distributing metadata piecemeal is
how to rely on it. Without a third party signing it, the issues get fairly
complicated. But that's old news, it's true with the dynamic lookup model
now.

Also, since metadata is used to figure out how to talk to somebody, I don't
see how this bootstraps. If it's IdP-first, sure, you can just send it, but
an SP needs to know where the SSO service is to start with. If you can
distribute that piece of information (which is extremely security critical
for users, in light of phishing), why not the rest?

> This would be really helpful to minimize the amount of
> metadata management both IdPs and SPs have to do.  Some sites cannot
> necessarily rely on the out-of-band mechanisms defined in the
> metadata specification (ie, DNS or well-known URLs) for various
> reasons, so it'd be nice (and just as safe!) to have metadata
> exchanged as part of the communication.

All the trust issues apply equally to using URLs, but I think the
operational issues are a little different and I don't know how we'd address
those.

> In these circumstances, it might be
> desirable to sign a SAML assertion or request with a SAML assertion.

You can do that now, but you can't do it without using KeyInfo to carry the
signing assertion, as in WSS.
 
> That is, the issuer of the SAML assertion (or the requester) acquires
> a SAML assertion authenticating it in the context of the larger
> federation, and then encodes that SAML assertion into another SAML
> assertion (or request), thereby authenticating that assertion or
> request.

Yes, that's done with a HoK assertion inside the KeyInfo of the signature on
the outer one. There's no constraint on how you choose to broker your trust
model, once you get to the point of deciding if the signer is ok, you're
completely free to use anything you can put inside KeyInfo. If you can't use
KeyInfo, the only reason would be size, and you could use assertion
references.

Now, is it interoperable? I think it is in the sense of knowing what you'd
implement to do it, but in terms of anybody supporting it, probably not.

> Clearly it will be more complex than just putting the assertion or
> metadata in another assertion or request for security reasons, but
> the idea is that a given service provider or identity provider need
> not necessarily know anything about the requesting or responding
> party (prior to the transaction, that is).

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.

I don't personally think dynamic lookup "works" in the sense of
accomplishing any kind of strong basis for accepting an assertion (unless it
ends up with a third party signer), but if people think it does, the specs
are there. I don't really follow the part where you said "some people can't
just post their metadata". Why not? How would that be harder than what
you're suggesting? I'm talking solely the URL thing, not DDDS. I know why
that's hard.

And if I could get an assertion from that other party, why wouldn't I be
able to get my metadata signed? It boils down to signing a key, and you have
to do it somewhere, sometime...

> Along those same lines, why can't the IdP Discovery Service
> (optionally) return (signed) metadata about the requested IdP?

Make it a POST coming back, you mean? In part, I think it boils down to the
distribution and trust issues. If I thought there were really surmountable
in the near term for my community, I'd probably have considered it. The
other part of it is that I think the DS concept is broken by design and
can't handle the UI for the use cases that would demand that kind of
metadata exchange. Once you need that, you're likely past the point that any
single DS will work for your SP (i.e. the multi-fed problem).

> How does the IdP Discovery Service allow a SP to deal with participating
> in multiple federations simultaneously?

It doesn't, not unless you see a possible future for some global SAML verson
of X.500 to do multi-fed discovery (I know I don't ;-)

Nothing there is preventing somebody from trying it, though, people can try
whatever they think they can make work...

> Finally, has there been any discussion on methods other than XMLSig
> or the Simple Sign POST profile (essentially, anything besides public
> key signatures) for authenticating SAML assertions?

Neither requires public key, you can do HMACs.

If you mean a different syntax, not that I know of. And they do different
things, obviously, Simple Signing is a protocol message level mechanism for
the front channel, the other operates at both levels and either flow.
Nothing other than XML Signature has been proposed for assertions, and I
doubt anything could be done that would handle *general* signing, but
something could work if you didn't have to allow for all the possible
repackaging of an assertion.

HTH,
-- Scott