When users and devices authenticate to your network, you should ideally have as much information from them as possible to make context-rich security decisions. Certificate-based authentication (CBA) empowers administrators to make those decisions by providing a detailed snapshot of each network connection.
But some infrastructure, especially Identity Providers (IDPs) limit the types of certificates you can create due to the way they store information. Some are more user-focused, storing user objects, and others allow for both user and device objects.
The good news is that, with a flexible managed PKI, even if you have a user-focused IDP, you can still achieve device authentication with user attributes. Here’s how.
Cloud Directories and Storing User Data
Your Identity Provider or directory is a key part of any Zero Trust infrastructure, providing the foundation for segmented network access through roles and groups. These policies can be applied to network authentication, and your policy options expand dramatically if you use context-rich digital certificates instead of credentials for authentication.
However, many of the popular IDPs in use today store information a little differently from each other. Here are some examples from a few common IDPs:
- Okta stores user objects.
- Azure Active Directory can store both user and device objects.
- Google generally stores only user objects, but can store device objects in Chromebook environments.
- Active Directory stores both user and device objects together.
This disparity can make certificate-based authentication a little tricky. Certificates generally fall into one of two categories depending on the types of information encoded within:
- Device/Machine Certificates
- User Certificates
User vs Device X.509 Certificate Attributes
Nearly all X.509 certificates contain the following attributes:
- Subject
- DNS
- Issuer
- Validity
- Key Size
- Signature Algorithm
- Serial Number
- Subject Alternative Name (SAN)
But on user certificates, you may have a template more tailored to identifying individual users rather than machines. These are the types of fields that are generally used in that scenario:
- Username
- Common Name
- SAN-UPN
- SAN-Email
With device certificate authentication, your certificate will usually be encoded with device-specific unique identifiers such as Client ID or computer identity.
If you have a user-focused directory like Okta, authenticating devices with device certificates can be a challenge. This is because generally, the identifying information used on a device certificate tends to be device-specific, while the information stored in Okta tends to be user-specific. We’ll explain what the differences are between these certificate types and how authentication works with either type in more detail.
Device Authentication vs User Authentication: What is the Difference?
Certificates can be issued to either devices/machines or users. While both types of certificates are still stored on the device, they work differently when it comes to authentication.
User certificates are attached to a particular user profile on the device. They’re used to grant varying levels of access depending on who logs in. This is useful for scenarios where the device is shared between multiple users, such as an office computer.
On the other hand, device certificates are assigned to the device itself rather than the user profile. They apply authorization to the whole machine and do not change if someone logs into it. This type of certificate is useful for scenarios in which the device either has only a single user or is an IoT device that doesn’t really have individual users at all.
Aside from the use cases mentioned above, there are other factors that determine whether you’ll use a device or user certificate. One is operating system; Windows devices have both user and machine certificate stores, as do MacOS devices. This is because these are desktop operating systems, and desktop computers are likelier to have multiple users, whereas mobile devices generally don’t. For that reason, common mobile device OSs, such as iOS, tend not to make a distinction between user and device certificates.
Your directory/IDP and the type of information it stores, as well as where it stores that information, can also be a determining factor in the certificates you use. As we mentioned previously, many IDPs are more user-focused, so they benefit from using devices that have user information encoded into them.
Fortunately, SecureW2’s JoinNow Connector PKI allows you to completely customize certificate templates, so you can encode user attributes onto device certificates. The end result is that you can authenticate device certificates by searching for information such as email address.
You can also back our PKI with our powerful Cloud RADIUS, a RADIUS service designed for passwordless authentication. Cloud RADIUS is capable of performing both device-based and user-based lookups at the moment of authentication. The end result is that it can apply policy changes the moment you update a user’s or device’s information in your directory.
User-Centric NAC vs Device-Centric NAC
When it comes to network security, the more information your administrators have, the better. Being able to apply certificates to both users and devices can provide a much more holistic view of the activity on your network since user and device certificates often contain different information in their templates.
Additionally, either type of certificate allows you to segment users in different ways. For example, user certificates on a shared device make it possible for multiple people to log into the device and receive their own unique levels of authorization. This is a distinct advantage of certificate-based auth over credential-based auth – there’s no way to share certificates like you can with passwords, so you can be certain that each user only has their intended level of access (as well as having high identity assurance as to which person is actually using the account).
Device certificates, on the other hand, are excellent for IoTs and devices with just one user. Even in situations where you have multiple users on one device, equipping a device certificate to the computer in question allows it to authenticate and connect to your Wi-Fi before a particular user has logged in.
Regardless of your situation, our PKI gives you the ability to issue both user and device certificates, then customize the templates with whichever identifying information you need. That means you can authenticate individual users with device certificates, which can come in handy when you need to use a machine certificate and a user-focused directory.
How Does Device Authentication Work?
Using certificates for authentication increases the security of your network by providing clear context for every network connection. However, if you’re using certificates, you’ll need something to authenticate them with, like a RADIUS server.
In short, a RADIUS server is an authentication server that functions like a bouncer at the gate to a club. It checks the certificates of the devices accessing your network to ensure they are authorized, then grants them access accordingly.
However, that’s just a brief overview of what device authentication with a certificate looks like. In reality, it’s a multi-step process that follows these steps:
- The device attempts to connect to your network and presents a certificate to the RADIUS server.
- The RADIUS checks that the device’s certificate is unexpired.
- If the certificate is unexpired, the RADIUS then checks to see if the certificate is on the Certificate Revocation List (CRL) to confirm whether or not it has been revoked.
- If the RADIUS supports Identity Lookup (such as our Cloud RADIUS), it will check your directory in real-time by searching for information contained in the certificate.
During the Identity Lookup step, RADIUS will confirm that the user principal name (usually an email address) exists in your directory, what group the user belongs to, and what their device’s ID is. Even if you have a user-based IDP like Okta, you can still authenticate device certificates at this point with user information such as email addresses.
The reason this optional step is so important is that it provides the most up-to-date information to the RADIUS server. Even if the personnel managing the PKI haven’t gotten around to revoking a certificate from a device yet, the moment that user’s information is updated in your IDP to reflect they no longer need access, the RADIUS will authenticate accordingly.
Customize Attributes for Both Users and Devices with SecureW2
Certificate-based authentication is significantly more secure than the alternative of credentials – not only because it eliminates credential theft, but also because it allows you to easily differentiate between users and devices. Your infrastructure doesn’t have to limit you in this regard. Our JoinNow Connector PKI gives you complete control over the certificates you issue, allowing you to encode user attributes into device certificates.
In addition to our PKI, we offer an effective Cloud RADIUS service designed for certificates – that way, you can back up your Zero Trust architecture with the assurance of passwordless authentication. Check out our pricing to see what solutions we offer, and how affordable they can be for your organization.
