On 11/12/2012 00:55, Danny Coward wrote:
> 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 ?
I don't think so. Everything looks covered to me.
Mark