Configuring Mobile SSO (for Apple) Authentication in Omnissa Access (Cloud only)

To set up Mobile SSO (for Apple) authentication, you configure the Mobile SSO (for Apple) certificate-based authentication settings in the Omnissa Access console and upload the issuer certificate for certificate-based authentication.

You configure the cloud-based authentication methods in the Omnissa Access console Integrations > Authentication Methods page. After the authentication method is configured, you associate the authentication method with an Omnissa Access built-in identity provider in the Integrations > Identity Provider page, and create access policy rules to apply to the authentication method in the Resources > Policies page.

How Mobile SSO (for Apple) Single Sign-on Authentication Certificate Authentication Settings are used

To enable logging in using Mobile SSO (for Apple) certificate authentication, root certificates and intermediate certificates must be uploaded to the Omnissa Access service. The X.509 certificate uses the public key infrastructure (PKI) standard to verify that a public key contained within the certificate belongs to the user.

When you configure Mobile SSO (for Apple) ) certificate-based authentication settings, you set the user identifier search order to locate the user identifier within the certificate. For Mobile SSO (for Apple) authentication, the value of the identifier attribute must be the same value in both Omnissa Access and Workspace ONE UEM services. Otherwise, Apple SSO fails.

You also create a list of object identifiers (OID) that are accepted in the certificate policies extensions. The OID is an identifier that is tied to the Certificate practice statement. The following value is an example of an OID name space 1.3.6.1.4.1.{PENnumber}.

You can configure certificate revocation checking to prevent users who have their user certificates revoked from authenticating. Certificates are often revoked when a user leaves an organization or moves from one department to another.

For additional security, you can configure the Device Settings Type to require users to use a biometric method to unlock the device before the certificate is used to authenticate the sign-in. If this setting is configured, every time a user accesses an app that requires certificate authentication, they are asked to enter the biometric method you configured.

Configuring Revocation Checking Settings

Certificate revocation checking with certificate revocation lists (CRL) and with the Online Certificate Status Protocol (OCSP) are supported. A CRL is a list of revoked certificates published by the CA that issued the certificates. OCSP is a certificate validation protocol that is used to get the revocation status of a certificate.

You can configure both CRL and OCSP in the same certificate authentication adapter configuration. When you configure both types of certificate revocation checking and the Use CRL in case of OCSP failure check box is enabled, OCSP is checked first and if OCSP fails, revocation checking falls back to CRL. Revocation checking does not fall back to OCSP if CRL fails.

When you enable certificate revocation, the Omnissa Access server reads a CRL to determine the revocation status of a user certificate. If a certificate is revoked, authentication through the certificate fails.

Logging in with OCSP Certificate checking is an alternative to certificate revocation lists (CRL) that is used to perform a certificate revocation check.

When you configure certificate-based authentication, when Enable Cert Revocation and Enable OCSP Revocation are both enabled, Omnissa Access validates the entire certificate chain, including the primary, intermediate and root certificates. The revocation check fails if the check of any certificate in the chain fails or the call to the OCSP URL fails.

The OCSP URL can either be configured manually in the text box or extracted from the Authority Information Access (AIA) extension of the certificate that is being validated.

The OCSP option that you select when you configure certificate authentication determines how Omnissa Access uses the OCSP URL.

• Configuration Only. Perform certificate revocation check using the OCSP URL provided in the text box to validate the entire certificate chain. Ignore the information in the certificate's AIA extension. The OCSP URL text box must also be configured with the OCSP server address for revocation checking.
• Certificate Only (required). Perform certificate revocation check using the OCSP URL that exists in the AIA extension of each certificate in the chain. The setting in the OCSP URL text box is ignored. Every certificate in the chain must have an OCSP URL defined, otherwise the certificate revocation check fails.
• Certificate Only (Optional). Only perform certificate revocation check using the OCSP URL that exists in the AIA extension of the certificate. Do not check revocation if the OCSP URL does not exist in the certificate AIA extension. The setting in the OCSP URL text box is ignored. This configuration is useful when revocation check is desired, but some intermediate or root certificates do not contain the OCSP URL in the AIA extension.
• Certificate with fallback to configuration. Perform certificate revocation check using the OCSP URL extracted from the AIA extension of each certificate in the chain, when the OCSP URL is available. If the OCSP URL is not in the AIA extension, check revocation using the OCSP URL configured in the OCSP URL text box. The OCSP URL text box must be configured with the OCSP server address.

