i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

In the current state we are using /authsvc based services for OTP mechanisms, we are trying to convert them to rest based /apiauthsvc

In the new rest based api approach, when i trigger MFA for sms/totp it working as expected but when i choose email for the first time and enter valid OTP code still its triggering the MFA for multiple times.

1.) client triggers the resource

2) webseal intercepts the resource, start the MFA, enter valid OTP code

3) webseal is redirecting back to the intercepted resource

4) webseal again intercepting for the second time, starting the MFA (this is happening only for email)

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

And you're using Access Policies to protect this resource. 

What does your policy look like? Are you singling out the other mechanisms in your policy? 

In the current state we are using /authsvc based services for OTP mechanisms, we are trying to convert them to rest based /apiauthsvc

In the new rest based api approach, when i trigger MFA for sms/totp it working as expected but when i choose email for the first time and enter valid OTP code still its triggering the MFA for multiple times.

1.) client triggers the resource

2) webseal intercepts the resource, start the MFA, enter valid OTP code

3) webseal is redirecting back to the intercepted resource

4) webseal again intercepting for the second time, starting the MFA (this is happening only for email)

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

yes, we are using Access policies for this resource. 

First policy calling the infomap to retrieve the sms/email/preferred mfa methods from LDAP and update the session context attributes.

Second is the one-time password authentication policy mechanism.

And you're using Access Policies to protect this resource. 

What does your policy look like? Are you singling out the other mechanisms in your policy? 

In the current state we are using /authsvc based services for OTP mechanisms, we are trying to convert them to rest based /apiauthsvc

In the new rest based api approach, when i trigger MFA for sms/totp it working as expected but when i choose email for the first time and enter valid OTP code still its triggering the MFA for multiple times.

1.) client triggers the resource

2) webseal intercepts the resource, start the MFA, enter valid OTP code

3) webseal is redirecting back to the intercepted resource

4) webseal again intercepting for the second time, starting the MFA (this is happening only for email)

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

never mind, after removing the first policy it started working for email as well. Thanks for your support Nye. 

do i have any other options, i would like to get the latest email info from LDAP then start the MFA for email.

yes, we are using Access policies for this resource. 

First policy calling the infomap to retrieve the sms/email/preferred mfa methods from LDAP and update the session context attributes.

Second is the one-time password authentication policy mechanism.

And you're using Access Policies to protect this resource. 

What does your policy look like? Are you singling out the other mechanisms in your policy? 

In the current state we are using /authsvc based services for OTP mechanisms, we are trying to convert them to rest based /apiauthsvc

In the new rest based api approach, when i trigger MFA for sms/totp it working as expected but when i choose email for the first time and enter valid OTP code still its triggering the MFA for multiple times.

1.) client triggers the resource

2) webseal intercepts the resource, start the MFA, enter valid OTP code

3) webseal is redirecting back to the intercepted resource

4) webseal again intercepting for the second time, starting the MFA (this is happening only for email)

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

And you're using Access Policies to protect this resource. 

What does your policy look like? Are you singling out the other mechanisms in your policy? 

In the current state we are using /authsvc based services for OTP mechanisms, we are trying to convert them to rest based /apiauthsvc

In the new rest based api approach, when i trigger MFA for sms/totp it working as expected but when i choose email for the first time and enter valid OTP code still its triggering the MFA for multiple times.

1.) client triggers the resource

2) webseal intercepts the resource, start the MFA, enter valid OTP code

3) webseal is redirecting back to the intercepted resource

4) webseal again intercepting for the second time, starting the MFA (this is happening only for email)

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

Hi Nye,

I need your help here, we are noticing weird behavior, not sure what we are missing

1.calling protected resource
2.intercepting the resource(POP--> rba-pop)
3.calling one-time password mechanism
4.triggered MFA for email(/mga/apiauthsvc)
5.entered the valid OTP code
6.re-triggering the OTP again for the second time, instead of redirecting back to the protected resource

i have attached the network trace snapshots and log

appreciate your help here.

And you're using Access Policies to protect this resource. 

What does your policy look like? Are you singling out the other mechanisms in your policy? 

In the current state we are using /authsvc based services for OTP mechanisms, we are trying to convert them to rest based /apiauthsvc

In the new rest based api approach, when i trigger MFA for sms/totp it working as expected but when i choose email for the first time and enter valid OTP code still its triggering the MFA for multiple times.

1.) client triggers the resource

2) webseal intercepts the resource, start the MFA, enter valid OTP code

