Employees need to sign in to a partner's browser-based SaaS application using their existing corporate credentials, and the company does not want user passwords stored by or sent to the partner. Which approach BEST meets this requirement?

Federation establishes trust between an identity provider and a service provider so users authenticate at home and access external applications. With Security Assertions Markup Language (SAML), the corporate identity provider authenticates the user and issues a digitally signed assertion that the SaaS application validates using a pre-exchanged certificate. The partner never receives or stores the user's password, and disabling the corporate account removes access to the partner application as well. Synchronizing passwords into the provider's user store directly violates the requirement, placing credential material with a third party. Exposing the corporate LDAP directory so the provider can bind with user passwords sends credentials to the partner on every login and opens a directory service to the internet, a significant exposure. Shared department accounts break individual accountability, make deprovisioning unreliable, and still require a password known to many people and held by the provider. Exam caveat: SAML is the classic browser-based federated SSO protocol; OAuth addresses delegated authorization to APIs, a different problem. Operational check: test an employee login to confirm redirection to the corporate identity provider, then disable a test account and confirm the SaaS sign-in fails.