RE: [saml-dev] SLO IDP generated bindings.

Title: RE: [saml-dev] SLO IDP generated bindings.

 

In order to do browser-based SSO, the browser has to have 
an active action in progress at the IdP.  Even if the browser has a page 
open at the IdP it doesn't matter if the IdP has already finished sending the 
data to the browser for that page.  The IdP would have to wait until the 
next HTTP request from the browser to initiate the SLO.

 

Expiration is typically handled via the 
 <Conditions> NotOnOrAfter or the <AuthnStatement> 
SessionNotOnOrAfter attributes.

User initiated SLO at the IdP works fine since that would 
be an HTTP request to the IDP.

 

Otherwise for IdP intiated SLO due to some administrative 
reason, the IdP would be forced to use the SOAP interface (if it was supported 
by the SP).

 

Conor

  

  
  From: Giuseppe Sarno 
  [mailto:] 
Sent: Thursday, November 30, 2006 7:59 
  PM
To: Scott Cantor; 
  
Subject: RE: [saml-dev] SLO IDP 
  generated bindings.

  

  
Hi thanks you are right I'll re-frase.

Case where IDP 
  decide to terminate session (expires or even admin intervention).
From what 
  I understood unless there some sort of Browser polling technique, SOAP is then 
  the only recommended 
  option?

Thanks.
giuseppe.

-----Original 
  Message-----
From: Scott Cantor [mailto:]
Sent: Fri 
  01/12/2006 00:53
To: Sarno, Giuseppe (MOP:GM15); 
  
Subject: RE: [saml-dev] SLO IDP generated 
  bindings.

> I was thinking about the case the IDP decides to 
  terminate a
> session (Session expires, others.)
> It should issue 
  a SLO req to the SP/SPs involved.
> Now in this case the User Agent is 
  not involved at all so I'm
> assuming the only possible binding to be 
  used (and coverd by
> the spec) is any synch binding (so far only SOAP 
  is supported).
> Is that correct ?

The browser is involved if the 
  user initiates the logout, or if a window is
maintained somehow with some 
  kind of polling or something.

IdP-initiated doesn't mean "user not 
  involved", that's an orthogonal
consideration.

> Could HTTP Post 
  be used in this case anyhow ?

HTTP POST is a browser-mediated binding, 
  but it is implementation-dependent
whether a server can tell the 
  difference. It should never be used in place
of SOAP, and there's really 
  nothing to be gained from doing that.

-- Scott

Hi