[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] Metadata, IdP Disco, AuthnRequest, etc...
Hello -- On 11 May 2007, at 16:49, Scott Cantor wrote: >> 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. I'll put something together; I found the templates buried on the OASIS website. Y'all prefer OOo, yes? 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... ? >> 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? Well, the idea is that it wouldn't necessarily be ultra-useful for the assertion, but it would be tremendously useful for the AuthnRequest. 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. 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. 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. There are still pieces (in the Shib world, anyway) that would have to be managed regardless, like attribute release policies, but that's clearly not in the SAML scope. >> 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. 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. 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. >> 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. 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). >> 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. What do you mean by that? Also, why do what everyone else is doing if it's fundamentally broken? > 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. 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... 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. > 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... 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..." >> 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). Well, again, not necessarily true. Once you start trafficking in signed metadata, as long as it's signed and you can verify the signer, it doesn't matter exactly how you get it, does it? If you can fake signed metadata, well, the whole world starts to fall apart anyway. Having the federation DS return it reduces the SP complexity by a little, and begins to solve the distribution problem from that end, too. There's nothing saying the SP can't cache it and revalidate only occasionally, for performance reasons... >> 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? > 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. 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. KH -- Karsten Huneycutt Systems Specialist, ITS Identity Management kph@unc.edu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]