Configure Certificate Authentication for Mobile SSO (for Apple)

Prerequisites

• Save the issuer certificate that you will upload for Mobile SSO (for Apple) authentication. If you are using the Workspace ONE UEM certificate, export and save the root certificate from the Workspace ONE UEM console System > Enterprise Integration > Omnissa Access > Configuration page.

• (Optional) List of Object Identifier (OID) of valid certificate policies for certificate authentication.

• For revocation checking, the file location of the CRL and the URL of the OCSP server.

• (Optional) OCSP Response Signing certificate file location.

• (Optional) Select the biometric authentication to configure.

• If you want to use TLS 1.3 for SSL connections, see KB article 6000726 for the prerequisites that you must complete before enabling the option.

Procedure

1. In the Omnissa Access console, go to the Integrations > Authentication Methods page and select Mobile SSO (for Apple).

2. Click CONFIGURE and configure the certificate authentication settings.

   Option	Description
   Enable Certificate Adapter	Toggle to Yes to enable certificate authentication.
   Use TLS 1.3 for SSL connections	Toggle to Yes to enable TLS 1.3 for SSL connections. TLS 1.3 provides security enhancements and performance improvements. By default, TLS 1.2 is used. CAUTION: See [KB article 6000726](https://kb.omnissa.com/s/article/6000726) before enabling this option. The Certificate Authentication Service (CAS) hostnames used for TLS 1.3 are different than those used for TLS 1.2. If you enable the TLS 1.3 option, you might also need to update your network configurations (proxy and firewall configurations) and device profiles to support the new CAS hostnames. See the KB article for more information about using TLS 1.3 and the actions required.
   Root and intermediate CA certificates Uploaded CA Certificates	Select the root certificate that you saved from the Workspace ONE UEM console to upload. The certificate files that are uploaded are listed here.
   User Identifier Search Order	Select the search order to locate the user identifier within the certificate. For Mobile SSO (for Apple) authentication, the value of the identifier attribute must be the same value in both Omnissa Access and Workspace ONE UEM services. Otherwise, Apple SSO fails. upn: The UserPrincipalName value of the Subject Alternative Name. email: The email address from the Subject Alternative Name. subject: The UID value from the Subject. If the UID is not found in the subject DN, the UID value in the CN test box is used, if the CN text box is configured. Note: If a Workspace ONE UEM CA is used for client certificate generation, the User Identifier Search Order should be Subject | UPN. If a third-party enterprise CA is used, the User Identifier Search Order must be UPN \| Email | Subject and the certificate template must contain the subject name CN={DeviceUid}:{EnrollmentUser}. Make sure to include the colon (:).
   Validate UPN Format	Toggle to Yes to validate the format of the UserPrincipalName text box.
   Request Timeout	Enter the time in seconds to wait for a response. If you enter zero (0), the system will wait indefinitely for a response.
   Certificate Policies Accepted	Create a list of object identifiers that are accepted in the Certificate Policies extensions. Enter the objectID numbers (OID) for the Certificate Issuing Policy. Click Add to add additional OIDs.
   Enable Cert Revocation	Toggle to Yes to enable certificate revocation checking. Revocation checking prevents users who have revoked user certificates from authenticating.
   Use CRL from Certificates	Toggle to Yes to use the certificate revocation list (CRL) published by the CA that issued the certificates to validate the status of a certificate, revoked or not revoked.
   CRL Location	Enter the server file path or the local file path from which to retrieve the certificate revocation list.
   Enable OCSP Revocation	Toggle to Yes to use the Online Certificate Status Protocol (OCSP) certificate validation protocol to set the revocation status of a certificate.
   Use CRL in case of OCSP failure	If you set up both CRL and OCSP, you can enable this toggle to fallback to use CRL if the OCSP checking option is not available.
   Send OCSP Nonce	Enable this toggle if you want the unique identifier of the OCSP request to be sent in the response.
   OCSP URL	If you enabled OCSP revocation, enter the OCSP server address for revocation checking.
   OCSP URL Source	Select the source to use for revocation checking. Select Configuration Only to perform certificate revocation check using the OCSP URL provided in the OCSP URL text box to validate the entire certificate chain. Select Certificate Only (required) to perform certificate revocation check using the OCSP URL that exists in the Authority Information Access (AIA) extension of each certificate in the chain. Every certificate in the chain must have the OCSP URL defined, else the certificate revocation check fails. Select Certificate Only (optional) to only perform certificate revocation check using the OCSP URL that exists in the AIA extension of the certificate. Do not check revocation if the OCSP URL does not exist in the certificate AIA extension. Select Certificate with fallback to configuration to perform certificate revocation check using the OCSP URL extracted from the AIA extension of each certificate in the chain, when the OCSP URL is available. If the OCSP URL is not in the AIA extension, the fallback is to check revocation using the OCSP URL configured in the OCSP URL text box. The OCSP URL text box must be configured with the OCSP server address. </li>
   OCSP Responder's Signing Certificates Uploaded OCSP Signing Certificates	Select the OCSP Responder Signing Certificates files to upload. The uploaded OCSP Responder Signing Certificates files are listed here.
   Issuer CA Certificates	You can use this option to limit the number of certificates that are presented to users when they authenticate with the Mobile SSO (for Apple) authentication method, if required. Click Select File and upload a subset of the certificates uploaded in Root and intermediate CA certificates to use as issuer certificates. Only the identity certificates issued directly by the uploaded Issuer CA Certificates will be available for user authentication. When a user authenticates with the Apple Mobile SSO authentication method for the first time on a device (for example, by launching an app), the user is prompted to select a certificate from the list of installed identity certificates. The list will only contain the certificates issued directly by the Issuer CA Certificates. If no certificates are uploaded to Issuer CA Certificates, identity certificates issued by all the certificates uploaded to Root and intermediate CA certificates are presented to the user. Important: The Issuer CA Certificates must be a subset of the Root and intermediate CA certificates.
   Device Auth Type	Mobile SSO (for Apple) supports requiring that the user authenticate with the device using a biometric mechanism (FaceID or TouchID) or a passcode before the certificate on the device is used to perform the authentication with Omnissa Access. If users must verify with biometric or biometric with passcode as a backup, select the correct option. Otherwise select NONE.

3. Click SAVE.

   The configuration settings are shown on the Mobile SSO (for Apple) authentication methods page.

   

Configure a Built-in Identity Provider

In the Omnissa Access built-in identity provider page, configure the users, network ranges, and authentication methods that users use for single sign-on to their apps portal.

Prerequisites

To configure the built-in identity provider, make sure that you complete the following tasks.

• Users and groups located in your enterprise directory synced to the Omnissa Access directories.
• Network ranges created in the Resources > Policies > Network Ranges page.
• The Mobile SSO (for Apple) authentication methods configured.

Procedure

1. In the Omnissa Access console Integrations > Identity Providers page, click ADD and select the identity provider labeled Built-in IDP and configure the identity provider settings.

   Option	Description
   Identity Provider Name	Enter the name for this built-in identity provider instance.
   Users	Select which users to authenticate. The directories that you configured are listed.
   Add a Connector/ Connector Authentication Methods	N/A
   Authentication Methods	The authentication methods that are configured in the Integrations > Authentication Methods page are displayed. Select Mobile SSO (for Apple).
   Network	The existing network ranges configured in the service are listed. Select the network ranges for the users based on the IP addresses that you want to direct to this identity provider instance for authentication.
   KDC Certificate Export	N/A

2. Click SAVE.

What to do next

Configure the default access policy rule for Mobile SSO (for Apple).