Kolide has long allowed you to control authentication via SSO - it’s even included at no extra cost! Today, we’re announcing a deeper integration with your SSO provider, which opens up some exciting new possibilities.
We’ve been working hard this summer to expand the capabilities in the SSO provider integrations Kolide offers, using the System for Cross-domain Identity Management (SCIM) protocol.
In a nutshell, SCIM is a specification that allows changes in your identity source of truth (i.e. your SSO provider) to propagate out to various other cloud services. For example, when you hire a new employee, they are always added to your SSO provider. SCIM allows for the addition of that new user to be replicated in all the cloud services relevant to that new employee.
Alongside user additions, removals, and information updates, you can also sync Group membership via SCIM. This means that when you add your new SWE hire into the ‘Engineering’ group in Okta/OneLogin etc, that fact can be mirrored in Kolide.
While terminology varies by vendor, most SSO providers refer to employee accounts as “Users,” and these Users can belong to zero or more “Groups.”
Traditionally, SCIM is intended for Users that should have complete access to the service provider (Kolide in this case). However, there are a couple tiers of access to Kolide - end users can interact with the Kolide Slack app and visit the Privacy Center, but don’t have access to the management side of the Kolide web app.
To make sure we don’t give anyone inappropriate management access, our SCIM integration imports your SSO users as “People” by default. (In Kolide parlance, “People” are able to access the privacy center and interact with the Kolide Slack app, but do not have access to the management interface). You can then invite select People (IT and Security Admins) to be Kolide Users with full access by going to the Users & Access settings screen after configuring your SSO connection and SCIM integration.
You can find a step-by-step guide to setting up your SCIM integration in our help documentation.
In Kolide, Teams are a great way to group People any way you’d like. You can sync your SSO Groups to Kolide Teams, and you only need to manage these groupings in a single source of truth: your SSO provider.
When you configure (in your SSO provider’s admin panel) a Group to be synced with Kolide, we’ll automatically create a corresponding “Team” in the Kolide dashboard. Each User belonging to the Group will also be added to the associated Team in Kolide. If a user is removed from an SSO group, those changes will be synced to your Kolide Team memberships.
How are Teams useful? While we have quite a few ideas that excite us, we’re starting with one important use-case: segmenting your automatic-onboarding into Kolide.
One of the most common questions we’ve received about our automatic-onboarding feature (where we reach out to your new coworkers via Slack to walk them through the process of enrolling their device into Kolide) is: “Can I only auto-onboard a subset of our users?”
For a while, our only answer was to point people at manual onboarding. Today, we’re happy to announce that automatic-onboarding can be limited to a specific set of Kolide Teams.
Perhaps you want to start your Kolide rollout with your Engineering team, or maybe you want to hold off prompting new employees to enroll in Kolide until they’ve moved out of your “New Hires” SSO group, and into the “Grizzled Old Vets” group (indicating they’ve finished all the first-week paperwork). However you’d prefer to break up the Kolide onboarding process by group, we’re here to support it!
Up until now, Kolide has only supported Slack and Google Workspace as identity providers. This means we allow you to integrate with Slack and Google Workspace to import your user accounts into Kolide. These accounts are useful for automatic device assignment and allowing your end users to access the Privacy Center.
With our new SCIM integration, we’ve added a third type of identity provider - SSO providers that support the SCIM specification. Now that the number is up to three, we also require one of the configured providers be marked as the Primary provider. While we’ll sync account data from all the providers you configure, only the Primary identity provider will cause People records to be created for device assignment and privacy center access. The non-primary providers will provide ancillary information for the people records created by the Primary provider.
While we were rebuilding the idea of auto-onboarding criteria, we also took the opportunity to expand and improve the available configuration.
In addition to per-team onboarding, you may now configure:
- How many times a user is reminded to enroll their device into Kolide
- Which days of the week users are contacted
- The time of day you think will be most effective to reach out
You can check out all the onboarding options available on our expanded onboarding options page. Note that some features (i.e. per-team onboarding) aren’t available until you’ve successfully configured and enabled a SCIM integration.
Stay tuned for additional Kolide features to be enhanced by Teams, and please, if a use-case came to mind as soon as you saw “Teams,” reach out to let us know what you’d like to see!