MFA Design That Keeps Workspace App and API Clients Working
An insurer publishes Citrix Workspace through a Citrix Gateway on ADC 13.1 with StoreFront and two STA servers. There are 6,500 users: 4,000 on the corporate LAN and 2,500 external. Policy requires external users to authenticate to Microsoft Entra ID via SAML and then enter an LDAP-backed OTP, while internal users must get Kerberos SSO with no prompt. A BI team calls a REST API through the same public hostname with a service account and no browser. Today one AAA vserver with one SAML policy is bound to the Gateway vserver. Symptoms: internal users are redirected to Entra ID, the BI scripts receive HTTP 302 and time out after 20 seconds, and since a recent identity change some external users loop between the IdP and the Gateway. Split DNS exists, the company has one public IP and a wildcard certificate, and the IdP team refuses to create a second app registration.
1. Compare a single Gateway vserver with source-IP-based nFactor branching against separate Gateway vservers. What do you recommend?
Read the worked answer
Single vserver plus nFactor branching is the tidier-looking option: one hostname, one certificate, and a policy that chooses a Kerberos factor for LAN source ranges and a SAML-to-OTP label for everything else. It fails in practice for three reasons. Corporate ranges are not a reliable identity signal once guest Wi-Fi, home VPN pools, and carrier NAT appear; a misclassified external user silently gets SSO and a policy exception. Second, the two populations need different session policies (EPA, split tunnelling, timeouts), which is easier to reason about on separate vservers than as policy overrides. Third, native clients and scripts cannot complete an interactive factor chain.
Separate Gateway vservers on the same public IP, distinguished by hostname and SNI under the wildcard certificate, with split DNS pointing internal users at gateway-internal and everyone else at gateway, is the recommendation. Each vserver gets its own certificate binding, session policy, and authentication vserver, and the external one carries the nFactor graph: SAML policy label to an OTP policy label, terminating on failure rather than falling through.
Use nFactor rather than two independent factors on the external vserver so the OTP prompt appears only after the IdP assertion is validated, and so a failed OTP produces an error page instead of re-entering SAML. The IdP needs one app registration pointing at the external vserver's assertion consumer URL, which satisfies the IdP team's constraint.
2. Why do the BI team's API calls loop on 302s, and what is the correct fix that does not weaken MFA for humans?
Read the worked answer
The Gateway is applying a browser authentication flow to a non-browser client. An unauthenticated request to a SAML-protected Gateway vserver is answered with a redirect to the IdP; the script does not follow redirects, or follows them into an HTML login form it cannot fill, and times out. Even a script that follows redirects cannot complete interactive sign-in and OTP.
Do not just add the service account to an OTP bypass list on the user-facing vserver. That puts a MFA-exempt credential on a hostname reachable from the internet and violates the intent of the policy.
Recommended fix: publish the API on a separate vserver with a machine-appropriate authentication model. Best is OAuth 2.0 client credentials at the IdP, with the ADC validating the resulting JWT (signature, issuer, audience, expiry) and mapping a claim to the session identity. If the IdP cannot issue tokens for this use case, use a dedicated LB or Gateway vserver with 401-based LDAP or certificate authentication, restricted by source range to the BI egress addresses, with the service account excluded from interactive logon and rotated on a schedule.
Either way, keep it on a separate hostname (api.example.com) so the browser flow on gateway.example.com is untouched, and verify that the authenticated username is populated in the AAA session so Gateway Insight attributes the traffic to a user rather than an IP address.
3. External users loop between the IdP and the Gateway after a recent identity change. How would you diagnose it, and what are the likely causes?
Read the worked answer
A loop means the Gateway accepts the SAML assertion, then something downstream rejects the session and re-initiates authentication. Work outward from the assertion.
Evidence to collect: ADC ns.log and AAA debug output for the affected users' session IDs; a SAML tracer trace showing the assertion attributes; the StoreFront and STA logs for the same timestamps; and the IdP sign-in log showing repeated successful sign-ins.
Likely causes, in order:
- NameID mismatch. If the identity change altered the UPN and the IdP now issues a different NameID, or the NameID format changed from persistent to emailAddress, the ADC session is valid but StoreFront cannot map the user, so the session is torn down and the client retries. Check the SAML SP configuration and the NameID format against what the IdP sends.
- Factor graph falling through. If the OTP label failure is configured to return to the SAML label instead of terminating, any OTP failure becomes an infinite loop rather than an error. Inspect the nFactor graph and force a clean failure page.
- Clock skew. Assertion validity windows are short; if the ADC or IdP clock drifts, assertions are accepted then immediately judged stale. Verify NTP on ADC, IdP, and StoreFront.
Fix and regression test: correct the NameID mapping, terminate rather than loop on factor failure, and re-test with an account whose UPN has recently changed before closing the incident.