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.
The first question is "Do we expose the Principal in this case?". I
think we should.
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?
Mark