When you have both IDaaS and UEM, where do you build your conditional access policies?

Example: UEM enrollment for SaaS app access

To illustrate how this decision might come up, let’s look at a very simple access policy: In order to access a SaaS app from a mobile device, the device must be enrolled in management.

You could do it in the UEM-centric way: The device is enrolled in UEM, and the UEM also authenticates the user, so the business logic and features in the UEM check off both parts of the policy. From there, the UEM could use a built-in IdP (identity provider, which itself is probably federated or synced to your Active Directory) to federate to a SaaS app. But here, we’re assuming the organization has a separate IDaaS (otherwise, there would be no choice to make), so instead, the UEM delegates this to the IDaaS, which then makes the last mile connection over to the SaaS app.

Or, you could implement this policy in an IDaaS-centric way. The user authenticates to the IDaaS, which federates over to the SaaS app. But, before granting access, the IDaaS calls out to the UEM via an API to verify that the device the user is coming from is enrolled and compliant with the UEM policies.

Both techniques have the same end result, but you’re implementing the decision-making logic in different places.

Example 2: Bringing in a third-party security agent

Let’s take this further with another simple example. Say you’ve deployed a third-party mobile threat defense (MTD) product. The MTD has an agent on the device, which reports the device status (for the sake of argument, we’ll just say “healthy” or “not healthy”) back to the MTD service.

In the UEM-centric approach, the UEM would authenticate the user and know what device they’re coming from (as in Example 1), and then call out to the MTD (likely via a proprietary API) to ensure that the device is marked as healthy.

In the IDaaS-centric approach, after the user authenticates, the IDaaS could call out to both the UEM (as in example 1 again) and then also call out to the API in the MTD service. Once both check out, then the IDaaS can grant access to the SaaS app.

Again, it’s the same policy, but you have an opportunity to choose whether to use your IDaaS or your UEM as the integration point for your MTD.

More considerations

These are just very basic policies, described in the simplest possible terms to get the point across. In reality, there are many more ways that the IDaaS and UEM relationship can be designed.

This is because there’s a lot of overlap, as I mentioned in the introduction. Just about every UEM platform has some identity features built in, and many IDaaS platforms have device-centric features built in, such as basic MDM, or a device attestation agent.

Thanks to identity standards, there are a lot of ways to chain things together and delegate from one platform to another. Plus, almost all of these products offer a proprietary API to read and/or report device status information, as well as other data.

Then, there are all the third-party other integrations you can pull into a conditional access policy engine. As I mentioned, there are antivirus, endpoint protection, and MTD integrations, but on top of that, platforms also pull in data from CASBs (cloud access security brokers), third-party MFA apps, networking products, threat intelligence and CVE feeds, and more. This has led to the proliferation of branded integration and partner programs, like the Workspace ONE Intelligence Trust Network, the Microsoft Graph API, the Google Cloud Identity BeyondCorp Alliance, the Lookout Post Perimeter Security Alliance, and others.

Also, we’ve seen the access policy engines themselves become branded, like Workspace ONE Intelligence, Citrix Analytics, the Microsoft Intelligent Security Graph, and MobileIron Access. (Sidenote: Have you noticed that all of these names make a lot more sense now that we’re talking a lot more about contextual access policies?)

Conclusions

There is a decision to be made, but of course, none of these decisions are made in a vacuum. In a lot of cases, companies may have a more strategic approach on one side or the other—that is, they may think of their UEM strategically and their IDaaS tactically, or vice versa. And some integrations might make sense more on one side than another. MTD might lend itself to plugging into UEM, while CASB makes sense with IDaaS.

No matter what, it’s clear now that integrating IDaaS and UEM, figuring out how and where to build all of the desired conditional and contextual access policies, and plugging in third-party security products, is going to be a big task for getting to the next stage of end user computing.

The partnerships are happening all over the place. In some of the most recent examples, Microsoft is opening up Azure AD conditional access a bit more; MobileIron was talking about new features in MobileIron Access; and at Synergy, Citrix announced several new identity management integrations.

I’d love to see some easier ways of passing nuanced device and risk data back and forth between all of these parties, kind of like the AppConfig concept for MAM, or like the “SaaSConfig” idea I talked about on the podcast with BetterCloud. (I have a long history of standards fantasies.)

Today, you’ll have to check with your IDaaS and UEM providers, and see how they build their reference integrations, what data they can pass back and forth, and what partners are part of their ecosystem.

No matter what, though, I firmly believe that all of this conditional access stuff is the future of EUC and key to having both good security and a good user experience.