Summary
Introduce a public utility class (e.g. GeoSessionUtils) that centralises reading and writing of resolved geo data to the AuthenticationSessionModel as authNotes. This allows other authenticators in the same flow to access geo context without performing their own GeoIP lookup.
Motivation
Currently, geo data resolved during authentication is not accessible to other authenticators running later in the same flow. A common use case is a 2FA authenticator that sends a push notification or email OTP to the user. By reading the resolved geo data from the session, it could enrich the message with location context to help the user recognise a legitimate login attempt:
"A login attempt was detected from Frankfurt, Germany. If this was you, please approve."
Without a shared mechanism, such an authenticator would have to either perform its own GeoIP lookup or have no location context at all.
Proposed Change
1. GeoSessionUtils public utility class
A utility class that wraps reading and writing geo data to the auth session, and exposes an enum of well-known note keys:
public class GeoSessionUtils {
public enum GeoSessionNote {
IP("geoaware.ip"),
COUNTRY("geoaware.country"),
CITY("geoaware.city"),
REGION("geoaware.region"),
LATITUDE("geoaware.latitude"),
LONGITUDE("geoaware.longitude");
private final String key;
GeoSessionNote(String key) { this.key = key; }
public String getKey() { return key; }
}
public static boolean isResolved(AuthenticationSessionModel session) {
return session.getAuthNote(GeoSessionNote.IP.getKey()) != null;
}
public static void writeGeoData(AuthenticationSessionModel session, GeoData data) {
session.setAuthNote(GeoSessionNote.IP.getKey(), data.getIp());
session.setAuthNote(GeoSessionNote.COUNTRY.getKey(), data.getCountry());
// etc.
}
public static GeoData readGeoData(AuthenticationSessionModel session) {
// read all notes and return as GeoData
}
}
Third-party authenticators can use this class to access geo data via the documented GeoSessionNote keys without depending on any internal implementation.
2. All GeoAware authenticators write to the session
All GeoAware authenticators should write their resolved geo data to the auth session via GeoSessionUtils, and skip writing if data is already present:
if (!GeoSessionUtils.isResolved(authSession)) {
GeoData data = geoIpProvider.resolve(ip);
GeoSessionUtils.writeGeoData(authSession, data);
}
GeoData data = GeoSessionUtils.readGeoData(authSession);
3. Event listener reuses session data where available
The LOGIN event listener should also check GeoSessionUtils before resolving. If a GeoAware authenticator already ran in the flow, the listener reuses that data. If not (e.g. no GeoAware authenticator is in the flow), it falls back to its own lookup as today:
if (GeoSessionUtils.isResolved(authSession)) {
geoData = GeoSessionUtils.readGeoData(authSession);
} else {
geoData = geoIpProvider.resolve(ip);
}
// persist to DB entity as usual
4. New GeoAware IP Enricher authenticator
For admins who want geo data available to downstream authenticators but do not need any GeoAware policy enforcement (block, alert, disable account), a new lightweight authenticator should be provided.
It does exactly one thing: resolve geo data and write it to the auth session via GeoSessionUtils. It can be placed early in any flow so that all subsequent authenticators, including the existing GeoAware IP and GeoAware Device, have access to the resolved data.
Acceptance Criteria
Summary
Introduce a public utility class (e.g.
GeoSessionUtils) that centralises reading and writing of resolved geo data to theAuthenticationSessionModelasauthNotes. This allows other authenticators in the same flow to access geo context without performing their own GeoIP lookup.Motivation
Currently, geo data resolved during authentication is not accessible to other authenticators running later in the same flow. A common use case is a 2FA authenticator that sends a push notification or email OTP to the user. By reading the resolved geo data from the session, it could enrich the message with location context to help the user recognise a legitimate login attempt:
Without a shared mechanism, such an authenticator would have to either perform its own GeoIP lookup or have no location context at all.
Proposed Change
1.
GeoSessionUtilspublic utility classA utility class that wraps reading and writing geo data to the auth session, and exposes an enum of well-known note keys:
Third-party authenticators can use this class to access geo data via the documented
GeoSessionNotekeys without depending on any internal implementation.2. All GeoAware authenticators write to the session
All GeoAware authenticators should write their resolved geo data to the auth session via
GeoSessionUtils, and skip writing if data is already present:3. Event listener reuses session data where available
The
LOGINevent listener should also checkGeoSessionUtilsbefore resolving. If a GeoAware authenticator already ran in the flow, the listener reuses that data. If not (e.g. no GeoAware authenticator is in the flow), it falls back to its own lookup as today:4. New
GeoAware IP EnricherauthenticatorFor admins who want geo data available to downstream authenticators but do not need any GeoAware policy enforcement (block, alert, disable account), a new lightweight authenticator should be provided.
It does exactly one thing: resolve geo data and write it to the auth session via
GeoSessionUtils. It can be placed early in any flow so that all subsequent authenticators, including the existing GeoAware IP and GeoAware Device, have access to the resolved data.Acceptance Criteria
GeoSessionUtilsutility class is introduced withGeoSessionNoteenum,isResolved(),writeGeoData(), andreadGeoData()methodsGeoSessionUtilsLOGINevent listener reuses auth session data viaGeoSessionUtilsif already resolved during the flowGeoAware IP Enricherauthenticator is introduced that only resolves and writes geo data without any policy enforcementGeoSessionUtilsandGeoSessionNoteare documented for third-party authenticator authors