SLO and ID Federation Termination for SAML persistent NameID formats

Title: Message

The following 
assumes two main use cases for an ID Federation when using a SAML 
persistent NameID format.. One that is initiated by a user and one that is 
initiated via some administration activity.

 

1. 
User-initiated

 

  a. User 
terminates federation at SPx with IDPy (no existing 
SAML session)

 

  b. User 
terminates federation at SPx with IDPy (with an existing SAML 
session between IDPy and SPx)

 

  c. User 
terminates federation at IDPy with SPx (no existing 
SAML sessions)

 

  d. User 
terminates federation at IDPy with SPx (with an existing SAML session 
between IDPy and SPx)

 

2. 
Admin-initiated.

 

  a. Admin 
terminates federation for a user at SPx with IDPy (no existing 
SAML session)

 

  b. Admin 
terminates federation for a user at SPx with IDPy (with 
an existing SAML session between IDPy and SPx)

 

  c. Admin 
terminates federation for a user at IDPy with SPx (no existing 
SAML sessions)

 

  d. Admin 
terminates federation for a user at IDPy with SPx (with 
an existing SAML session between IDPy and SPx)

 

For cases 1a, 1c, 
2a, and 2c, an MNI terminate message is sent to terminate the 
federation. Since there are no SAML sessions associated with the NameID, no SAML 
logout processing is necessary.

 

For case 
1b, an MNI terminate message is sent from the SP to the IDP 
to terminate the federation. It is up 
to the SP as to whether the SAML session created by an Assertion from the IDP is 
logged out. In general the SAML session SHOULD NOT be logged out. When the 
IDP receives an MNI terminate message, the IDP SHOULD remove or otherwise 
invalidate the SAML session it has for the SP. To adhere to the SAML 
specification requirements, the IDP and the SP MUST not send an SLO message with 
the terminated NameID. 

 

For case 1d, an 
MNI terminate message is sent from the IDP to the SP to terminate the 
federation. The IDP 
SHOULD NOT send an SLO message to the SP prior to sending the MNI terminate 
message. The IDP SHOULD remove or otherwise invalidate the SAML session it 
has for the SP. It is up to the SP as to 
whether the SAML session created by an Assertion from the IDP is logged out when 
the SP receives the MNI terminate message. In general the SAML session 
SHOULD NOT be logged out. To adhere to the SAML specification requirements, the 
IDP and the SP MUST NOT send an SLO message after the MNI terminate message 
because the NameID has been terminated.

 

For case 
2b, an MNI terminate message is sent from the SP to the IDP to 
terminate the federation. It is up to the 
SP as to whether the SAML session created by an Assertion from the IDP is logged 
out. In general the SAML session SHOULD be logged out. [[TomW: this is the 
difference from 1b that was proposed on the conference call. I still think that 
perhaps this should be changed to SHOULD NOT as in 1b??]] When the 
IDP receives an MNI terminate message, the IDP SHOULD remove or otherwise 
invalidate the SAML session it has for the SP. To adhere to the SAML 
specification requirements, the IDP and the SP MUST NOT send an SLO message with 
the terminated NameID. 

 

For case 2d, an 
MNI terminate message is sent from the IDP to the SP to terminate the 
federation. The IDP SHOULD NOT 
[[TomW: we could change this to MAY, but I don't think it's appropriate, if we 
don't 2d is identical to 1d]] send an SLO message to the SP prior to sending the 
MNI terminate message. The IDP SHOULD remove or otherwise invalidate 
the SAML session it has for 
the SP. It is up to the SP as to 
whether the SAML session created by an Assertion from the IDP is logged out when 
the SP receives the MNI terminate message. In general the SAML session 
SHOULD NOT be logged out. [[TomW: I think this is appropriate but others 
can argue that a SHOULD should be 
used??]] To adhere to the SAML specification requirements, the 
IDP and the SP MUST NOT send an SLO message after the MNI terminate message 
because the NameID has been 
terminated.

 

[[TomW: Keep in mind that there is no 
normative text around what should happen to a SAML ID federation for a user 
that is "locally removed" at a provider -- irregardless of whether it is 
user-initiated or admin-initiated. If the provider does not do an exhaustive 
propagation (e.g., via an MNI Termination to all partners where an ID Federation 
exists), the federated identities basically become 
orphaned.]]

 

Tom.