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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[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]