The Dogfooding Chronicles: Group Therapy—Getting All You Can From Okta Groups
We humans have been categorically labeling things for hundred of thousands of years. Personally, I try not to assign labels to people. We are all unique, and there’s always more to people than meets the eye, right? (The only exception being… Green Bay Packers fans.) In the IT world we have lots of good reasons to use labels. But the more common term would be groups. Groups help us manage the many users in our highly populated environments.
In this episode of the Dogfooding Chronicles, we look into how we use Okta Groups by focusing on three specific use cases: resource access, policy enforcement, and group creation within 3rd-party applications.
Why group rules RULE: automated authentication policy scoping
In our last blog post, we discussed some of the different authentication policies we use at Okta. Our authentication policies are crafted in a way that suits the level of access a user has to a particular resource. Now let’s say we wanted to apply an authentication policy to certain departments, and those departments are IT, Engineering and HR. Each of these teams has access to sensitive resources, so we want to ensure we apply the most appropriate and secure authentication policies.
The first thing we’ll do is create group rules so we can populate our Okta groups dynamically. The rule below does just that, assigning all users that have "Engineering" as their Okta profile attribute for department string into the Okta group named Engineering.
Once we’ve created rules to populate all three of our Okta groups (again, IT, Engineering, and HR), we can use those groups to dynamically populate another one. This second group is then assigned a policy by creating group rules. These rules can determine membership for multiple groups moving forward. So, instead of keying off of an Okta user attribute, we are keying off of an Okta group membership, as shown below.
Once these dynamic groups are created, we can leverage these groups for authentication policies, app sign-on policies, and/or factor enrollment policies. We can also leverage our Okta groups for app access.
Application group assignments: More reliable than those college projects
To streamline the assignment of apps, our IT team likes to use group assignments. Why do we prefer group assignments over individual ones? It allows us to customize the assignment of roles and permissions within certain OIN, provisioning-enabled apps.
For example, like the majority of Okta customers, we use Office 365 as one of our collaboration tools. The two types of licenses that we utilize are E1 and E3. The only notable differences between these two licenses are that 1) the E3 license allows an end user to install the Microsoft Office apps onto their laptop, and 2) the price point ($8 verses $20). We can assign both licenses (E1 or E3) as well as roles (standard end user or global admin) from Okta.
Also in our Office 365 example, we have three types of users: an end user with an E1 license, an end user with an E3 license, and an Office 365 global admin with an E3 license. We can solve for these user types by utilizing our app group assignments.
Pairing group rules with group push: A beautiful combination
As I explained above, Group Rules gives Okta admins an automated way to assign users to Okta groups based on their Okta user attributes or their Okta group membership. Group Push allows Okta admins to create and manage groups within 3rd-party apps that are managed by Okta.
A great example of how we use this at Okta is in our integration with Slack. For example, if you were 1) located in San Francisco, 2) a member of the IT department and 3) on the Okta on Okta team, you would be asked to join three Slack channels on your first day of work: #sf-announcements, #all-it, and #it-ooo.
Using Okta profile attributes, we have created group rules to assign groups based on location, organization and department. These Okta groups can then be associated to a Slack User Group that has predefined channel memberships already set up. By combining Okta Group Push with Slack User Groups, we are enabling new employees to collaborate with their teams—day one on the job.
Another application that enables our employees to collaborate efficiently and securely is Box. Again, we utilize Okta profile attributes in order to create granular groups within Box. By doing this, we created a “file system” structure which allows us to apply Box folder permissions to different teams based on their roles. This has made it much easier to find files in Box and has improved our security posture within the app, ensuring that teams only have access to the files they need to do their jobs.
The main thing to take away from this post? Take a hard look at your groups and ask yourself: Are our groups serving a logical purpose? Can they influence more than one app or process within the organization? Here’s the breakdown:
- Establish best practices around the creation of groups. Each group formation should serve a purpose.
- Evaluate the management of your groups. At a minimum, review them annually to ensure they continue to add value in their current form.
- Don’t forget the security aspect. Groups can play a strong part in the security of your organization by restricting sensitive information to those who need to know.
If done correctly, you will have ensured that the right people have the right access to the right resources, at the right time. No judgement required.
I hope this helped! Interested in more ways to get the most of your org’s apps by using Okta? Check out this 3 Steps to Secure Your Office 365 Environment infographic!
Missed a previous post? Don't ever skip a meal—read them all!
