Re: [regext] Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt)

[Mario Loffredo <[e-mail]>]

Hi Scott,

according to my experience about session management,  client and servers 
should operate as in the following:

- Normally, a session/login followed by another session/login should 
result in opening a new session on the server with a new session cookie.

- The server sets the session cookie once the session/login is received, 
the client includes the session cookie received from the server in any 
RDAP request within the scope of that session including session/refresh, 
session/status and finally session/logout.

- If the client sends any request other than session/login including an 
unknown cookie, the server must return an error.

- If the client sends a session/login request including a cookie, the 
server could return an error or ignore the cookie received by the client 
and hence provide the client with a new session cookie. To be decided 
what should be the server's behaviour in that case.

- A server can refuse to open a new session after a session/login if a 
maximum number of concurrent sessions per user exists and the client 
exceeded that limit. This is to prevent servers from resource starvation.

- A session can be removed by the server due to timeout expiration or 
because a maximum session lifetime exists, regardless the fact that the 
session ia active, and the session has exceeded that limit. This is to 
prevent server from handling inactive sessions and indefinitely opened 
sessions.


Best,

Mario


Il 07/07/2022 17:01, Hollenbeck, Scott ha scritto:
> Thanks, Rick. Trimming things up a bit and changing the subject
> appropriately...
>
>>>> In the last sentence: Is the client required to wait until the access
>>>> token has
>>>> expired before submitting the new login request?  Or can it send logout
>>>> and
>>>> login back-to-back?  (Or even just a login command while currently logged
>>>> in?)
>>> [SAH] Let's talk about this. What's appropriate behavior? IF the server
>>> gets a
>>> "login" during an active session, it can either ignore the second "login",
>>> or it
>>> can return an error. Similarly, it the server gets a "logout" when there's
>>> no
>>> active session, it can either ignore the "logout" or return an error. I'm
>>> inclined to return an error to explicitly note that the submitted
>>> query/command
>>> wasn't processed as requested.
>> [RW] First off, I will certainly defer to those with more implementation in
>> this
>> realm.  However, based on my experience as a user, I would expect a login
>> that
>> happens during an active session to "just work" and override the previous
>> active
>> session.  This could happen when I have an active session at the server but
>> the
>> client browser (with the session) crashes or is otherwise inaccessible.
>> This
>> seems better than the alternative:  If the new login request is refused,
>> then
>> the user is (essentially) locked out until the session timeout value
>> expires.
>> Related, if the server gets a "logout" when there is no active session, I
>> think
>> that it should ignore the "logout" (rather than returning an error).  The
>> thinking being that returning an error is at best useless and at worst could
>> be
>> an information leak (aka security risk).
> The document currently describes a session/refresh path segment to perform the
> kind of "override" behavior described above. Having a "login followed by a
> login" do the same thing seems counter-intuitive. My own experience with
> server-side session management is that there is no lockout. If the client
> sends the right HTTP cookie, and the session is still active, there won't be a
> problem. Another login should be possible if the "old" session gets corrupted.
>
> Let's look at the server-side options again for situations in which the server
> receives a login followed by a login, or a logout where there's been no login,
> or a refresh without an active session, or a session status without an active
> session:
>
> 1. Return an error. HTTP includes a 409 (Conflict) response that can be
> returned if a received request conflicts with the current state of the server.
>
> 2. Accept the request and ignore it. I'm not sure what an appropriate HTTP
> response code would be for this situation.
>
> 3. Accept the request and do "something".
>
> Option 1 can be done consistently for all the above request sequences. Option
> 2 seems like it could mislead the client into thinking that something has
> happened unless there is, in fact, an appropriate HTTP response code available
> to describe a no-op (I couldn't find one). Option 3 might be doable if we can
> figure out what the "somethings" are, like processing a second login received
> while a session is active, but the other command sequences present problems.
> As you described above, a logout received without an active session is
> processed differently than the "login followed by a login" situation. Is that
> really the best course of action? I think consistent behavior would be
> preferred.
>
> Scott
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web: http://www.iit.cnr.it/mario.loffredo