Previously the web browser sent HTTP Authorization headers for all requests to a given origin after the header has already been set for the initial request. This meant the user interface plugin infrastructure acquired a REST API session using web administration portal user credentials including domain and password information, and the session was kept alive until the user signed out of the administration portal.
To work around this issue, all user interface plugins now receive a single shared session ID based on the web administration portal user login credentials. This session times out after six hours, and the administration portal will not attempt to keep this session alive using periodic heartbeat requests.
The plugin is in charge of keeping its session alive, and if no plugin interacts with the REST API session via the provided ID for more than six hours, the session will time out.

Hi Leonid
To avoid logins/logs, restapi clients should be using persistent-authentication.
This is incorrect usage that is causing the re-authentication of client on the api side resulting in the logs entries.

Leonid,
We got impression that this logins caused by api working against the same backend
you connected with webadmin to,
please check the connection sources, afaics this is not a bug even if assumption
made above is correct (see Comment 5).

Same user,tried in several browsers. Also checked on Dafna's environment (different RHEVM machine) and she has the same issue. I think it might be better if someone come and look at the issue instead of rising needinfo flag each time :)

Hi, this is a bug related to UI Plugins infrastructure trying to keep REST API session alive while the user stays authenticated in WebAdmin UI.
RestApiSessionManager (WebAdmin) issues HTTP GET keep-alive request to "/api" every 60 seconds.
> To avoid logins/logs, restapi clients should be using persistent-authentication.
> This is incorrect usage that is causing the re-authentication of client on the api side resulting in the logs entries.
WebAdmin uses persistent-auth scheme as described in http://wiki.ovirt.org/Features/RESTSessionManagement:
* first request (acquire session) is sent with "user@domain:password" credentials + Prefer:persistent-auth [RestApiSessionManager.acquireSession]
* subsequent request (keep session alive) is sent ONLY with REST API JSESSIONID cookie + Prefer:persistent-auth [RestApiSessionManager.scheduleKeepAliveHeartbeat]
Is the above incorrect usage of REST API persistent-auth scheme?
From my perspective, the problem is that each REST API request goes through LoginUserCommand, but I might be missing something.

It seems that even though WebAdmin (JavaScript) doesn't set Authorization header for heartbeat request, web browser is still setting it (using value from initial session acquiry request) before dispatching the heartbeat request.
I'll try to work around this, but I highly recommend to consider option B) mentioned in comment #18. In other words, WebAdmin (JavaScript) doesn't have full control over HTTP request processing, unlike traditional HTTP client, so hopefully REST API provides a helping hand here.

Note regarding the above mentioned patch: after applying, there will be two "User <username@domain> logged in." business events for each user login: first one due to WebAdmin GUI user login, second one due to REST API session created with GUI user credentials.

Verified in rhevm-3.2.0-10.26.rc.el6ev (sf17).
After login into webadmin as user admin@internal, there are only two events "User admin@internal logged in." listed as mentioned in comment #29.
According to BZ release notes ("Doc Text" field), no subsequent login events are then reported, because no keep-alive requests are being made. Instead, a session timeout is set via HTTP header "Session-TTL: 360".