WindowsDesktopSSO: untrustedToken, context and notfound errors make the module ignored instead of failed #1174

Summary

WindowsDesktopSSO returns LOGIN_IGNORE instead of failing when the Kerberos token is rejected by the module's own checks:

• the security context cannot be established (context);
• the token's realm is not in Trusted Kerberos realms (untrustedToken);
• Search for Kerberos user is enabled and the user is not found in the realm (notfound).

The user is not logged in, but the module counts as ignored rather than failed: no authentication failure is recorded for it, and the chain behaves as if the module had not taken part.

Cause

authenticateToken runs inside Subject.doAs(..., PrivilegedExceptionAction) and throws AuthLoginException for the three cases above (L291, L313, L330). Subject.doAs wraps it in a PrivilegedActionException.

In process(), the catch (PrivilegedActionException pe) branch unwraps the cause and handles it only if (e instanceof GSSException). Any other cause, including the AuthLoginException, falls through without being rethrown, and process() returns the initial result = LOGIN_IGNORE. The catch (AuthLoginException e2) below it is never reached, because the exception arrives wrapped.

Impact

With trusted realms restricted or user lookup enabled, a token from an untrusted realm, or for a user missing from the realm:

• is not audited as a failed authentication for the module;
• does not count towards account lockout and does not trigger the failure URL;
• lets the chain continue as if the module had been skipped.

The error is logged (debug.error), so the rejection itself works: the user does not get a session from this module.

Expected

Rethrow the unwrapped AuthLoginException from the PrivilegedActionException branch (and wrap any other non-GSS cause in AuthLoginException(..., "auth", ...)), so the module fails with the specific error key.

Test

PR #1172 adds a Kerby-based module test whose untrusted-realm case pins the current LOGIN_IGNORE result (see "Note for reviewers" there). Once this is fixed, that assertion has to change to expect an AuthLoginException with untrustedToken.