Evaluating Microsoft Entra ID Against Okta SSO Part 2: Advanced Features

both

Last Week, we covered part 1 of evaluating Microsoft Entra ID against Okta SSO. We covered what both platforms are, user, groups, authentication, and policies.

Today, we will cover some more advanced concepts:

Again, as a reminder I have no preference toward a platform. Simply, each platform has gaps, and it depends if they let you meet your goals. Let’s get started with provisioning in Microsoft Entra ID.

Entra ID Provisioning

Within provisioning, we have a few different areas to focus on:

We discussed inter-directory provisioning in part one of our article. Specifically, it includes provisioning between two distinct directories. The most common is AD to Azure AD via Entra Connect or Cloud Sync. Microsoft Identity Manager is a 3rd and growingly less common option for inter-directory provisioning.

Entra ID App Provisioning

In Entra ID, app provisioning is the automated creation of users in a specific application. You can use individual users or groups to perform provisioning. Entra ID will pass attributes to the application to deliver a seamless onboarding process for an application. In some situations, provisioning can also set roles like “user” or “admin.”

Entra App Provisioning

In addition, provisioning includes onboarding and offboarding applications as users are removed from groups or separate from the company. The same extends to role changes. One of the differentiators is Entra support for on-prem provisioning for:

  • SCIM
Entra SCIM provisioning
  • LDAP
Entra LDAP provisioning
  • SQL
  • REST Web Services
  • SOAP Web Services
  • Flat-file via PowerShell Connector
  • Custom ECMA connectors/gateways built by partners (similar to MIM)

Some of the capabilities included in provisioning are:

  • Automatic provisioning and deprovisioning
  • Sync’ing data between systems
  • Provisioning groups
  • Monitoring and auditing user provisioning
  • Brownfield deployments
  • Rich customization through customizable attributes
  • Alerts supported with the Log Analytics integration

Many gallery apps support provisioning. You can access that list here.

Some of the most popular ones are Zoom, Jira, Salesforce, ServiceNow, Workday and much more. Remember, not all apps support everything. Some will support roles, some support just provisioning, and some gallery SSO apps only support SSO itself.

Apps that support provisioning in Entra

They have a few neat features with provisioning. Firstly, you can add scoping filters, to decide who is in scope to be provisioned:

Entra scoping filters

You can also decide if you can create, update, or delete attributes from Entra ID to an application.

Within attributes themselves, you can map a specific value, map an existing Entra ID attribute, or user an expression to determine the value:

Entra attribute expressions

You can also create new attributes to be part of your provisioning. If I have a single criticism, I would like to see the target attributes be a bit more uniform as this could confuse some admins:

Creating Entra attributes

The last item to mention are custom security attributes. They are key-value pairs (KVPs) that you can assign to Entra ID objects. They are useful since you can leverage them in Azure RBAC, use them to control access, and leverage filters. One note, they cannot be used in SAML token claims.

Custom security attributes

Entra ID HR-driven Provisioning

HR-driven provisioning is vital to most companies today. Your HR system will onboard users, which are automatically provisioning into Active Directory, Entra ID and other possible apps. Frequently, people are added to dynamic groups based on department, title, or manager. Those dynamic groups may trigger numerous provisioning workflows. Today, Workday and SuccessFactors are supported for HR-driven provisioning.

Your HR system is known as “source of truth” or “start-of-authority.” Entra ID supports both SaaS and On-prem HR provisioning. Some of the workflows this delivers is new employee onboarding, attribute changes, termination, and rehires.

Entra ID hr-driven provisioning

Entra ID Provisioning: 8.5

Okta Provisioning

Okta frequently touts their two main pillars are authentication and provisioning. Okta’s focus is on CRUD (Create, Read, Update, Deprovision). It’s not a new concept, but it is a common trend among many vendors.

Similar to Microsoft, Okta puts a major emphasis on profile masters. One difference is deeper support by Okta for the “HR-driven provisioning” that Microsoft offers. You can leverage those capabilities with:

  • Active Directory
  • BambooHR
  • G Suite
  • LDAP
  • NetSuite
  • Namely
  • Salesforce
  • SuccessFactors
  • UltiPro
  • Workday

