Creating Applications for Limiting Access to Devices

Jamf Connect Documentation
Solution
Application
Jamf Connect
Content Type
Technical Documentation
Utilities & Services
ft:locale
en-US

The Jamf Connect login window can be used by an OIDC application to limit access or local administrator rights to users based on group membership. If the Okta Authentication API can authenticate the user to the application, they are a member of the group and are granted the permission.

Additionally, use of the Jamf Connect login window for this purpose is only supported when your Identity Provider (OIDCProvider) setting in your Jamf Connect Configuration is set to Okta. If your Identity Provider (OIDCProvider) setting is set to Okta-OIDC or OktaIdentityEngine, see OpenID Connect User Role Settings for more information about the Admin Roles (OIDCAdmin) and the Secondary Access Group (OIDCSecondaryAccess) settings.

There are three permissions that can be granted:

Access Client ID OIDCAccessClientID
Specifies the OIDC application to use for users that are allowed to create an account or log in to computers.
Admin Client ID OIDCAdminClientID
Specifies the OIDC application to use for users who are created as local administrators during account creation.
Secondary Login Client ID OIDCSecondaryLoginClientID
Specifies the OIDC application to use for users that are allowed to create additional users on computers after the first account is created. This setting would allow a select group of users to create additional user accounts (IT administrator staff doing one-off, hands on administrative tasks, for example), and prevent unauthorized users from using 1:1 equipment issued to another person.
When logging into a device, the Jamf Connect login window will evaluate a user login with the following order:

  • Check the status of the DenyLocal flag

    • If false or undefined, check the local macOS user database. Authenticate the user locally if the account exists. Keep existing account permissions.

    • If true, continue and authenticate the user against the Okta tenant with the Okta Authentication API.

  • Use the access token from the authentication to the Okta tenant to determine:

    • If defined, is the user able to authenticate to Access Client ID (OIDCAccessClientID) app?

    • If defined, is the user able to authenticate to Secondary Login Client ID (OIDCSecondaryClientID) app and is there an existing local user account with a local password?

    • If defined, is the user able to authenticate to the Admin Client ID (OIDCAdminClientID) app?

Additionally, the use of the limiting applications is optional, and one or multiple applications can be defined depending on your organization login requirements.

Example: A call center uses a shared desk environment for their Macs. Anyone who is a member of the call center team should be allowed to log into Macs. Others, like members of the Caffeination team, should not be allowed to log into a Mac.

All users should be standard. Define an app to be used for Access Client ID (OIDCAccessClientID). Assign a group of call center team users to the app in Okta. Only users assigned to that app will be able to log into a Mac and may create an account on any computer. No user will become an administrator.