IBM Verify

 View Only

 ISVA 10.0.7 - 500 Internal Server Error when POP has elevated authentication level

Brian Thompson's profile image
Brian Thompson posted Sat January 11, 2025 11:21 AM

I am using IBM Security Access Manager 10.0.7 and I'm getting an immediate internal server error from PD after attaching a POP with IP Auth set to Any Other Network to 3 instead of being directed to the local response redirect for login. I have confirmed that if I detach the POP I am properly redirected to the login process, and if I drop the Authentication Level in the POP to 1 it works, but anything 2 or higher fails.  The only thing I can find in the pdweb.debug log is the request and the 500 response: 

2025-01-09-11:58:56.546-08:00I----- thread(4) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- Browser ===> PD -----------------
Thread 4; fd 258; local x.x.x.x:1234; remote x.x.x.x:1234
GET /en/my-accounts/list HTTP/2.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
accept-encoding: gzip, deflate, br, zstd
accept-language: en-US,en;q=0.9
host: tstbdvsamw03-ai2.octfcu.org:8048
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
sec-ch-ua-mobile: ?0
priority: u=0, i
sec-fetch-site: none
upgrade-insecure-requests: 1
sec-fetch-dest: document
sec-fetch-user: ?1
sec-ch-ua-platform: "Windows"
sec-fetch-mode: navigate
sec-ch-ua: "Google Chrome";v="131", "Chromium";v="131", "Not_A Brand";v="24"

2025-01-09-11:58:56.547-08:00I----- thread(4) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:285: ----------------- Browser <=== PD -----------------
Thread 4; fd 258; local x.x.x.x:1234; remote x.x.x.x:1234
HTTP/2.0 500 Internal Server Error
content-length: 1101
content-type: text/html; charset=UTF-8
date: Thu, 09 Jan 2025 19:58:56 GMT
p3p: CP="NON CUR OTPi OUR NOR UNI"
x-frame-options: DENY
x-content-type-options: nosniff
cache-control: no-store
x-xss-protection: 1
content-security-policy: frame-ancestors 'none'
strict-transport-security: max-age=31536000; includeSubDomains
session-timeout: 3600
pragma: no-cache
Set-Cookie: PD-S-SESSION-ID=0_eU2vGACi3M9acvtF1WWMZku6a/OdJgNk0LbLYJxmPT9/EkNWFqA=; Path=/; Secure; HttpOnly

Enabling the full pdweb trace, I did also find this error:

DPWWA1130E Authentication level mismatch when performing reauthentication

...which, I'm not reauthenticating.  I'm in a fresh incognito window, no session, just as soon as I attempt to access the protected resource (/en) I get an immediate 500 internal server error from PD. We have a higher environment where this is operating just fine and I've checked everything I can think to check across the webseal config, the object space, ACLs, POPs... it's all identical.

If I manually navigate to our login application, authenticate, then navigate to /en everything behaves fine.  It's just the unauthenticated session not getting pushed for authentication on the resource itself.

Any help would be greatly appreciated!

Laurent LA Asselborn's profile image
Laurent LA Asselborn

Hi Brian,

What do you have configured in the [authentication-levels] stanza?

If your config is just this:

level = unauthenticated
level = password

then the level 2 does not exist and it is normal that a request for a level 2 authentication is not accepted.

Kind regards,

Laurent

Brian Thompson's profile image
Brian Thompson

Apparently I marked this as a question, not a thread so I can't respond directly, but our authentication levels are set as such:

level = unauthenticated
level = password
level = oauth
level = ext-auth-interface

And it's set this way across both environments.

Tuhina Banerjee's profile image
Tuhina Banerjee

Did you find a solution to this problem? I have a similar issue, but for authentication level 0. All the IPs added to the POP gives a forbidden error quite strangely,