A company identifies who the “source of truth” is and that becomes the basic for their entire identity inside of Okta. You can also set priorities, so that user attributes can be sources by different systems. This provides great flexibility and ensures your profile is extended as desired.

Okta profile sources

Okta Profiles and Provisioning

As we discussed last week, you can configure attribute mappings to/from various profiles. We have a few different profile types:

  • Okta Profile (Universal Directory)
  • App Profiles (Profiles for apps integrated in Okta, likely from the Okta Integration Network (OIN))
  • Directory Profiles (From a sourced directory)
  • Identity Provider Profiles (From 3rd party IDPs like Entra ID, Ping, etc.)

Within your profile, you have attributes, which can be base attributes (the ones that it comes with) or custom ones you create. A good example is creating ObjectGUID to sync your immutableID from Microsoft to Okta.

Okta custom attributes like objectGUID

You also have mappings, which indicate when provisioning occurs what will be synchronized to the app from Okta and vice versa.

Okta user profile mapping

We may use those attributes to pass back to an application or use them to format the username that is passed to your application. You also get expression support to cultivate accurate values.

A nonsense example but this shows it:

Okta expressions for attribute mapping

Okta Integration Network

The OIN is just a fancy term for their app catalog. It’s their collaborative community where developers bring their products and capabilities to Okta. Okta offers a collection of services in the OIN:

  • Workflow Connectors (Basically connectors that support API-driven workflows for automation)
  • Workflow Templates (Pre-built workflows for things like sending welcome emails to a new Office 365 user)
  • SAML (SAML SSO)
  • OIDC (Open ID Connect)
  • SWA (Secure Web Authentication basically means an app doesn’t support SSO but they can help bridge it securely. They don’t provide any auth, but more so a single-pane-of-glass.)
  • SCIM (Provisioning)
  • API (API-driven features like automation, alerting, log integration, etc.)
  • Inbound Federation (3rd party IDP inbound federation)
  • Outbound Federation (SailPoint integration for handling provisioning/deprovisioning together)
  • Event Hooks (Stuff like Zapier, which are outbound calls from Okta triggered by specific events via REST)
  • Inline Hooks (Used by Socure ID+, similar to event hooks. They are used to perform identity verification).

Okta supports about 2000 SSO apps in their OIN along with 500+ apps for provisioning. One of the brilliant things about Okta is that it’s an easy button for administrators.

Okta App Provisioning

Their approach to app provisioning is seamless. Provided the app supports it, you can quickly configure it. Let’s check out Salesforce.

Similarly, to Entra ID, you just put in a client ID and secret and authenticate to the service:

Salesforce provisioning integration in Okta

They take provisioning a little further with Microsoft with some nice safeguards. Their user matching capabilities will map users automatically if they meet the guidelines you set:

Okta user creation and matching

In addition, you have other nice features like unassignment safeguards to ensure someone doesn’t accidentally burn the store down.

You will also see you can deploy licenses and permission sets via provisioning. Entra ID supports similar capabilities for some apps, but nowhere near the scale of Okta:

Salesforce roles in Okta
Salesforce license mapping in Okta

Okta Provisioning: 9

Thoughts on Provisioning

Overall, both do a solid job with provisioning. The main difference in the depth of Okta’s provisioning via the Okta Integration Network providing far more apps (about a 2-to-1 advantage) and some deeper integrations. Outside of that, they’re about even on provisioning. One other thing to mention is the limited support for HR-driven provisioning, which is another feather in Okta’s cap.

One other place Okta thrives is in the multi-profile and multi-user type world, which are unique capabilities that fit some niche use cases. Entra ID is an amazing platform that will cover probably 80% of use cases, but I could see more Okta customers moving toward Entra ID based on the licensing structure.

As I reflect on provisioning, I still think Okta’s huge value is with small/medium business because it’s easier to manage and it has deep penetration in B2C markets. It will be interesting to see how Entra ID progresses on provisioning in 2024 as they still have some work to do there.

