A SaaS company hosts two applications on one name, and only one of them uses SAML. The synthetic web test targets the application that does not use SAML. How should that test authenticate?
Select an answer to reveal the explanation.
Short Explanation
You knock on the door you were sent to, not on the neighbor who happens to share the front hallway. Only one application on that host uses SAML, and the test targets the other one, so you authenticate the application under test. The trap is borrowing the neighbor SAML method, skipping credentials, or substituting a network-loss test that does not log in.
Full Explanation
Two applications share a host name, and only one of them authenticates with SAML. The synthetic test is aimed at the application that does not use SAML, so the test must authenticate that application, not the neighbor that happens to share the host. Applying SAML from the neighboring application uses a different method than the application under test uses, so a pass or a fail would describe the neighbor login. Running the transaction with no credentials on the application under test skips authentication and cannot show whether a real remote user can sign in. Replacing the web test with a network-loss test that does not log in drops the transaction down to a path measurement, which never presents SAML or any other application login. Exam caveat: a shared host name is not a shared login; the credential and the method follow the application under test. Operational check: confirm the transaction URL and the login step belong to the non-SAML application, and that the script does not submit the neighbor SAML flow.