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

Title: Message

Ari, 
that was my sentiment as well.

 

It 
wasn't clear what you were proposing for the soap case. I thought that returning 
a very general soap fault seemed ok (albeit a DOS attack with invalid sigs will 
cause the responder to create soap fault-based responses). I guess the only 
other altrenatives are to close the pipe period or to issue an HTTP 403 
Forbidden error.

 

Tom.

  

  
-----Original Message-----
From: Ari Kermaier 
  [mailto:] 
Sent: Thursday, June 23, 2005 9:26 
  AM
To: Thomas Wisniewski; Scott Cantor; Thomas Wisniewski; 
  
Subject: 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 
>