Okta Lifecycle Management

Okta Lifecycle Management covers a few areas. Some we have already covered:

  • App Entitlements and Provisioning (discussed earlier)
  • Lifecycle of Provisioning Users
  • Entitlement Management
  • Okta Workflows
  • Access Request Management
  • Okta PIM
  • Auditing and Reporting
  • Universal Directory (discussed earlier)
  • HR-driven IT provisioning (discussed earlier)
  • Profile masters (discussed earlier)
  • Sourcing users from CSV, LDAP, and more (discussed earlier)

We will discuss the lifecycle of a provisioned user, Okta Workflows, Access Requests, and Entitlement Management.

Okta User Lifecycle

The lifecycle of a user goes through multiple stages from a new employee up until they are terminated.

The Okta user lifecycle

With Okta, it starts with your HR system integration. With BambooHR for example, your employees are synchronized. Departments are also brought in as groups in Okta to power the provisioning journey.

As a user is created in BambooHR, the provisioned groups will deliver an ideal day one experience. Apps and access come down as things flow organically.

As times change, so does their access. Employee changes will synchronize to drive onboarding and offboarding of access and apps. Additionally, when the employee leaves all apps are deprovisioned and we ensure access is terminated. Lifecycle maintenance is exactly that concept. These concepts grow as you buy other products like the Okta Access Gateway (OAG), Privileged Identity Management (PIM), and Governance products. Okta does a solid job, but sometimes it needs to rely on its next friend Okta Workflows.

Okta Workflows

Okta Workflows is mostly a paid product, but you do get a few workflows with your standard contract (5). Provisioning is not without its limitations in Microsoft or Okta. With most products, you can manage specific attributes/settings. A handful of settings doesn’t meet the needs of a lifecycle management journey.

An example of a workflow that Okta can solve is something like this:

A logical flow of an Okta workflow

Their template support is a little bit weak (only 10-12 today), but we will look at piece of a useful one. This is leveraging the template for Office 365 onboarding/offboarding. When we pull in the template it gives us 7 flows along with a table to store all of the licenses:

The flows involved in onboarding and offboarding in Office 365

First, we run the “Store all Microsoft Licenses” workflow to build the table of licenses. The workflow, we can break into a few parts. This first part does:

  1. Clears the license table
  2. Create a new input field in that table
  3. Clear the existing table

The nice thing as you can see below, it’s very easy to read and understand:

Looking at the Okta workflow for storing Office 365 licenses in a table

The second part will get all of your licenses from Entra ID and write them to the table

The second part of the Okta workflow for storing Office 365 licenses in a table showing the Azure API calls

A few things to note. They have a nice collection of connectors for several products here. Some of the popular ones:

  • Salesforce
  • Adobe
  • Microsoft
  • Google docs
  • Box
  • Zoom
  • Proofpoint

Below, you can check out a demo I made awhile back on using workflows for updating IDs in Entra ID:

A video demo on using Okta Workflows to automate updating of the ImmutableID

Okta Workflows Building Blocks

Let’s cover the building blocks inside of Okta Workflows for clarity’s sake. They have 3 types: events, actions, and functions.

Events are what cause a flow to run. As an example, when a user account is added to a group. Okta supports three types:

  • App Events: monitors for a change in a cloud app
  • Schedule Events: given intervals
  • On Demand Events: an event triggered manually like an API call that triggers an event

Functions enable interaction with the data in the flow to change or control something. Functions are grouped also:

  • Logic (conditional statements, handling errors, manipulating flow structure)
  • Manipulation (parsing text, performing math operations, boolean, iterating items)
  • Elements (exporting elements of a flow as a JSON, table functions)
  • Advanced Functions (API connectors, JSON, XML, URL, JWT, and encrypt/decrypt)

Actions control an application or service, like sending an email, updating a field, etc. These actions are only limited to the connector that exists, but you can also build custom connectors.

For example, these are some of the Okta connector actions:

  • Activate User
  • Delete Group
  • List Users
  • Read Groups
  • Update Group Rules

Okta Entitlement Management