3) webseal is redirecting back to the intercepted resource

4) webseal again intercepting for the second time, starting the MFA (this is happening only for email)

Ok. Let's take a step back, we've covered a bit. And need to rebaseline. 

So, what's the new state? Vs the desired state?

Thank so much Nye, it worked for us.

when i choose otp.user.otp-method.id: "email" as  email, after entering the OTP code its redirecting back to the initial target url again webseal is intercepting the request starting the MFA, this is happening only for email but not for sms/totp.

2025-12-11-14:12:54.518-05:00I----- thread(145) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 81965 usec
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost:service/secure/mfa
2025-12-11-14:12:54.527-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: https://myhost:service/secure/mfa)
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728
2025-12-11-14:12:54.547-05:00I----- thread(145) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=gVseYXXHZ2NHGGzJM31r5uzK5qFMxf7Ef390rQVXnyXG7tL2KojzpnTmHoCdbGOadVpKVyeuUgpIj1zENY0hvzVbBY85prujycz8Oe4q9GzNzuw25obMCPh9VHD90kpT, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728)
2025-12-11-14:12:54.548-05:00I----- thread(145) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------
Thread 145; fd 259; local 10.205.45.16:62664; remote 10.205.42.16:8443
GET /sps/apiauthsvc?TransactionId=9b1d4205-3b43-4050-bfb1-50649b210728 HTTP/1.1

This might be related to changing the default values for the EAI Flags:

https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/
In the Reverse Proxy Configuration File:

[eai]eai-flags-header = am-eai-flags

If the value isn't the one above, it will revert to similar behaviour as the standard Authsvc. 

Hey, 

It looks like thats related to 'follow-redirects-for' in the Reverse Proxy Configuration file. 

Although if you're getting a 204 - I'm not sure if it will give that experience or not. 

Thanks Nye for responding to the thread, we are using API Auth service

we have one application(App1) in different proxy which is implemented using API Auth service which is working as expected, but not in other application(App2) not sure what configuration are we missing in App2, what we have noticed in logs for App1 is highlighted below, can you please let me know what configuration triggers this log statements: 

App1 flow:

1) trigger the resource from Single Page application

2) webseal intercepted the resource, started the MFA

3) once the MFA process completes webseal is redirected back to the backend application to process the request

App1 Logs:

 thread(101) trace.pdweb.debug:3 /build/isam/src/i4w/pdweb/webseald/junctions/remote/framework/ThirdPartyJunction.cpp:4429: Processing time of the junction request: 59880 usec
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:368: It has been determined that the redirect is destined for the local host/port: https://myhost/mfa/start
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: https://myhost/mfa/start)
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:376: It has been determined that the redirect is destined for the local host/port as it is for a server relative URL: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52
 thread(101) trace.pdweb.debug:5 /build/isam/src/i4w/pdweb/webseald/http/server/handle-call.cpp:399: This redirect will be handled internally as the request URL, /mga/sps/apiauthsvc?StateId=VPXiQXzbz0YUE4kNTPf2tvslnFujb0Oa5ZOoUpFr8PIsoYTWQ08uvTJJmLKwedei1XyXdp1NnDEjChztueeWanWUVesaxRGIvshW9afvsJI8i2IidFM3gax6bv1jUlss, matches one of our configured URLs (redirect: /mga/sps/apiauthsvc?TransactionId=e3b7a291-14ed-4bfa-a0cc-a820ceba0d52)

Hi Raghavendra, 
Are you using the "API" Auth service? or are you using a regular authservice (HTML) flow? 

The API Auth service, will return a 204 upon completion. As the API client might not handle the 302. 

We've had some patterns elsewhere (Some of the OOTB MMFA flows for example) that complete it with the API flow, until the 'last' page - which uses the regular auth service flow. 

1) API Auth service (OTP Challenge)
2) API Auth Service (OTP Response) 
3) simple "Infomap" response that can be identified - and then have REST client to primary browser flow - which can then trigger the cached redirect. 

we have assigned the rba-pop(eas-trigger as trigger_rba_eas) for the resource and assigned the "one-time password" authentication policy.

Explain what you mean by: which then we are intercepting the request

How are you doing that precisely?

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks

i am triggering this resource https://<hostname>/myapp/myresource, which then we are intercepting the request to complete the one-time password mechansim, once the OTP flow completes its giving 204 response instead of returning back to the intercepted url, please let me know for any suggestions. Thanks