Access token authenticator handles expired tokens and inactive users incorrectly

Issue Summary

When using a personal access token to authenticate, if the:

• access token is expired, or
• the user is inactive in LDAP

the token authenticator opts out of the authentication processing, rather than rejecting the token. This results in the system attempting subsequent authenticators, including the Crowd authenticator that handles username/password authentication. The token is sent as a password and rejected, which increments the CAPTCHA counter for the user. This eventually leads to the user account being locked.

Steps to Reproduce

1. Set up a personal access token for a user
2. Mark that user inactive in Crowd
3. Attempt to authenticate using basic authentication with the token as the password

Expected Results

The token is rejected, because the user is not active in LDAP, and normal username/password authentication is not attempted. The user's CAPTCHA counter is not incremented.

Actual Results

The token authenticator logs that the user is inactive and then opts out rather than rejecting the token. The system attempts username/password authentication with the token, which fails, and the user's CAPTCHA counter is incremented.

The following message is logged:

2021-01-01 01:01:01,010 INFO  [http-nio-7990-exec-1] *RLCFSXx373x31758x0 1.1.1.1 "GET /rest/api/1.0/projects/KEY/repos/slug/commits HTTP/1.1" c.a.b.i.a.DefaultAccessTokenService User "jdoe" attempted to authenticate via a personal access token, but is no longer active in the underlying user directory. The request has been blocked.

Workaround

There is no workaround for this behavior. Generally if an inactive user is CAPTCHA'd it shouldn't matter, since they're not active. If necessary, the CAPTCHA can be cleared by any ADMIN or SYS_ADMIN user using the REST API. (Note that if the inactive user is a SYS_ADMIN, only another SYS_ADMIN user can clear the CAPTCHA.)