OIG Entitlement Management as it’s commonly called is powered by Okta’s Governance Engine. When an app has Governance Engine enabled, a resource is created inside the engine for that app.

The “Entitlement” is the central object represented as entitlements on an app as roles, profiles, or licenses. A resource can have multiple entitlements, and each can have a set of values. Single-valued and multi-valued are supported.

Okta uses “Entitlement Policies” to assign entitlements similar to Group Rules based off an attribute. Similar to app policies, a resource has one policy with multiple prioritized rules. Okta groups sets of entitlements into “Entitlement Bundles” An example would be someone in IT gets a set of app entitlements. Another example is a bundle needed for access to a specific office.

One departure from the standard Okta model are “Grants” Grants are an association between users and entitlements (it’s decoupled from the user profile). Okta’s access request platform is extended to submit requests in a central location.

Okta entitlement management

Entitlements are still an early access feature, so we won’t spend too much time on it. Microsoft has a major edge here at this point I think. You can read here about the current limitation. As you can see above, those are the only provisioning entitlements available currently. Some of the other items:

  • No support for mandatory entitlements
  • Cannot assign bundles with an entitlement policy
  • Entitlements assigned by policy rules only work for Okta-sourced groups

You can read the full list at the link, but there’s still some work to be done.

A look at Okta entitlement bundles in the admin console

Okta Access Requests

Okta Access Requests let you automate the application access request process. Some of the benefits are:

  • Supported in chat, email, and browser
  • Self-service automation
  • Approval workflows
  • Conditional request logic
  • Delegation
  • Business justification capturing

Access Requests automate the process of requesting for application access similar to entitlements. The neat thing about Access Requests is the ability to submit requests by email, chat, or web. Okta provides some self-service support out of the box to request app access, but Okta Access Requests take it to the next level.

A basic screenshot of it looks like this:

Okta access requests via Slack

Okta Privileged Access

As Okta PIM is a new product, I will provide a brief overview. Okta PIM delivers the following capabilities at release:

  • JIT access to On-Prem infrastructure
  • PIM access requests
  • Privileged account vaulting
  • Secrets management
  • Cloud infrastructure entitlement discovery and analysis
  • Session recording

Okta’s PIM product is significantly different from Entra ID. They are a hybrid approach of CyberArk-esque capabilities and PIM together. It will come down to what your needs are. Okta PIM focuses on being a vault platform that can vault keys, record sessions, and grant access to servers. It’s out-of-scope for our two-part series, but since I am discussing Entra PIM I thought it was worth a short blurb. I definitely like Okta PIMs offering but I think it’s a bit overpriced (maybe not compared to CyberArk, but overall). Okta charges about $14 per resource unit.

A logical diagram of Okta PIM

This is what the JIT access to a server via SSH looks like. It’s neat since CyberArk requires RADIUS for this still:

Okta PIM performing JIT access to a server via SSH

This is what their access to a server looks like:

Okta PIM access to a server

Okta Lifecycle Management: 7.5

Microsoft Entra ID Governance

We will be looking at the Entra ID Governance platform in this section. The governance platform covers 3 areas:

  • Identity Lifecycle
  • Access Lifecycle
  • PIM Lifecycle

Overall, Entra ID Governance is a solution enabling orgs to be more productive and secure. It also focuses heavily on compliance and regulatory needs. As you can see in the graphic below, Microsoft focuses on the entire lifecycle of the user, their apps, controls, and auditing to ensure gaps are accounted for.

A map of Microsoft Entra ID governance

Identity Lifecycle

The identity lifecycle like we discussed with Okta is paramount to the identity journey. Entra Identity Governance ensures what birthright applications a new employee gets, what to do when things change, and proper offboarding of a user.

We start with a company integrating Workday with automated user provisioning similar to the image below. CRUD events are handled as Workday is the authority and ensures the right people have the right access from the beginning:

HR-driven provisioning for Workday to Entra ID

One slight difference, we leverage dynamic groups to duplicate what Okta does, e.g. creating a Dynamic AD Group for department to group mappings. Not a big deal by any means, but a good thing to call out. Additionally, the Workday integration has strong support for attribute mappings, which makes it a strong offering.

