macOS - Certificate Based Authentication - App Level or OS Level?

[AntonThirifays]

Hello,

We're currently working on revamping our macOS design.

While working on it came of course the question of proxies and specifically the authentication onto them.  We have several possibilities for that but it comes along to answer to the following question :

Is it the OS on the Mac that deals with the Certificate Based Authentication aspect or is it each installed app individually ?

If it is the latter, for apps like Safari, we're pretty confident this will work properly because of Safari knowing how to handle certificates.

Regarding 3rd party apps, (Bluejean, Adobe Suite...), this is not so sure these would be able to exploit the certificates present in the keychain. Hence the question about CBA being handled by macOS itself or by every single app individually.

If anyone knows, that'd be good to know.

Thanks,

Anton

[rterakedis]

AntonThirifays​,

For starters, it's a little of both (OS vs App).   For anyone that may be new to macOS and reading this post, WS1 UEM allows you to send credentials (e.g. Certificates) as a "User" profile OR a "Device" profile.   This means the certificate is delivered by the mdmclient process into the login keychain, or the system keychain (respectively).   Certs within the system keychain are typically used for system-wide processes or actions --> 802.1x connectivity, etc.    

As you mentioned, Safari generally knows how to handle certificates, and it does so by matching against certificates in the login keychain.  You can control which certificates get chosen using the "identity preferences" functionality in the credentials payload.   Many third-party apps don't handle cert-auth directly, and instead offer federated or SAML authentication.  By doing this, the app can present some type of in-app view (or alternatively refer the user to the mobile browser) to handle the authentication using the certificate.  

That said, Apple's new "SSO Extension" functionality aims to handle some of this complexity.   The point here would be that the extension could perform authentication (such as certificate-based authentication) on behalf of any app on the device.  In this case, the apps wouldn't need to maintain any type of authentication as the extension should handle it.

See the WWDC 2020 video here:  https://developer.apple.com/videos/play/tech-talks/301/

Hope that helps.  

Rob

[AntonThirifays]

Hi rterakedis​

Thanks for the insight and valuable information.

Ok gotcha, I thought the prerequisite for SSO Extension to work was that the Mac to be placed on a network that could reach the DCs, but it just needs to be able to access the IDP.

In our case, the IDP is a different service.

If I get you right, if we'd like for any app present on the Mac, we would have to push a user-based macOS profile onto our Macs.

This profile would contain at least the following payloads :

- Credentials > In order to have our authentication certificates pushed on the device

- Custom Settings > In order to have the piece of code needed to activate the SSO Extensions

Regarding the SSO Extensions code in Custom Settings payload, we would need to implement at least these code considerations :

class ASAuthorizationSingleSignOnProvider

A mechanism for generating requests to authenticate users with third-party providers.

class ASAuthorizationSingleSignOnCredential

A credential that results from a successful single sign-on (SSO) authentication.

plus of course custom settings :

Extension Identifier

Team Identifier

Sign-On Type

Realm

Hosts

URLs

as specified on https://developer.apple.com/documentation/devicemanagement/extensiblesinglesignon and https://support.apple.com/en-in/guide/mdm/mdmfd9cdf845/web

Am I right in my statements ?

Thanks for your help,

Anton

[jebrum]

Is there any sort of guide for setting this up for use with WS1 Access or w/ Okta since the two can integrate together?