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