Guest Accounts in Entra ID Identity Lifecycle

Guest account management is super exciting with Entra ID. First, we’ll start with connected organizations.

A connected organization is one you have a relationship with. You can add other Entra ID directories into your environment to be used in “Access Packages” (which we will discuss shortly). Below you can see how that works:

Access packages with connected organizations

With user entitlements, you can enable guests to access the specific resources they need from https://myaccess.microsoft.com upon approval of the access package they will have a guest account created and their access provisioned.

The MyAccess portal for requesting access with Entra Governance

The best part is the access packages can expire, which strengthens your security posture further around guest accounts:

creating new Entra access packages

Access Requests are another nice feature that will solidify your overall identity strategy as you can see:

Entra Access Request approvals

Access Lifecycle

Processes around managing access are important. Access Lifecycle empowers IT by:

  • establish the right access rights
  • enforce checks like separation of duties or job changes

One way you can extend Entra ID Conditional Access to support the Access Lifecycle is with custom terms of use policies inside of Conditional Access, which requires users to read/accept terms of use before they can access an application. Once you create the terms of use, you can now see it in the test section:

Entra ID conditional access policies with EULA in the grant

Now, let’s shift to looking at Lifecycle Workflows, which is crucial to the Access Lifecycle.

Lifecycle Workflows

Lifecycle Workflows let you automate lifecycle management processes. They will work out-of-the-box, or you can customize them to meet your needs. The supported ones today are:

  • Onboard pre-hire employee
  • Onboard new hire employee
  • Post-Onboarding of an employee
  • Real-time employee change
  • Real-time employee termination
  • Pre-Offboarding of an employee
  • Offboard an employee
  • Post-Offboarding of an employee

Let’s check out the new employee onboarding:

We leave the basics the same (to onboard a new employee on their hire date)

Entra ID Lifecycle Workflows

We can configure a scope if necessary:

Entra ID Lifecycle Workflow scopes

Now, we just have workflow tasks to look at/customize as needed (e.g. adding them to various groups and customizing the welcome letter):

Entra ID Lifecycle Workflow tasks

You can also add tasks, which is very neat. The very exciting one is adding user access packages, which ensures a strong birthright setup:

Entra ID Lifecycle Workflow task list

Once done, you just create and that’s it!

Entra ID Lifecycle Workflow creation

Entitlement Management

Entitlement management enables companies to manage their identity and access lifecycle effectively. We can automate access request workflows as mentioned earlier. We can also manage assignments, review, and their expiration.

Some of the things you can do are:

  • Control who gets access to apps, groups, Teams, and SharePoint sites with multiple stages of approvals. They also support expiration and recurring access reviews
  • Grant automatic access to resources based on user account properties
  • Delegate to non-admins the ability to create access packages
  • Integrate connected organizations to simplify user access requests

Within the access package, we have resources and policies. You can see below the rules are defined granularly to provide effective access.

Entra ID entitlement management access packages

The diagram below shows the different elementals of entitlement management. In Access Package 1, we have a single group as a resource with a single policy. Access Package 2 is much more complex with a group, app, and SharePoint site. You will notice that policies are completely separate for internal and external users.

Diagram of Entra ID entitlement management

Overall, you can see that Microsoft’s Lifecycle Management platform is significant more advanced than Okta’s. They have done a great job designing a solution that is effective and easy to administer. I’ve seen other IAGs over the years that were very confusing. Well done on their part as it’s a strong experience.

Privileged Access Lifecycle (PIM)

PIM is a constant issue at companies. Admin rights need to be secured as we’ve seen many bad things happen over the last year because of it.

Entra ID PIM diagram

PIM lets you manage, control, and monitor access to resources in your organization. PIM supports Entra ID, Azure, and other Microsoft online resources. PIM offers these benefits:

  • Providing JIT PIM access to Entra ID and Azure resources
  • Assigns time-bound access to resources
  • Requires approval for role activation
  • Enforce MFA to activate a role
  • Request justification for role access
  • Notifications on role activation
  • Access review
  • Audit trail
  • Protects your Global Admin and Privileged Role Admin assignments

