[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsfed] FW: Request for clarification of WSFED issue i008 -Sign-out notification and priority (on behalf of the WSFED TC)
I'm forwarding for Don since the list seems to be bouncing it. - Marc g
________________________________________
From: Don Schmidt
Sent: Friday, August 17, 2007 5:06 PM
To: wsfed@lists.oasis-open.org; Paul.Lesov@wellsfargo.com
Subject: [wsfed] FW: Request for clarification of WSFED issue i008 - Sign-out notification and priority (on behalf of the WSFED TC)
It was requested at the last TC meeting that I respond on the list to issue i008 with clarifications that have been discussed during previous meetings and propose a resolution for review by the members. I have separated Paul Lesov's email description of the issue into separate parts and responded to each one individually.
<Part 1>
[Issue Description]
>Firstly I would like to clarify on the specification documentation
>(ws-federation-1.2.-spec-ed->01.doc).
>http://www.oasis-open.org/apps/org/workgroup/wsfed/download.php/24422/w
>s-federation->1.2-spec-ed-01.doc
>
>According to the depiction III.9.3 of Sign-Out the IP redirects a
>browser to clean-up at one service provider and then >once complete redirects a browser to clean-up at the next service provider. This diagram depicts sequential, not parallel >sign-out, even though section 4.2 states that parallel approach SHOULD be used for sign-out.
[Discussion]
The referenced sections of the specification do not contradict each other, but are potentially ambiguous.
Section 4.2 provides a generic description of the Sign-Out process which is applicable to both SOAP and browser requestors. This includes a discussion of both sequential and parallel message transmission, including the robustness of these methods with respect to the likelihood of completion. The specification recommends parallel transmission since this approach is more likely to complete for all endpoints.
Appendix III.9.3 describes the potential sign-out message flow specifically for the browser requestor case in which all messages must be transported by the requestor. Since it cannot be assumed that all browser requestors can transmit parallel requests, the sequential method is depicted as the lowest common denominator approach. This is consistent with the syntax defined in section 13.2.4 for sign-out messages, which includes the optional "wreply" parameter to specify the URL to which the browser requestor should be redirected.
[Proposed Resolution]
The text in III.9.3 should be clarified as follows:
[existing text]
The figure below illustrates the sign-out flow for a requestor that has signed in at two sites and requests that the sign-out cleanup requests redirect back to the requestor:
[proposed text]
The figure below illustrates the sign-out flow for a Web browser requestor that has signed in at two sites and requests that the sign-out cleanup requests redirect back to the requestor. The message flow is an example of the use case in which all sign-out messages must be transmitted by the requestor. Since it cannot be assumed that all browser requestors can transmit parallel requests, the sequential method is depicted. This message flow is enabled by the "wreply" parameter defined in section 13.2.4.
</Part 1>
<Part 2>
[Issue Description]
>The same depiction also indicates some sort of reply being sent from service providers indicating clean-up complete, >while in section 4 of the document (first paragraph) there is a statement about sign-out being a one-way message without >any reply.
[Discussion]
The specification appears to be ambiguous. Section 4 states, "It should be noted that a sign-out message is a one-way message (that is, it doesn't have a reply)." Section 13.2.4 describes the possibility of a reply to a sign-out message using the optional "wreply" parameter.
The intention of the text in section 4 is to convey that operationally Sign-Out is a best effort operation that is not guaranteed to complete. Therefore, no completion response can be required or expected. Section 13.2.4 refers to a physical requirement. When multiple sign-out messages must be transmitted sequentially by a Web browser requestor, it is necessary to redirect the requestor to the IP/STS repeatedly until all sign-out messages are sent.
[Proposed Resolution]
The text in section 4 should be clarified as follows:
[existing text]
In typical usage, sign-out notification serves as a hint - upon termination of a principal's session - that it is OK to flush cached data (such as security tokens) or state information for that specific principal. It should be noted that a sign-out message is a one-way message (that is, it doesn't have a reply). Depending on the type of application that is being used to sign-out, the process may vary. For example, the implication of sign-out on currently active transactions is undefined and is resource-specific.
[proposed text]
In typical usage, sign-out notification serves as a hint - upon termination of a principal's session - that it is OK to flush cached data (such as security tokens) or state information for that specific principal. It should be noted that a sign-out message is a one-way message. No "sign-out-complete" reply message can be required since the Sign-Out operation cannot be guaranteed to complete. Further, sign-out requests might be processed in batch, causing a time delay that is too long for the request and response to be meaningfully correlated. In addition, requiring a Web browser requestor to wait for a successful completion response could introduce arbitrary and lengthy delays in the user experience.
The processing implication of sign-out messages can vary depending on the type of application that is being used to sign-out. For example, the effect of sign-out on currently active transactions is undefined and is resource-specific.
</Part 2>
<Part 3>
[Issue Description]
>Now to expand on ISSUE i008
>
>There were really three points there:
>
>- (1) Identity provider should be certain (as much as possible with stateless protocol framework) that sign-out requests >sent to service providers were processed successfully.
>
> In the proposed architecture sign-out is a one-way message. Therefore it is not possible to provide a confirm/reply >that session is terminated. I would argue that sign-out should have a reply indicating successful session termination. >Some parameter should specify to the requestor that the cleanup is completed at the service provider.
[Discussion]
As discussed in <Part 2>, the Sign-Out operation is not guaranteed to complete. Even if it completes, the time delay may be too long for a successful completion response to be useful. Finally, requiring a Web browser requestor to wait for a successful completion response could introduce arbitrary and lengthy delays in the user experience.
[Proposed Resolution]
The requested change to the specification should not be accepted. The revised text for <Part 2> includes an explanation of why this is not possible.
</Part 3>
<Part 4>
[Issue Description]
>- (2) Priority of sign-out was the second point
>
> I will withdraw priority request from the issue, once I get confirmation on my clarification above that parallel >sign-out is being used not sequential sign-out. If parallel sign-out is used prioritizing does not add any value.
[Discussion]
It does not seem useful to require prioritized processing of sign-out messages when it is conceivable that Sign-Out operations may be performed in batch, or may not even complete. Furthermore, what justification is there for sign-out messages to take precedence over other requests, such as token issuance or validation?
[Proposed Resolution]
The requested change to the specification should not be accepted.
</Part 4>
<Part 5>
[Issue Description]
>- (3) Informing the user about completed sign-out.
>
> Once Identity Provider receives success sign-out replies from
>service providers (1) IP should be able to indicate to >a passive requestor that sign-out was completed. If some service providers did not return a success reply to a sign-out >request a user should be presented with that information as well. I realize that this may be beyond the score of the >specification but it is not possible without (1).
[Discussion]
As discussed in <Part 2>, it is not possible to guarantee that an Identity Provider will receive sign-out replies in a timely manner, if at all. Therefore, it is not possible to require that the Identity Provider will inform a passive requestor that sign-out was completed.
Note, however, that Web requestors transmit sign-out messages using an HTTP GET. Thus, in section 13.2.4 the specification does allow the possibility that a Requestor or Resource IP/STS may return "realm-specific data such as a string indicating cleanup is complete for the realm." One could imagine some sort of Sign-Out landing page where the status of sign-out requests could be recorded to be looked up by a passive requestor. This would be implementation specific and is outside the scope of the specification.
[Proposed Resolution]
The requested change to the specification should not be accepted.
</Part 5>
Regards,
Don Schmidt
Principal Program Manager
Microsoft Corporation
________________________________________
From: Paul.Lesov@wellsfargo.com [mailto:Paul.Lesov@wellsfargo.com]
Sent: Thursday, July 05, 2007 12:54 PM
To: wsfed@lists.oasis-open.org
Subject: [wsfed] FW: Request for clarification of WSFED issue i008 - Sign-out notification and priority (on behalf of the WSFED TC)
________________________________________
From: Paul.Lesov@wellsfargo.com [mailto:Paul.Lesov@wellsfargo.com]
Sent: Thursday, July 05, 2007 12:05 PM
To: Greg Carpenter
Cc: mikemci@us.ibm.com; Chris Kaler; abbieb@nortel.com; mkaiser@us.ibm.com
Subject: RE: Request for clarification of WSFED issue i008 - Sign-out notification and priority (on behalf of the WSFED TC)
Firstly I would like to clarify on the specification documentation (ws-federation-1.2.-spec-ed-01.doc). http://www.oasis-open.org/apps/org/workgroup/wsfed/download.php/24422/ws-federation-1.2-spec-ed-01.doc
According to the depiction III.9.3 of Sign-Out the IP redirects a browser to clean-up at one service provider and then once complete redirects a browser to clean-up at the next service provider . This diagram depicts sequential, not parallel sign-out, even though section 4.2 states that parallel approach SHOULD be used for sign-out. The same depiction also indicates some sort of reply being sent from service providers indicating clean-up complete, while in section 4 of the document (first paragraph) there is a statement about sign-out being a one-way message without any reply.
Now to expand on ISSUE i008
There were really three points there:
- (1) Identity provider should be certain (as much as possible with stateless protocol framework) that sign-out requests sent to service providers were processed successfully.
In the proposed architecture sign-out is a one-way message. Therefore it is not possible to provide a confirm/reply that session is terminated. I would argue that sign-out should have a reply indicating successful session termination. Some parameter should specify to the requestor that the cleanup is completed at the service provider.
- (2) Priority of sign-out was the second point
I will withdraw priority request from the issue, once I get confirmation on my clarification above that parallel sign-out is being used not sequential sign-out. If parallel sign-out is used prioritizing does not add any value.
- (3) Informing the user about completed sign-out.
Once Identity Provider receives success sign-out replies from service providers (1) IP should be able to indicate to a passive requestor that sign-out was completed. If some service providers did not return a success reply to a sign-out request a user should be presented with that information as well. I realize that this may be beyond the score of the specification but it is not possible without (1).
________________________________________
From: Greg Carpenter [mailto:gregcarp@microsoft.com]
Sent: Thursday, June 28, 2007 11:11 AM
To: Lesov, Paul
Cc: Michael McIntosh; Chris Kaler; Abbie Barbir; Mike Kaiser
Subject: Request for clarification of WSFED issue i008 - Sign-out notification and priority (on behalf of the WSFED TC)
Hi Paul,
As a Secretary and Issues List Editor of the WSFED TC I'm contacting you to convey the TCs request for clarification regarding issue i008 (http://docs.oasis-open.org/wsfed/issues/Issues.xml#i008). In order for the TC to adequately understand and process this issue we need more information, preferably in the form of a specific proposal documenting what is needed to implement the features you mention in the issue.
Best Regards,
-greg
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]