Protecting access for employees and third-party contractors
The recent Okta breach has shown the harmful impact of a hacker with access to a SaaS administrative console. There has been plenty of coverage on what Lapsus$ was able to do and on how security teams can learn from this breach. Many organizations are now looking to ensure the right security checks are in place for the SaaS applications accessed by employees – and for third-party vendors as well.
This post will explain the mechanism Banyan Security uses to provide zero trust protection for SaaS applications. We’ll cover the role that Banyan and the Identity Provider each play, and then show how it works behind the scenes. The solution discussed applies not only to Okta, but to any Identity Provider including Microsoft Azure AD, OneLogin, and others.
Who does what?
SaaS applications are commonly federated with an Identity Provider. In this solution, the Identity Provider will provide the following:
- Directory and Entitlements
- User Provisioning
- Multi-factor Authentication (MFA)
Banyan integrates directly with your Identity Provider and provides:
- Device Trust
- Passwordless Authentication
- Continuous Authorization
What is Device Trust?
The Banyan Security solution defines Device Trust by the following measures:
- The device is known to Banyan
This could be through registering your device with the Banyan app or through possessing a client certificate that is trusted by your organization’s public or private Root Certificate Authority (CA). - The device meets the Banyan TrustScore requirements to access a service
Trust scoring is done by weighing a combination of on-device factors, such as an enabled firewall, disk encryption, auto-updates, etc., and signals from third-party security tools like CrowdStrike, Jamf, Workspace ONE, Intune, SentinelOne, and others. Groups of devices can have their own set of trust factors that are evaluated for access.
Deep Dive into the flow
In this deep dive, we’ll use Jenkins as the application being accessed and Okta as the Identity Provider. The flow is similar for other Identity Providers as well.
The Request
When logging into Jenkins, the user is routed to Okta to provide their username. Okta is configured to leverage Banyan for device trust and passwordless authentication for Jenkins. Here is a part of the OAuth request:
<state>d1VJZjg2bmRWUUhqdjFWQzZ3QkdYMEZPRVA1T1dsbGxjQ343525231FUQlFyN1Z6 YWtWdE1EWm5uazczcUJjOXdhYQ</state> <client_id>xYFX5Ml3xiYGJhBaEeF435234543KAjSfUVmsH9ge9w</client_id> <redirect_uri><https://banyansecurity.okta.com/oauth2/v1/authorize/callback></redirect_uri> <response_type>code</response_type> <login_hint>faraz@banyansecurity.io</login_hint> <scope>email+openid+profile</scope>
Okta forwards over the user’s email address in the request to Banyan, where the policy evaluation will occur.
Device Trust and Policy Evaluation
The certificate on a Banyan-registered device contains information about the device serial number in the Common Name and the user’s email address as part of the Subject Alternative Name (SAN). To ensure the device is known to Banyan and tied to the user making the request to access Jenkins, a certificate check is performed and the SAN is compared to the user email address sent by the IDP.
The device’s TrustScore is evaluated to ensure it meets the policy requirements for accessing the Okta SaaS application. Policies can be configured for different categories of applications such as high security and medium security. It is recommended to route all Identity Provider traffic to a zero-trust network access (ZTNA) product like Banyan when protecting SaaS applications. This ensures that both SP-initiated and IDP-initiated flows have the proper policy checks.
Passwordless
In the Passwordless Authentication Flow, Banyan leverages the fact that the trusted Device Certificate includes the user’s email address in the UserPrincipalName SAN extension field. Certificate-based authentication provides the user with a passwordless experience. An SSO token (Banyan ID Token) is generated and passed back to Okta.
{
"id": "d85dd62fa-8ceb-46e0-9b32-0feffedc27ce",
"external_id": "blsdf2anl1aFF0SCtQbFBSWmFUb1hIRy9xUS9N",
"org_id": "767sgd6ec-67b9-4157-bdc9-23cbf848b687",
"org_name": "farazworld",
"severity": "INFO",
"action": "Grant",
"type": "Identity",
"sub_type": "UserPrincipal",
"message": "SUCCESS - Banyan ID Token Generated",
"result": "INFO",
"created_at": 1649453783430,
"reported_by": {
"type": "trustprovider",
"host_name": "trust-preview.banyanops.com",
"host_ip": ""
},
"user_principal": {
"user": {
"name": "",
"email": "faraz@banyansecurity.io",
"groups": [
"Everyone",
"Faraz"
],
(Banyan event after Passwordless authentication)
See it in Action
Now that we’ve walked through the technical steps—let’s see how this looks from an end-user perspective.
The device trust and passwordless checks happen silently in the background, and the end-user will not see or interact with Banyan. MFA can be added at a per-application level for most Identity Providers and is recommended for a more secure solution. If the device is not registered or has a low TrustScore, the end-user is guided to how to remediate in a self-service manner.
Learn more about the setup for protecting SaaS applications with specific identity providers, like Okta and Azure AD. Banyan is free for up to 20 users, and you can get started protecting SaaS applications now!
