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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsfed message

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


Subject: New Issue: Deprecation of wsignoutcleanup1.0 message breaksinteroperability


Section 13.2.4 of the current draft of WS-Federation deprecates the wsignoutcleanup1.0 message for use during sign-out processing for passive requestors.  The intention of this change was to establish consistency with the newer SOAP sign-out protocol (using <fed:SingleSignOutSubscriptionEndpoints> and <fed:SingleSignOutNotificationEndpoints>)which only requires sending a single type of sign-out message.
 
During interoperability testing TC members have discovered that this change is not interoperable with released implementations that support the original WS-Federation sign-out protocol defined in the Passive Requestor Profile.  Existing implementations require both the wsignout1.0 and the wsignoutcleanup1.0 messages to determine whether it is necessary to (a) redirect the requestor upstream to the original Identity Provider STS, or to (b) clean up local session state and redirect the client downstream to other Relying Party STSs.
 
Sign-out can be initiated by the client at one of four points in the system:
1.    A Relying Party application server
2.    A Relying Party STS
3.    An application server local to the Identity Provider
4.      The Identity Provider STS
 
For the first three use cases, existing implementations use the wsignout1.0 message to redirect the browser and sign-out request to the IP STS.  Then the IP STS sends the wsignoutcleanup1.0 message to all local applications and remote RP STSs to instruct them to perform cleanup all local session state for the requesting client.  Effectively, wsignout1.0 messages are only used to propagate the sign-out request to the IP STS.  Sign-out is not actually performed by any RP STS or application until it receives a wsignoutcleanup1.0 message.
 
 
The following changes to WS-Federation are proposed to restore interoperability between new implementations and existing customer deployments.
 
Current text
13.2.4  Sign-Out Request Syntax
 
This section describes how sign-out requests are formed and redirected by Web requestors.  For modularity, it should be noted that support for sign-out is optional.
 
The following describes the parameters used for the sign-out request (note that this parallels the sign-out SOAP message previously discussed):
 
wa=string
wreply=URL
 
wa
 
This required parameter specifies the action to be performed.  By including the action, URIs can be overloaded to perform multiple functions.  For sign-out, this string MUST be "wsignout1.0".  For backward compatibility with previous versions, this parameter MAY be "wsignoutcleanup1.0" but use of this is deprecated.  That is, processors SHOULD use "wsignout1.0" but MUST accept "wsignoutcleanup1.0".
 
wreply
 
This optional parameter specifies the URL to return to once clean-up (sign-out) is complete.  If this parameter is not specified, then after cleanup the GET completes by returning any realm-specific data such as a string indicating cleanup is complete for the realm.
 
 
Proposed text revision
13.2.4  Sign-Out Request Syntax
 
This section describes how sign-out requests are formed and redirected by Web requestors.  For modularity, it should be noted that support for sign-out is optional.
 
Sign-out can be initiated by a client at one of four points in the system:
        1. A Relying Party application server
        2. A Relying Party STS
        3. An application server local to the Identity Provider
        4. The Identity Provider STS
 
For the first three use cases, the requestor's client must be redirected to the Identity Provider STS where the current session originated. This STS is required to send clean-up messages to all Relying Party STSs and any local applications for which the IP STS has issued security tokens for the requestor's current session.  How the STS tracks this state for the requestor is implementation specific and outside the scope of this specification.
 
As can be seen, for passive requestors the sign-out process is divided into two separate phases, referred to as sign-out and clean-up. Two different messages are used to ensure that all components of the system understand which phase is in effect to ensure that the requestor's sign-out request is processed correctly.
 
13.2.4.1 Sign-out Message Syntax
The following describes the parameters used for the sign-out request (note that this parallels the sign-out SOAP message previously discussed):
 
wa=string
wreply=URL
 
wa
 
This required parameter specifies the action to be performed.  By including the action, URIs can be overloaded to perform multiple functions.  For sign-out, this string MUST be "wsignout1.0".  For backward compatibility with previous versions, this parameter MAY be "wsignoutcleanup1.0" but use of this is deprecated.  That is, processors SHOULD use "wsignout1.0" but MUST accept "wsignoutcleanup1.0".
 
wreply
 
This optional parameter specifies the URL to return to once clean-up (sign-out) is complete.  If this parameter is not specified, then after cleanup sign-out the GET MAY completes by returning any realm-specific data such as a string indicating cleanup sign-out is complete for the realm.
 
13.2.4.2 Clean-up Message Syntax
The following describes the parameters used for the clean-up phase of a sign-out request:
 
wa=string
wreply=URL
 
wa
 
This required parameter specifies the action to be performed. By including the action, URIs can be overloaded to perform multiple functions. For the clean-up phase of a sign-out request, this string MUST be "wsignoutcleanup1.0".
 
wreply
 
This optional parameter specifies the URL to return to once clean-up is complete. If this parameter is not specified, then after cleanup the GET MAY complete by returning any realm-specific data such as a string indicating cleanup is complete for the realm.
 
 


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