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...


> 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...

Well, I think in terms of our needs as an implementer, we wanted a spec to
write to that would be stable in time for us to ship, and we were asked to
offer it to the TC. I would suggest that we consider this as a follow on. It
may be possible through the policy extension point in the profile or it may
require formally altering it, perhaps something you could look at.

(But you're also welcome to join a call and argue for getting it in now, I
just don't personally have that on my agenda as the original co-submitter.)

> 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 ...

Yes, but that's why it's hard to split it all up. Who signs it? In the batch
approach, each federation can just collect up what it signs and there's no
ambiguity about the signer.
 
> 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.

Maybe I wasn't clear...I actually don't think piecemeal works well in
conjunction with signing. Until there's some kind of explicit service that
can be leveraged to get trusted metadata more dynamically, I think batch is
the simpler way to go, and I haven't been able to get my mind around a model
where it's both distributed in content but still vetted by  a third party.

My experience has been that the people arguing for distributing the
information are also advocating unsigned metadata, typically by that meaning
they use an SSL cert or something, but I don't really find the notion
comforting (as I don't think you do).

> Batch downloads solve the problem, but rely on batch processes.

Well, we should distinguish bulk from batch. Batch is one way, but the real
point is that's it's centrally hosted and signed. It can be fetched and
monitored in real time or batch.

> 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).

I'm fine with that, I'm just trying to understand some of your assumptions
better. I'm obviously not the gatekeeper here (apart from somebody asking me
to actually author specs, which you're not).

> 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?

It's an Extension, that's what it's there for. It's explicitly an optional
thing (in the sense that metadata is always somewhat non-normative), so it
fits fine.

My questioning was intended to better understand the scope of what you were
suggesting and how it would address (or not address) certain problems.

Clearly an SP that knows enough about an IdP to send it a request can
include its metadata in the AuthnRequest and you could drive pretty much the
rest of the process with it. If you wanted to just say that the SP needs to
know only the SSO service information, then I suppose an IdP could include
its metadata as well.

-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]