Are you wanting to authenticate with a cert (mTLS), then you need to protect the backend API so you technically need to authorize or authenticate the authorization header access token as well before allowing the flow to continue to the backend api junction?
In flows I have done, I authN the x509 cert then when the call to the junction/backend happens, and it happens as the "user" (client/account) associated with the cert. Hence, the mTLS cert is then associated (via user name mapping or eai or whatever) a user ID with the same ID as the oauth client ID. The authorization header is just sent on through to the backend with the -b ignore in place.
However, I think what you may be saying is you need to authenticate the cert, then you need to protect the API using IVIA webseal based on that access token (as if basically mTLS authentication was not involved where the webseal essentially allows/denies based on the access token to some API backend)? Hence, no tight association between the cert and the api client id?
If so, I'm wondering if oauth auth would help. That is what I have used on pools without mTLS/x509 auth. However, to combine that with x509 auth, maybe the authentication-levels could be set so that level 1 is ssl, level 2 is oauth. Then essentially it would "step-up" through oauth. You probably would need to set [step-up] verify-step-up-user = false otherwise the cert user would need to match the oauth client id. Then put a POP on the API junctions requiring level 2? Or instead of oauth auth use an eai to authenticate the custom access token if those are not valid access tokens to from the runtime.
Anyway, just some ideas. I'm curious what you end up doing.
Matt
------------------------------
Matt Jenkins
------------------------------
Original Message:
Sent: Tue May 27, 2025 04:53 AM
From: Jürgen Hitt
Subject: Custom API protected by Verify Access
Hi Philip,
yes we know -b ignore option. However we are looking for a solution to provide standard OAuth-Flow to the consumers, even if the API itself is none standard implementation.
I recognized that my original message contained a mistake. I corrected it now.
Do you have any hint in which direction we can investigate ? Maybe something like JWT Junction, API-Protection, Junction -S (but for application/json) or any other approaches ?
Thanks, Juergen
------------------------------
Jürgen Hitt
Original Message:
Sent: Tue May 27, 2025 01:09 AM
From: Philip Nye
Subject: Custom API protected by Verify Access
Hi Jurgen,
You might be simply looking for the -b ignore option on a junction?
So that you require 'authentication' with MTLS, then the Authorization header is passed through?
Or do you want to do a tighter binding between the Authorization header and the Authorization Header?
------------------------------
Philip Nye
Senior Product Manager - IBM Verify
Original Message:
Sent: Mon May 26, 2025 06:31 AM
From: Jürgen Hitt
Subject: Custom API protected by Verify Access
Hello,
we need to protect an Backend-API with Verify Access that behaves like follows:
Authentication request to API:
curl -X 'POST' \
'https://api/v1/bind' \
-H 'accept: application/json' \
-H 'Authorization: SHA512 0213:5b2c124...' \
-H 'Content-Type: application/json' \
-d '{
"authType": "simple",
"user": "test",
"password": "test01"
}'
Successful authentication response:
{
"accessToken": "SHA512 0213:5b2c124..."
}
In case "authorization" header is supplied with value of "accessToken" no new authentication is performed and access to API is granted.
Behavior of the API is close to OAuth Client Credentials flow.
We want to use Verify Access to act as secure access gateway and perform "certificate" authentication, since password only is not allowed by IT-Security. AAC/Fed/RP 11.x is in used (including certificate auth). We want avoid double authentication flow for clients. Ideally we want to achieve some standard OAuth flow with Verify Access.
Is there some advice how this can be achieved ?
Regards,
Juergen
------------------------------
Jürgen Hitt
------------------------------