At a logistics hub, the scheduling application redirects browsers through the corporate identity provider for single sign-on, but the synthetic test posts credentials only to the application host. What should the test do?
Select an answer to reveal the explanation.
Short Explanation
Single sign-on is a front desk that sends you down the hall to the identity provider before it will stamp your badge. You configure the logistics test to follow that redirect the way a user browser does. Posting a password only to the application, skipping credentials, or probing for loss stops short of the real login.
Full Explanation
Users reach the scheduling application only after the browser follows the single sign-on redirect to the corporate identity provider and completes sign-on there. The synthetic test has to follow that same path. Posting a basic password only to the application host uses a different method and ignores the redirect the real login depends on, so the test never arrives at the identity provider. Calling the application with no credentials and treating the redirect as a successful login scores the hop away from the application as if the session had been granted. A network-loss test that does not attempt sign-on can show whether packets are dropped toward the hub, and it never follows the redirect or establishes the single sign-on session the schedule page requires. Exam caveat: a failure to post a password on the application host is not an application outage when the application does not accept the password there. Operational check: trace the synthetic transaction and confirm it leaves the application host, completes sign-on at the identity provider, and returns to the same scheduling page a dispatcher reaches. If the test never contacts the identity provider, it is not measuring the login users use.