[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] SAML2 metadata for a SAML1 IdP
> Sorry, Scott, I'm not understanding you. I'm talking about ordinary > SAML1 IdP-initiated Browser/POST. What does IdP metadata look like in > this case? Whatever you want it to look like (that's what unspecified means), but I stand by the original statement. There is no such thing as "ordinary SAML1 IdP-initiated Browser/POST". You can't get an IdP to respond using thought waves. Something from the client has to tell it to respond. That's an AuthnRequest, whatever the form. You could implement an IdP inside some kind of application, I suppose, and then the message might be extremely varied or part of some larger application exchange, but that's rare, and could still be advertised if you wanted to do so. And I bet at the end it would still be a pretty specific request with parameters you could document, even if they didn't mean anything outside the app. Point being, you could work really hard at making it impossible to get the IdP to respond using a reasonably self-contained message, or you could do what everybody does, just use a couple of simple parameters, call it a binding, and stick a label for it in the metadata. The reality is that you could probably get 99% of the IdPs on the market to interop just fine using simple scripts that rewrite parameter names into whatever the IdP wants, but when we try and explain that to people, they glaze over. So it's easier to just say "SAML 1.1 doesn't support SP-initiated SSO" even though it's almost always not true in practice. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]