The tiqr polling requests are hard (impossible) to match to an authentication/registration

[phavekes]

This issue is imported from pivotal - Originaly created at Sep 2, 2024 by Pieter van der Meulen

Polling requests are logged in the access logs, they are part of an authentication or registration. But when a registration/authentication fails during the polling process. The actual polling request that failed can not be matched to the request that failed at the Tiqr server.

To improve correlation between the two, we want to add a something that correlates with the session id as a request parameters of the polling requests that can easily be correlated to the authentication / enrollment session. Because the only identifier used in polling the the session cookie, it makes sense that this ID is bound to that.

Security must be taken in account, as we should never disclose the contents of the session cookie. Investigate what is a best practice here.

Currently Stepup-tiqr uses the symfony session ID (SessionInterface::getId()) a session ID with the tiqr-server-libphp. Is this session ID safe to reveal? There is no requirement to use this as the session ID between Stepup-tiqr and tiqr-server-libphp, we could generate a new random sessionId for that purpose and store it's value in the symfony session, and use (a part of) that as the session correlation.

The polling requests:
/authentication/status?correlation-id=abcd1234
/registration/status?correlation-id=abcd1234

[phavekes]

@pmeulen 

Do you think it would be useful to add the correlation id (session id hash) on this page as well?

Or is that not useful? (Maybe because if you get that page, there is never an active session?) (Johan Kromhout - Nov 19, 2024)

[phavekes]

I expect the relation between the correlation ID and the request ID (and also the SARI) to be visible in the logs.
The HTTP access logs will have correlationID + requestID.
The application log will have requestID + correlationID and SARI on different log messages in different combinations.

The correlationID is sent for ajax requests, and these would never show this error page. So if we do get this error it's in the front channel and from a server error. If the error is because there is no session (cookie) present, we couldn't get the correlationID from the session like you mention. If there is a session then the error is probably unrelated to cookies and the correlationID would be of little use.

My thoughts: adding correlation ID here is probably not very useful and would make an already somewhat intimidating error screen worse in that respect. IF we do find in practice that we need the correlationID in this screen, we add it then. We're already making many improvements that should help us.

(Pieter van der Meulen - Nov 19, 2024)