Title: RE: [security-services] Rejecting Saml Requests (SOAP Binding0
I
would argue that a bad signature also means that the issuer is unknown -- at
least in the sense that the Issuer value might not identify the
actual sender of the message -- and that it should be the prerogative of
the recipient to ignore the message entirely, and not even return a transport
layer error to the sender. In the HTTP case, an HTTP error could be
returned to the user's browser, but the recipient should not have to respond to
the "Issuer" via SAML protocol.
Ari
Kermaier
-----Original Message-----
From: Thomas Wisniewski
[mailto:]
Sent: Wednesday, June 22,
2005 6:31 PM
To: Scott Cantor; Thomas Wisniewski;
Subject: RE:
[security-services] Rejecting Saml Requests (SOAP
Binding0
Scott, take the first item below -- so you do not even know
the issuer (for an http binding, you wouldn't send a saml response, since you
wouldn't know where to send it to -- since you don't know the issuer at
all).
I could see your case for when the issuer is known (bullets
2-4).
However, I think the spec isn't clear on "cannot process the
request." The example it gives is much more latter on in processing the
request.
Are others returning saml responses for bullets 2-4 but not
1?
Tom.
> -----Original Message-----
>
From: Scott Cantor [mailto:]
> Sent: Wednesday, June 22, 2005 5:06 PM
> To: 'Thomas Wisniewski';
> Subject:
RE: [security-services] Rejecting Saml Requests
>
(SOAP Binding0
>
>
> > It seems that from bindings 313-314, that if
a Saml Responder
> > or Provider cannot process
the request, then it would send a
> > soap fault
(vs. a SAML response msg). So some examples of
>
> this include:
> >
> > - the issuer name is not recognized at all.
> > - requeset was not signed, but signature was required.
> > - signature was incorrect.
> > - the Destination attribute of the request did not match
the
> > url the request was sent to.
>
> Umm, not really. Those to
me would all be SAML errors, and
> handled with
SAML responses. SOAP faults are reserved for
>
transport layer concerns like "malformed message". In ours,
> as soon as I parse the SAML successfully, further errors are
> returned in the SAML domain.
>
> > talks about possibly using the
Status second level code
> > Version..... So
this implies a Saml msg could be sent back.
> >
So is the actual response (soap fault vs. Saml msg) up to the
> > implementer?
>
> Ultimately, but version errors in the SAML domain are
> supposed to be SAML errors.
>
> -- Scott
>
