On 12/8/12 3:55 AM, Mark Thomas wrote:
> On 07/12/2012 23:42, Danny Coward wrote:
>> On 12/7/12 9:43 AM, Mark Thomas wrote:
>>> On 07/12/2012 00:56, Danny Coward wrote:
>>>> OK, so in the spirit of trying to close out this discussion and find
>>>> what is reasonable to require in the specification, what it looks like
>>>> to me we are left with is this:-
>>>>
>>>> 1) The only association between websocket session and HttpSession is at
>>>> opening handshake time. The API gives developers a convenient access to
>>>> the HttpSession object at that point in time.
>>>> 2) The user identity associated with the websocket Session is the user
>>>> identity that was established at the opening handshake.
>>> Do we want to expose this through the API?
>> I think it would be convenient to do so. Its the same Principal that is
>> available on the OpeningHandshake. But perhaps developers would like to
>> access it even if they don't intercept the handshake. Like POJO developers.
>>>> 3) If the server decides that authorization for this websocket resource
>>>> by this user identity has ended (it expired, or some logout mechanism
>>>> was invoked) then the websocket implementation must immediately close
>>>> the connection.
>>> Can we make this behaviour optional?
>> Hi Mark,
>>
>> My thinking is that if the server has revoked the access of a user to a
>> certain resource, if that resource is one of our websockets, we should
>> close it. What would be the reason to keep a protected resource like
>> this available to a client after such a time ?
> I'm thinking about edge cases when the end point is not protected but a
> Principal was present at the point of the handshake either because the
> container cached one in the session or because the client is using
> pre-emptive authentication.
OK, I meant only to be talking about the case where the resource is
protected, so the behaviour doesn't have to be the same as this
(unprotected) case you are talking about.
> The first question is "Do we expose the Principal in this case?". I
> think we should.
That sounds reasonable.
> The next question is then "If no use is made of that Principal why
> should we close the WebSocket connection when the Principal is
> invalidated?".
> If the Principal is used then I think there is a case for closing the
> handshake when the Principal is invalidated. Even in this case though, I
> can think of examples where that would not be the desired behaviour.
> (e.g. the Principal was obtained for logging purposes but was not used
> for any security function).
>
> There ends up being so many edge cases that having a defined policy for
> all circumstances quickly gets messy. That is why I suggested making it
> optional. I'm not sure what the simplest way of doing that would be. My
> implementation work isn't as far on as I would like at this point. Maybe
> add a flag to the getUserPrincipal() call that indicates if a Principal
> is returned then the connection should be closed when the Principal is
> invalidated?
I think its simpler just to define the behavior just in the two cases of
'websocket is protected' and 'websocket is not protected' rather than
whether or how the server knows the identity of the client or whether
the developer is making use of it.
I think the important case is to make sure a websocket that is only
accessible by particular authenticated users cannot continue to be
accessed after the server has decided the authenticated state has ended.
The other case when the websocket is not protected, in which case I
think it would be reasonable to require the container to make the
identity of the client user of the websocket known through the API, if
the container knows it. But since the identity of the user had no effect
on whether the websocket connection from that client was opened in the
first place, it should have no effect on closing it if the identity of
the user changes or becomes invalid.
Are there still edges cases outside those two ?
- Danny
> Mark
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation