Max number of REST sessions

[Joseph Reynolds]

On 2018-12-14 09:10, Tanous, Ed wrote:
> Today, there is no session count limit, aside from your BMCs RAM
> limitations to store a small struct for each user session, although
> there should be. In the past when this has come up, there were
> questions about what the behavior should be when user sessions roll
> past the limit.

 From the Redfish specs [1] DSP0266 1.6.0 Redfish API Specification 20 
Sep 2018 [2]:

>>>> Section 9.2.4.1. Session life cycle management
>>>> Session management is left to the implementation of the Redfish 
>>>> Service. This includes orphaned session timeout and number of 
>>>> simultaneous open sessions.

[1]: https://www.dmtf.org/standards/redfish
[2]: 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.6.0.pdf

Note the BMCWeb Redfish implementation effectively defines OpenBMC's 
Redfish session management policy.  As such, I vote we document that 
policy, specifically, the decisions we are making now, including 
existing behavior like persisting sessions across a server restart.

> Some of the proposed solutions that I’ve heard in the past:
> 
> 1. Impose session limits either per user, per connecting ip address,
> or both. When a user rolls past the limit, one of two things can
> happen:
> 
>  a. New sessions are rejected until old sessions time out.

It looks like BMCWeb Redfish sessions have a 60 minute idle timeout (ref 
bmcweb/include/sessions.hpp class SessionStore [3]) which means they 
stay active indefinitely when they are used at least once every 60 
minutes.  This is consistent with the spec (9.2.4.5. Session lifetime).

[3]: 
https://github.com/openbmc/bmcweb/blob/aceb7fc879578407879af2f456458d080e39ec2d/include/sessions.hpp#L101

>  b. New sessions will “push out” the oldest session in the queue.

This seems like a good approach.  What maximum number of simultaneous 
sessions?  Several dozen?

Does "oldest" refer to the sequence in which sessions were established?  
I assume it does not mean "least recently used".


> 2. Use session tokens encrypted with a BMC secret (similar to json web
> token) and don’t store the session information on the BMC at all.
> This would effectively remove all the session limits
> 
> 3. “Reuse” sessions per user account, effectively capping the
> session count to the number of users or less
> 
> In my opinion, someone (possibly me) should put together a patchset to
> execute on 1b. What are other people’s requirements in this area?
> Did I miss anything?

What do other Redfish implementations do?

> -Ed