Enforce Device Trust and SSO for desktop devices with Okta + VMware Workspace ONE
This use case allows administrators to establish device trust by evaluating device posture, such as whether the device is managed, before permitting end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. to access sensitive applications. It also establishes Okta as a trusted identity provider to Workspace ONE, allowing end users to log in to the Workspace ONE appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in., Workspace ONE Intelligent Hub app, and web portal using Okta authentication policies.
A device trust flow for macOS and Windows 10 devices using the Salesforce application would follow this sequence:
- End user attempts to access the Salesforce tenant.
- Salesforce redirects to Okta as the configured identity provider.
- Okta processes the incoming request and routes the clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. to the Workspace ONE IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. based on configured routing rules.
- Workspace ONE challenges the client device for credentials.
- Workspace ONE checks device compliance status.
- Upon successful authentication with Workspace ONE, the client device is redirected back to Okta.
- Okta validates the SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. assertion from Workspace ONE and issues the SAML assertion for Salesforce.
To configure this use case:
|Parent topic:||Integrate Okta Device Trust with VMware Workspace ONE for Windows and macOS computers|
|Other use case:||Configure streamlined Device Enrollment and Workspace ONE login for desktop devices using Okta|