Title: 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
>
