Library patrons are not in Active Directory, but staff are. Staff must open city HR and ticketing SaaS without a password taped under the keyboard. What identity approach should the EUC technician describe?
Select an answer to reveal the explanation.
Short Explanation
Staff SaaS should use the same city badge-behind-the-login the directory already knows, not a sticky note under the keyboard. Workspace ONE Access federates that civic identity into HR and ticketing. Patron kiosks and DEM password files are not an identity provider.
Full Explanation
Staff should use the city's directory or identity provider so Workspace ONE Access single sign-on covers HR and ticketing SaaS without passwords taped under keyboards; patrons being outside AD does not force shared staff logins. In municipal EUC terms, treat the endpoint as a window into city systems when the architecture says so, not as the system of record for the files or apps in the stem. Distractor concept: A shared patron kiosk account in App Volumes is not the identity source for staff SaaS. Distractor concept: Storing each SaaS password in Dynamic Environment Manager is secret sprawl, not federation. Distractor concept: Enrolling patrons in UEM does not make them the identity source for staff HR apps. Exam caveat: Staff SaaS SSO points to directory/IdP + Access federation, not App Volumes, DEM password stores, or patron enrollment. Operational check: Federate a pilot staff app through Workspace ONE Access using civic directory identity and confirm clerks sign in without sticky-note passwords. Record the chosen control and the rejected failure modes in the civic change ticket or runbook so on-call staff and auditors share the same rationale after the next maintenance window. Re-validate after personnel or image changes that the same control still meets the city's continuity, security, and support expectations for this service.