Single Sign On: What happens on the back end to handle authentication and authorization

Watch this JNUC session in its entirety.

Jamf supports a lot of tools. But how? In today’s session, Jamf product experts, William Smith and Joel Seeger, discussed what happens on the back end to handle authentication and authorization, as well as the Security Assertion Markup Language (SAML) spec and how Jamf interprets it. As the developers who write the tools, and engineers to deploy them, these presenters had the inside scoop on what it all means.

The session began with a look at SAML 2.0. “Defining SAML is more easily done from right to left,” Smith said, “so let’s start from the right.” He continued, “SAML is a markup language, as as Mac admins, you’re probably already familiar with a few markup languages, such as HTML, Markdown and XML.”

A quick explanation:

HTML: The prevalent markup language for web pages and email formatting.

Markdown: A more readable alternative to HTML. Used in popular blogging software (and the JSS).

XML: Common markup language for exchanging data between a variety of systems and platforms. (It’s all over macOS.)

With that explained, Smith turned back to SAML with a quick definition for Assertion. “Assertions are used to pass information between the end-user and an identity provider,” Smith explained. “SAML uses three types of assertions.”

1) Authentication Assertion: Identifies a specific user was authenticated at a specific time.

2) Attribute Assertion: Includes user data, such as name, email, department and user’s role.

3) Authorization Assertion: States whether a user is allowed access to a resource.

“The Identity Provider manages all this information,” Seeger explained. “While they don’t necessarily use SAML, you’ve more than likely used Facebook, Twitter, LinkedIn or Google to identify a third-party website. These organizations are acting as identity providers, allowing you to log in with credentials you already have, as opposed to making you create new credentials.”

The Service Provider integrates and trusts the Identity Provider to provide the proper authorization. “This would be your JSS or Self Service,” Seeger said. “Jamf currently supports a number of Identity Providers, and because SAML 2.0 is a standard, your JSS should integrate with any Identity Provider supporting that standard.”

Jamf-supported Identity Providers

• Active Directory Federation Services
• Google Apps for Work
• Okta
• One Login
• Ping Identity
• Shibboleth

And that’s where security comes into SAML 2.0. Similar to using Active Directory for Mac logins and access to servers, SAML allows a client to use a single identity to access multiple resources. This is Single Sign-On (SSO). Users can integrate Active Directory with an external Identity Provider to securely authenticate users outside the network, without exposing a domain controller to the Internet.

Smith and Seeger then looked behind the scenes of SSO and showed the process of setting up a test environment. All-in-all, they said it’s a fairly easy setup. “Okta can act as a cloud directory service for small organizations,” Smith said. “But larger organizations will want to utilize their existing directory services, such as Active Directory. That’s where Integrations come in.”

Another demo followed. “And after configuring your Identity Provider and connecting it to Active Directory, the last step for using SSO with your JSS and Self Service is to connect your JSS to the Identity Provider, Seeger explained.

Need more information? Find an assortment of knowledge-base articles about all supported Identity Providers at jamf.com.