You can go into a role, and add assignments:

Entra ID PIM assignments

You can also modify settings within the role to match with your PIM strategy like enforcing approvals and MFA:

Entra ID PIM assignments and setting roles

You can also set assignment rules (eligible means you can request it, active means you can just use it):

Entra ID PIM assignment rules

Of course, you also have notifications:

Entra ID PIM notifications

An easy thing to miss, is only allowing “eligible” as an assignment type when you create your assignments:

Entra ID PIM blocking active assignments

The activation part is relatively easy as you go to “My Roles” in PIM and click activate:

activating Entra ID PIM roles

Entra ID Lifecycle Management: 9.5

Thoughts on Lifecycle Management

Lifecycle management is a tough one. The only reason Entra ID didn’t get a 10 is they don’t support a few of the niche players on the HR side. Entra ID does a great job on the governance side, which was something I wasn’t aware of until I looked into it. Many of us are familiar with PIM, as many companies are doing it now, but the new capabilities in governance like access requests/entitlements/lifecycle workflows are very appealing.

Okta does a great job themselves, but their PIM and governance products are immature at this point and need time to solidify themselves. I like their approach to PIM being a CyberArk-adjacent product and aligning on on-prem issues. They’re almost different enough that I could see Okta customers having both Entra ID governance and Okta PIM. Okta has over 17,000 customers and despite their recent challenges aren’t going anywhere. I think similar to Office 365 Profile Sync in Okta, they will co-exist nicely for a long time.

Entra ID Security Capabilities

When we discuss security, there is a ton we covered already. For Entra ID, we will cover these areas today:

  • Secure Score
  • Identity Protection
  • Risk-based Conditional Access
  • Token Protection
  • Vulnerability and Risky Accounts

Entra ID’s score will encompass security-based features we have already discussed and these capabilities overall.

Entra Identity Secure Score

A great Microsoft feature across their platform is “Secure Score” which helps many companies without expertise protect their resources. The idea is pretty simple. They have a list of features they consider to be important. You implement and the score goes up yay!

It’s a great planning tool for companies who don’t have a large InfoSec department and could use some guidance on good decision making.

An example of one of the screens you might get is:

Entra ID Identity Protection

Entra ID Identity Protection is Microsoft’s foray into contextual access management. This service helps orgs detect, investigate, and remediate identity-based risks. They feed into conditional access along with a company’s SIEM to investigate further.

The list of risk detections they look for are (Premium require Entra P2):

Risk detectionDetection typeType
Atypical travelOfflinePremium
Anomalous TokenOfflinePremium
Anomalous TokenReal-time or OfflinePremium
Malware linked IP addressOfflinePremium This detection has been deprecated.
Suspicious browserOfflinePremium
Unfamiliar sign-in propertiesReal-timePremium
Malicious IP addressOfflinePremium
Suspicious inbox manipulation rulesOfflinePremium
Password sprayOfflinePremium
Impossible travelOfflinePremium
New countryOfflinePremium
Activity from anonymous IP addressOfflinePremium
Suspicious inbox forwardingOfflinePremium
Mass Access to Sensitive FilesOfflinePremium
Verified threat actor IPReal-timePremium
Additional risk detectedReal-time or OfflineNonpremium
Anonymous IP addressReal-timeNonpremium
Admin confirmed user compromisedOfflineNonpremium
Microsoft Entra threat intelligenceReal-time or OfflineNonpremium

Additionally, these are user risk detections:

Risk detectionDetection typeType
Possible attempt to access Primary Refresh Token (PRT)OfflinePremium
Anomalous user activityOfflinePremium
User reported suspicious activityOfflinePremium
Suspicious sending patternsOfflinePremium
Additional risk detectedReal-time or OfflineNonpremium
Leaked credentialsOfflineNonpremium
Microsoft Entra threat intelligenceOfflineNonpremium

As I said earlier, you can put this right into conditional access policies:

