Why identity management matters to mobility engineers

Core concepts of identity and access management (IAM)

As a mobility engineer, you are often asked to deploy a new application in your environment. To provide a full-featured experience, you need to understand some basic identity and access management concepts.

When you introduce IAM, you can now ask better questions like:

• How should users authenticate?
• How does your IDP connect to your app?
• Are there groups I can use?
• Who needs access?

User authentication methods
We will start with users and how to authenticate them. No solution will be “one size fits all,” but you will be expected to understand how you can log into each platform and what log-in method is the most effective. This may vary from product to product, but the overall concepts are the same.

I'm going to focus on just a few authentication methods without going into the weeds. It can get very daunting, but by understanding how a few of them work, you can learn what works best for your situation. These methods are:

• Kerberos (read more about Kerberos on mobile)
• Certificate-based authentication (CBA)
• AD username and password

The best practices will depend on the platform, but you need to learn how all these methods work and why they are effective. Kerberos is always king on Windows, CBA provides the best experience on macOS, and username and password is a great fallback and widely used for external access. (That will widely depend on your environment and experiences.) We will talk more about fallback mechanisms and flow of authentication when we get into applications. Your initial focus is to make sure users can authenticate correctly and then you move onto how things are organized.

Application federation methods
Once a user’s identity is authenticated, the identity provider (IdP) will federate with the application using a few different methods:

• SAML
• Token-Based Authentication

You are probably familiar with SAML if your company already uses Active Directory Federated Services (ADFS) for Office 365, SharePoint, or other internal apps. (Non-SAML and non-token-based application authentication is a legacy design that will inevitably cause issues.)

Delivering a seamless and transparent path into your key applications is one of the best ways to improve productivity and build trust among your peers. BrianMadden.com published a previous introduction to identity that will provide a good foundation for many of these concepts.

User groups
The next step is to get your users in order, so you can move on to leveraging dynamic AD groups to permission applications, sync users automatically, and deliver a scalable strategy.

You should never just give everyone access to every application. By layering security effectively using dynamic groups, you show your expertise as an ambassador for security. It doesn’t matter how good your initial deployment is if it cannot stand up to the test of time. That is the true test for any engineer to deliver a strategy that can adapt with your business. The best piece of advice that I can give is never take shortcuts.

In practice, I like to create new AD groups to entitle applications and ensure a smooth workflow from end-to-end. We should always be providing this sort of guidance (like you are hopefully already doing for your MDM platform). Static is never the answer!

Application access
After setting up proper application authentication, you can now start to think about how people access your applications. This comes down to a few key characteristics, including device posture, network, and device platform

The flow you see below, based on VMware Identity Manager, is a nice example of building a strong workflow for your applications:

Simply, every application falls into one of three buckets: low, medium, and high-risk apps:

• Low-risk apps: Authenticate from anywhere, with Kerberos or CBA for internal access and username and password or mobile SSO for external access.
• Medium-risk apps: Authenticate from anywhere, with Kerberos or CBA for internal access and username and password or mobile SSO AND multi-factor authentication for external access.
• High-risk apps: Authenticate only on internal networks using Kerberos or CBA AND multi-factor authentication.

Of course, this is just an example and you should evaluate your postures on your end, but the idea is that if you’re trying to demonstrate value, you have to show powerful identity can be. It’s one thing to say, “I can give you SSO,” but something else entirely to deliver SSO with strong security and analytics under the covers. This will create fans out of your users and your security/infrastructure teams.

Bringing it all together

We covered basic IAM concepts and tasks you’ll be expected to handle more often, but I’m sure you are asking yourself, “how could I ever possibly do this?”

The next generation of engineers and architects on the UEM/MDM track need to know about areas like IAM or identity and access governance. You can grow into these types of roles with the right amount of effort, focusing on a few key technologies:

• Active Directory and LDAP
• Basic network fundamentals
• SAML
• Kerberos and SSL security and certificates
• Web server technologies

If you take the time to learn about these technologies (or read some of my deep dives) you will grow closer to that goal.

IAM can seem daunting, but it’s about understanding organizational requirements at a high level and delivering them. It’s simply taking “I only want people on our internal network to have access to our 401(k) IF they use our MFA” and turning that into a workflow. Or, it’s “I want to use Office 365 conditional access policies to stop legacy authentication on email clients, and mandate modern authentication instead.”

We can do better and we can evolve, but you need to have the drive, passion, and dedication to do so. No person is an island, and only by collaborating can it become reality.