[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 14 May 2007, at 14:53, Scott Cantor wrote: >> 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. Yep. UNC Chapel Hill is an institutional member, so I joined on up (both OASIS and the SSTC). I'll post the doc when I get it done, probably today or tomorrow. > 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. I can see that having the SPs get the IdP metadata is hard, too, and I never meant to imply it was easy; I do think the IdP disco service, even as flawed as we both agree that it is, could help immensely by returning the (signed) metadata if asked to do so. I think the redirect-with-identifier behavior should be preserved, too, but it's not much additional complexity to have a flag indicating "post me the signed metadata, please", and I think it's well worth it. SP reliance on that is probably not ideal, but in the absence of a better discovery mechanism... >> 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? Less scary, but you'd have to do it every once in a while just to verify that it hasn't changed, or at the very least re-retrieve after the valid-until or cache-duration ran out, so it's intermittent discomfort vs constant. Plus you still have to get it signed, and that poses problems for SPs and IdPs in a multiple-federation environment -- presumably you want the same entityId on a given provider for all federations, but each federation will have its own signing cert, so ... > 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. Even with the existing distribution schemes, except for the batch load, you've got the problem of getting it signed piecemeal and putting it on each SP. Getting each metadata stanza signed is really a matter of federation procedure, I think. You join the federation, send them some things including your signing key and contacts and URLs and everything, and the federation sends you back a signed blob of metadata. You have to get the metadata re-signed occasionally, but if the metadata has the cert embedded in it in the first place, you have to do that anyway -- the federation maintainer still has to update the global metadata file and then re-sign it. Instead of updating one big file, it's just as easy to update one small file. And, there could be a few tools to make it easier on the federation owners. > 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. Batch downloads solve the problem, but rely on batch processes. Shib 2 can still do its preferred thing (including an automated incorporated batch process so that an admin doesn't have to think about it), and someone else can do the piecemeal in-band exchange with another product, and maybe the batch download can be a reasonable backup or bootstrap or something. I'm just arguing for flexibility in the protocol to allow metadata to be more dynamically distributed. Use it, don't use it, it doesn't matter, as long as your fellow federation members can follow along (a matter of federation policy, I'd think, or maybe a metadata flag). As far as nitty gritty details, I think saml:Advice is obviously the way it would go for assertions (not saying it's overly useful, but there for completeness); a samlp schema modification at the level necessary to do this (ie, a modification to the samlp:RequestAbstractType) would probably be less-than-good, so samlp:Extensions for the request. Thoughts on that? > 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. Right, local deployments are different, and the way I think that can be made easier doesn't need attention by the SSTC. True federations *do* have to sign metadata every time it changes, whether it be one large file pushed out to everyone, one small file pushed out to the entity in question, or both. > 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. Duh. Of course it does. And a cacheDuration to help with the caching. I don't know why I didn't see it in the schema and in the document. Nevermind on that, then. :) Also, the discussion about XML Signature forced me to go back and re- read the specification, which was immensely helpful for me; I had forgotten a bunch of the finer points of the spec. So, nevermind on that tangent, too. 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]