Along these lines, a new feature in preview is token protection now. You can leverage token binding by ensuring a token can only be used from the intended device. This feature creates a crypto secure tie between the token and device via its client secret.

The final item to mention is risky account detection. Entra ID Protection will send two types of automated emails to manage risks. A user at risk detected email and a weekly digest. Essentially, when a high-risk user is detected, it will send the email to the user. This will let the user take action and try to remediate any issues before the administrator notices it.

The weekly digest can be seen below, which shows new risky users detected, risk sign-ins detected, and links to related reports.

Entra ID Security Score: 9

Okta Security Capabilities

Similar to Entra ID, we have discussed many things over the last few weeks. In Okta, we’re going to look at these items:

  • Okta ThreatInsight
  • Contextual Access Management

Okta ThreatInsight

Okta ThreatInsight enhances the security of your Okta tenant by evaluating sign-ins for suspicious activity. It writes the event to the audit log and may block the request. It targets specific malicious traffic but isn’t perfect.

Okta ThreatInsight focuses on a few areas:

  • Credential-based attacks
  • Threat evaluation at the pre-auth level
  • Data analysis and machine learning

ThreatInsight focused on credential-based attacks like brute force or password spraying. It will evaluate a sign-in request looking for potential threats like malicious IP address. The brilliance of it is that it doesn’t run up the bad password count (it’s handled outside of standard auth attempts). With data analysis and machine learning, Okta correlates data from all of its environments to correlate bad actors, block traffic, and enhance the protection for their landscape.

You can use a basic filter to look for events they blocked with: eventType eq “security.threat.detected”

ThreatInsight also supports advanced scenarios like companies using trusted proxies:

By implementing trusted proxies and trusted zones, you minimize the potential for false positives. Overall, it’s a small enhancement but a useful one.

Okta Contextual Access Management

When we refer to contextual access management, we’re talking about using context like geolocation, device, network, and risk-based authentication to deliver a strong policy-driven story.

Okta starts to tell this story with dynamic zones that let you either include or exclude traffic from your policy rules:

You can also configure behavior detection, which is nice because it is fully customizable. This table from Okta’s documentation shows you how it’s evaluated:

Behavior typeCondition typeDescriptionDefault evaluation and customization
LocationNew cityA city that hasn’t been the source of a prior, successful sign-in attempt.Checked against the last 20 successful sign-in attempts. You can change the number to check against.
New stateA state or region that hasn’t been the source of a prior, successful sign-in attempt.Checked against the last 15 successful sign-in attempts. You can change the number to check against.
New countryA country that hasn’t been the source of a prior, successful sign-in attempt.Checked against the last 10 successful sign-in attempts. You can change the number to check against.
New geo-locationA location outside a specified radius that hasn’t been the source of a prior, successful sign-in attempt.Checked against the last 20 successful sign-in attempts for locations that are outside a 20-kilometer radius of the locations of prior, successful sign-in attempts. You can change the number to check against, specify the radius size, and define the location by longitude and latitude.
DeviceNew deviceA device that hasn’t been the source of a prior, successful sign-in attempt. A device is based on the client. Changing the browser is considered new device. The Improved New Device Behavior Detection feature provides a better mechanism for detecting new devices for browsers that store HTTP cookies. Device Behavior Detection is based on data passed from a web browser and a trusted application. For details about this feature, see Improved New Device Behavior DetectionChecked against the last 20 successful sign-in attempts. You can change the number to check against.
IPNew IP addressAn IP address that hasn’t been the source of a prior, successful sign-in attempt.Checked against the last 50 successful sign-in attempts. You can change the number to check against.
VelocityVelocityA measurement of velocity used to identify suspicious sign-in attempts.Velocity is evaluated based on the distance and time elapsed between two subsequent user sign-in attempts.Checked against the geographic distance and time elapsed between two successive sign-in attempts. Defaults to 805 km/h (500 mph)

You can use the behavior to build custom expressions in your sign on policy like this:

security.behaviors.contains('New IP') || security.behaviors.contains('New Device')

