OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] Rejecting Saml Requests (SOAP Binding0


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:Thomas.Wisniewski@entrust.com]
Sent: Wednesday, June 22, 2005 6:31 PM
To: Scott Cantor; Thomas Wisniewski; security-services@lists.oasis-open.org
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:cantor.2@osu.edu]
> Sent: Wednesday, June 22, 2005 5:06 PM
> To: 'Thomas Wisniewski'; security-services@lists.oasis-open.org
> 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
>



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