I know, it’s only a few days since I discussed deploying Jamf Connect Login with OneLogin, but as many people are using Jamf Connect with different iDP’s, let’s quickly have a look at another one: Google Cloud Identity.

Before taking it out for a spin, have a look at the admin guide here. As with all other iDP’s and Jamf Connect, the idea is to create an app in Google Cloud, and configure Jamf Connect via a config profile or custom settings plist.

However, Google is a bit different compared to other iDP’s and there are a few things I’d like to highlight before we have a look at the deployment.

First of all, Google does not support ROPG operations. This means that validating the Google password during the user creation won’t be possible. Hence the key “OIDCNewPassword” needs to be set to <true/>. This means that the user will be asked to create a local account password (instead of getting a second authentication screen to validate the password).

NOTE: The OIDCNewPassword key MUST be set, skipping it will make the Jamf Connect Login screen loop. Same for trying to set it to <false/>, it needs to be set to <true/>.

Furthermore, Google also needs a “Client secret”, set via the “OIDCClientSecret” key. See below.

Finally, while other iDP’s (see the manifest of an Azure app for instance) allow to use “roles” to define who gets Admin privileges at he login screen, it seems the Google iDP design does not allow to do so. When using Jamf Connect with Okta you can set the “OIDCAdminClientID” to another Native app, to grant Admin privileges, but the way OAuth works in Google this is not possible either.

With Google ID, based on what’s possible in Google ID and Jamf Connect at the moment, it seems that you can’t create different OAuth apps and assign users based on roles. Information about this was recently corrected in the Jamf deployment guide:

Once credentials are successfully created and saved for Jamf Connect Login, you can determine if all users are created as an "admin" or "standard" user with the CreateAdminUser key. This key applies to all users. 
Note: Configuring whether each user is created as an "admin" or "standard" user is currently not supported with Google ID.

You could however create a new project within your organisation and create another OAuth Client ID, with a different ID and Secret. This would then allow you to differentiate Admin users from Standard users by creating separate config profiles in Jamf Pro and scope them accordingly. In the settings of the profile for the Admin Users you would then add the “CreateAdminUser” key to make them all admins, while omitting that key in the profile you scope to your Standard Users.

Note: you could actually just use the same OAuth credentials and push different config profiles to the Mac used by Standard and Admin users... just set the "CreateAdminUser" for those Admin privileged Macs... you don't really need to create another project as it doesn't really change much.

Compared to other iDP’s which allow you to define roles, this is however a bit less seamless as you’ll need to think about a scoping strategy in Jamf Pro, on a device level via a different preStage and different preinstalled profiles.

This doesn’t really seem handy to me, so I’d just go for another approach: make everyone Standard and promote your Admin users post enrolment.

Note: :-) just think about your Secure Tokens... if you make your Google iDP Jamf Connect users Standard... don't log in with a Local Admin account (or the Management Account) before the end user creates an account... check out my Secure Tokens Category for related posts :-)

Anyway, that said, let’s have a look at how to do a basic deployment of Jamf Connect Login with Google iDP (Google Cloud Identity).

As always, we have to start at the iDP side of things, before we can deploy and configure Jamf Connect Login. First thing to do is creating OAuth client ID credentials. Go to APIs & Services -> Credentials -> Create Credentials -> OAuth client ID:

Set the application type to “Web Application”, give the app a name and enter “https://127.0.0.1/jamfconnect” in the Authorized redirect URIs field:

Once the credentials have been created you’ll have access to the Client ID and Secret which we’ll need in our config profile:

By default all Google accounts in your organisation have access to the Jamf Connect app, and as said, there is no way to differentiate Standard versus Admin users in Google iDP at the moment.

In the OAuth Consent screen you can however define if a Google Account from outside your organisation can login. As I don’t see a reason to do that (quite the opposite from what you’d want from a security point of view I guess), as well as the fact this needs to be reviewed by Google, I did not test this. Just pointing it out because if the user tries to connect with a Google account which does not belong to your organisation, he/she will get this:

The fun fact is however, that apart from clicking the Local Auth button, there seemed to be no way out of this screen, as “Refresh” didn’t clear it… Even a reboot didn’t let me do another login either.

However, while being stuck at this screen, I updated the config profile, added the “OIDCIgnoreCookies” key, pushed it to the Mac and this fixed it.

<key>OIDCIgnoreCookies</key>
<true/>

Ok, apologies for deviating from the main topic… back to the config. Once you have your Google Cloud side of things configured, it basically comes back to deploying Jamf Connect Login and pushing the config profile. As there is no need to tweak the Authchanger, you can just deploy the official Jamf Connect Login package (tweaking the Authchanger is only needed for Okta).

The mandatory keys for Google ID are:

– OIDCProvider
– OIDCNewPassword -> !!! set it to true !!!
– OIDCRedirectURI
– OIDCClientID
– OIDCClientSecret
– OIDCIgnoreCookies (if needed, see above)

The rest is similar to all other Jamf Connect deployments: add the plist as a custom setting in a Jamf Pro Config Profile and scope it to your devices (preferably add it as a preinstalled config profile in a preStage but don’t forget the scope to keep it assigned to the devices post enrollment).

The Google OIDC screen…
… asking to sign in.
Next step is allowing Jamf Connect to use the Google account.
And finally the end users has to create a local password. As said, because Google ID does not allow ROPG operations.

That’s it! Within the limitations of Google ID, I did not really have any roadblocks!

As always, if you have any comments, remarks or suggestions, leave a message down below, and if you like this blog, tell your friends about it and leave some feedback here.

Grtz,
TTG

Print Friendly, PDF & Email