We would use that to make a user step-up authenticate to MFA in the event it picks up on risky behaviors like that.

In addition, as we mentioned last week, they have device assurance (compliance policies) and integrations with CrowdStrike to enhance the contextual security of a device.

Okta Security Score: 8

Thoughts on Security

I didn’t think overall Entra ID would surpass Okta on the security side, but I just don’t see it. For one, Entra ID does a much better job with aggregating data and surfacing it to administrators. In addition, despite the way policy is managed in Entra ID, their policies are comparable.

Entra ID protection was the largest gap that Entra ID had with major players like Ping and Okta. It’s nice to see that being addressed as they continue to grow their security story (Defender has made some major inroads over the last 12-18 months too). It’s just too difficult to argue against Entra ID because they have some strong friends in their corner. Wherever they have gaps, products like Intune have their back. Device compliance, App Protection Policies, etc. just strengthen the security story for the Microsoft suite.

Cost Analysis

I did a basic cost analysis, which let me reflect on what the better solution is for a standard cloud-only company. I based it on 60 users.

An Okta renewal with these features below cost $8500:

  • Adaptive MFA
  • Lifecycle Management
  • SSO
  • Universal Directory

For me to achieve the same capabilities in Entra ID, I would need my Windows Premium Licenses and Entra ID P2 and Governance (total of $8,280).

In that experience, for a small/medium business that is cloud only, Okta could be a better investment based on feature value, cost, and ease of management. That’s highly subjective but just my opinion.

However, when I start looking at Hybrid companies the story changes quickly. Let’s take someone with 10,000 users. The Entra ID total is $1.9M.

For those same 10,000 users with adaptive SSO, adaptive MFA, Universal Directory, Lifecycle Management, and Identity Governance the total is around 2.3M (presuming a 25% discount). That doesn’t count PIM. Either way, I think my opinion is that the platforms are now close enough that the cost is the biggest conversation vs. features.

I do think the divide on how both platforms see PIM (On-Prem CyberArky vs. Cloud) is interesting and will play a major factor on the smart strategic move. Okta can definitely get very expensive very quickly. It’s also nice to see that Entra ID licensing is probably more straight forward than most of their stack right now.

Final Thoughts

First, let’s tally the final score:

CategoryOktaEntra ID
Users and Groups88
Authentication8.58
Policies9.258.75
Provisioning98.5
Lifecycle Management7.59.5
Overall Security89
Total Score50.2551.75
The Final Tally of Entra ID vs Okta

Impressive, much like my beloved Boston Celtics, Okta fell down in the 3rd quarter. Many of the key identity capabilities that Okta is starting to get into like PIM and Governance, Microsoft is incredibly strong there. I also had to take off points from Okta in Security for the whole support system leak debacle. Sorry, not sorry.

Both platforms are great. Microsoft has very sneakily caught up in a few areas recently. MacOS and Entra ID have quietly become forces to reckon with. As someone who owns both, I still prefer the manageability in Okta. This is why I don’t full profile master Office 365 so that I can use the best of both worlds. Nothing is wrong with liking both. Competition drives innovation. Microsoft often takes inspiration from their competitors, which helps the product grow.

Facebook
Twitter
LinkedIn
This article discusses the evaluation of Microsoft Entra ID and Okta SSO, covering various aspects such as provisioning, lifecycle management, security, and cost considerations. Entra ID's capabilities for app provisioning, HR-driven provisioning, and security attributes are detailed. Okta's profile management, app provisioning, lifecycle management, and security features, including ThreatInsight and Contextual Access Management, are also highlighted. The article concludes with a cost analysis and a final comparison of the two platforms, favoring Entra ID for hybrid companies and acknowledging Okta's strengths. Both platforms are praised for their excellent features, with a preference for Okta based on manageability.

1 thought on “Evaluating Microsoft Entra ID Against Okta SSO Part 2: Advanced Features”

  1. Pingback: Unlocking Potential: The Future of Okta Stock in Tech Portfolios – US Stock Market Today

Let me know what you think

Scroll to Top

Discover more from Mobile Jon's Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading