Why identity management matters to mobility engineers

The next phase of your career can be paved by identity and access management.

In the late 90s, BlackBerry Enterprise Server (or BES) came out and opened up a whole new world for IT. We now had new mobility roles enter the market. The role of a mobility administrator/engineer/architect was beginning to take shape, while trying to jockey for position among vSphere, Exchange, storage, and server administrators. A long road would be ahead of them to earn the respect and admiration of their peers.

Today, another new world is again taking shape for mobility professionals. Largely due to Windows 10 and modern management APIs, the lines are blurring between endpoint management and mobility’s illegitimate love child, unified endpoint management. Mobility administrators might find themselves phased out because of the skill sets required in this new world. It’s similar to when telecom administrators were replaced to make way for mobile administrators.

Mobile administrators are now asked to understand the intricacies of Windows 10, macOS, and even identity. Combined identity and EMM scenarios now resonate with companies, and you have to take new device characteristics into account, like location, security level, user role, and more.

If you’re a mobile admin, it’s time for you to evolve and learn how identity affects your position.

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:

mobility engineers need to evolve
VMware Identity Manager architecture. Click for high-resolution version

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.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close