Which IIQ version are you inquiring about?
Version 8.3
Please share any other relevant files that may be required (for example, logs).
oauth.log (3.14 KB)
Share all details related to your problem, including any error messages you may have received.
Hi all,
We’ve noticed an extremely large number of loginFailure audit events and are having trouble pinning down exactly why they’re occurring. It’d be good to know if a) anyone can reproduce this, and b) if anyone knows why it’s happening.
Context:
In our environment, we have a plugin that exposes REST endpoints. These endpoints are only accessed normally by a microservice that authenticates to IIQ using OAuth. Human users login with their AD account credentials (passthrough auth)
The problem:
I’ve noticed that every request with a bearer token causes a loginFailure audit event, but the request succeeds. Basic authentication does not cause this. This can also be seen when using the SCIM endpoints, so this problem is not exclusive to our plugin.
Investigation so far:
(see attached logs)
- This is definitely occurring once per authenticated request using OAuth. Reproduced in Postman. Requesting a token does not trigger it, only a request using the bearer token.
- As mentioned above, using basic authentication instead does not cause the loginFailure
- Following the logs, you can see the SailPointContextRequestFilter is triggered to add a context to the request.
- After that, the bearer token is decoded, triggered by BaseOAuthRestFilter
- You can then see that the ADLDAPConnector is invoked to try and find a user with sAMAccountName=OAUTH_CLIENT_ID
- This obviously fails, then we fall back to internal auth (properly validating the bearer token), which then works
- I’ve verified in web.xml that we’ve not configured anything unusual that could be triggering this
Ideal outcome:
An OAuth request doesn’t cause a loginFailure audit every single time.
Potential theories:
- IIQ doesn’t know that this is a proxy access token and first tries to find a user via passthrough authentication before failing and falling back to internal auth and therefore this is expected behaviour
- Something is wrong with our AD application configuration and it shouldn’t even be trying to using it to authenticate in this scenario
- Something is broken with IIQ’s OAuth flow
This isn’t a blocker, but the noise does lower our visibility of genuine login failures. These events currently account for 90% of all of our audit events.