Restructure IP Login Implementation
Date: 2025-02-06
Status: rejected - IP login will be shut off by the end of the year, no more work should flow into this
Context
The current IP login implementation involves a lot of checks in both the configfrontend monolith and the remix-sso library used by the Statista 4.0 apps. This setup requires two implementations of the same logic, one in PHP and one in the remix-sso library, which have to be kept in sync. The existing mechanism is documented in docs/references/auth-methods/iplogin.md.
Additionally, the current implementation has led to unresolved issues such as unwanted IP login attempts and IP mismatch problems. As a workaround for the missing client-side check for cookie support, we implemented the so-called "Fernando solution" which relies on additional redirects between the monolith and the remix-sso app with an additional cookie. Details are documented in docs/explanations/fernando_solution.md.
This ADR proposes to restructure the IP login mechanism to come up with a unified solution for both the monolith and the Statista 4.0 apps, which also addresses the known issues.
Decision
In order to unify the IP login logic for both the monolith and Statista 4.0 apps and mitigate existing problems, we want to restructure the IP login implementation by making the following changes:
- Move the IP CIDR check from behind Auth0 (using
platform-sso-services) to theremix-ssoapp.- This also requires moving the Redis cache and its population function (
ip-login-synchronizer-service) to theremix-ssodeployment unit. - The IP login method is removed from Auth0, including the
platform-sso-servicesand theip-login-synchronizer-service. - The
remix-ssoapp will directly query the IP Redis to check if the IP is allowed to login. - The implementation of
/sso/iploginis changed to query the IP Redis and perform an ID login if the IP is allowed to login.
- This also requires moving the Redis cache and its population function (
- Provide the
isIpLoginAllowedinformation to the client, e.g., by adding a flag to thesso/userendpoint (or create a separate endpoint if that is more appropriate). - Deliver a React-independent JavaScript library with
SSOContextProviderwhich can be integrated into theconfigfrontend(like the current ReactSSOContextProvideris used in the Statista 4.0 application).- This context provider calls the
sso/userendpoint and decides if an IP login attempt is made based on the response and further client-side checks integrated into the JavaScript code.
- This context provider calls the
- Remove the code to trigger IP login (
IPLoginListener) from the monolith. The user is set in the PHP session if a valid__ssocookie is present as it is currently already implemented inTokenValidatorListener. - Ensure the
__sso_iplogincookie is only checked by theremix-ssoapp, which maintains the cookie:- This will fix IP mismatch problems, as the
remix-ssoapp is the only one that needs to evaluate the IP, i.e., the monolith does not need to check the IP anymore.
- This will fix IP mismatch problems, as the
- Perform the cookie support check directly in the JavaScript frontend code, allowing the removal of the Fernando solution.
- This will reduce the number of redirects between the monolith and the
remix-ssoapp and make the__sso_cookie_checkercookie obsolete.
- This will reduce the number of redirects between the monolith and the
Consequences
Positive Consequences
- The restructuring will unify the IP login logic and reduce dependency on different headers and cookies.
- The monolith will no longer handle IP login checks itself, reducing its complexity and maintenance overhead.
Negative Consequences
- The IP login attempt will cause a flickering effect in the frontend as the IP login is attempted after the initial page load.
- The
remix-ssoapp will need direct access to the users' database, which requires an additional migration path in the future. Having the IP login behind Auth0 would have allowed migrating the IP login data together with the user data. - As we remove IP login as a separate login connection from Auth0, the IP login string in the login ID cannot be used as a workaround for double login. A different solution will be needed.
- IP login cannot be supported for applications directly interacting with Auth0. This decision will deprecate the IP login as a supported login method in the future.