Certificate authentication from AppConnect apps to enterprise services

An AppConnect app can send a certificate to identify and authenticate the app user to an enterprise service. The AppConnect library, which is part of every AppConnect app, makes sure the connection uses the certificate. No additional development is required for the app.

When an AppConnect app uses a certificate to authenticate the app user to an enterprise service using HTTPS:

  • The authentication occurs without interaction from the app user.

    The app user does not need to enter a user name and password to log into enterprise services, resulting in a better user experience.

  • Access to the enterprise service is more secure.

The AppConnect app must use networking methods that this feature supports. Contact the application vendor or developer to find out if the app supports certificate authentication to enterprise services.

You configure which certificate to use and when to use it on MobileIron Core as described in Setting up certificate authentication from an AppConnect app. When using this feature, you can also use Certificate pinning for AppConnect apps. Certificate pinning ensures that the certificate presented by the enterprise service in response to the app's connection request is in a trusted set of certificates that you configure.

Certificate authentication from AppConnect apps to enterprise services:

  • is for HTTPS connections only.
  • does not work if you are using AppTunnel with HTTP/S tunneling for the connection.
  • does work if you are using AppTunnel with TCP tunneling for the connection.

Authenticating users to enterprise servers using Kerberos Constrained Delegation (KCD) with AppTunnel has been available for some time. This feature does not use KCD or AppTunnel.

Impact on AppTunnel use

If an AppConnect app uses a certificate to authenticate the app user to an enterprise service:

  • The app can use AppTunnel with TCP tunneling (provided with the Tunnel app) to access an enterprise service.

  • The app cannot use AppTunnel with HTTP/S tunneling for accessing the same URL to which the certificate authenticates.

    The app can use AppTunnel for HTTP/S tunneling for accessing a different URL than the one that the certificate authenticates to.

Setting up certificate authentication from an AppConnect app

To set up certificate authentication from an AppConnect app to an enterprise service, you configure the app’s AppConnect app configuration on MobileIron Core. You add sets of two key-value pairs to the AppConnect app configuration. The two key-value pairs in each set specify:

  • a certificate

  • a URL matching rule

You can have any number of sets of these key-value pairs, but keep the number to a minimum to preserve Core performance.

When the app makes a web request to a URL that matches a URL matching rule, the connection uses the certificate.

Before you begin 

Configure MobileIron Core with the certificate that the app will use to authenticate to the enterprise service. You specify the certificate in a Certificate Enrollment.

See “Certificate Enrollment settings” in the Core Device Management Guide for iOS and macOS Devices.

It is not necessary to assign labels to the Certificate Enrollment setting to distribute certificates to the appropriate devices. You will configure and apply labels to an AppConnect app configuration that refers to the certificate enrollment setting. That action distributes the certificates to the appropriate devices.

 

  1. Creating an AppConnect app configuration for the app if one does not already exist.

  2. Configuring the key-value pairs for the certificate and URL matching rule.

Creating an AppConnect app configuration for the app if one does not already exist

Check if you already created an AppConnect app configuration for the app. If one does not exist, create an app configuration for the AppConnect app.

Procedure 

  1. Go to Policies & Configs > Configurations.

  2. Look for an APPCONFIG setting type for the app.

  3. If found, continue to Configuring the key-value pairs for the certificate and URL matching rule.

If not found, create the AppConnect app configuration:

  1. Click Add New > AppConnect > App Configuration.

  2. For Name, enter a name for the AppConnect app configuration.

  3. For Description, enter a description for the AppConnect app configuration.

  4. For Application, enter the bundle ID of the app, or select the app from the drop-down list if it is in the App Catalog.

  5. Click Save.

  6. Select More Actions > Apply to Label.

  7. Select the appropriate label and click Apply.

Configuring the key-value pairs for the certificate and URL matching rule

Configure key-value pairs for the certificate and URL matching rule in the AppConnect app configuration in the Core Admin Portal.

Procedure 

  1. Go to Policies & Configs > Configurations.

  2. Select the AppConnect app configuration for the app (the Setting Type is APPCONFIG).

  3. Click Edit.

  4. Scroll down to App-specific Configurations.

  5. Click Add+.

  6. In the KEY field, enter MI_AC_CLIENT_CERT_#, substituting digits of your choice for #. The key is case-sensitive.

    Example  

    MI_AC_CLIENT_CERT_1

    MI_AC_CLIENT_CERT_2

    MI_AC_CLIENT_CERT_15

    You can have many MI_AC_CLIENT_CERT_# keys, each with a different digit substitution.

  7. In the VALUE field, select the Certificate Enrollment setting from the drop-down list.
  8. Click Add+.

  9. In the KEY field, enter MI_AC_CLIENT_CERT_#_RULE, substituting the same digits for # that you used in MI_AC_CLIENT_CERT_#. The key is case-sensitive.

    Example  

    MI_AC_CLIENT_CERT_15_RULE

     

  10. In the VALUE field, enter the URL that will use the certificate for authentication.

    Example  

    *.mycompany.com/sales

    myserver.mycompany.com/hr/benefits

  11. Click Save.

Details about MI_AC_CLIENT_CERT_#_RULE

The following describes the rule format and matching logic for the certificate key-value pair.

Rule format

The value for the key MI_AC_CLIENT_CERT_#_RULE is a URL matching rule. The rule has one of these formats:

  • <host >
  • <host >/<path>

The <host > component specifies a host within a domain. It can include one or more wildcard characters *.

Example  

  • myserver.mycompany.com
  • anotherserver.mycompany.com
  • *.mycompany.com

The <path > component specifies a path within the host. It cannot include the wildcard character *. It can contain multiple <subpath> components.

Example  

  • sales
  • sales/west
  • sales/west/california

    The <subpath> components are sales, west, and california.

Matching logic

When the app makes a URL request, the AppConnect library within the app compares the URL request with the values of the MI_AC_CLIENT_CERT_#_RULE keys. If the rule matches the URL request, the connection uses the certificate.

A match occurs if all of the following are true:

  • the rule’s <host> matches the URL request’s <host>.

  • Any <subpath> in the rule matches the URL request’s <subpath>, in the same order.

    More <subpath> components can be in the URL request than are in the rule.

The matching logic ignores any port number or query parameters in the URL request.

Example  

Table 40.   Matching rule example: my.server.mycompany.com

URL Request

Match?

Comments

https://myserver.mycompany.com

Yes

Exact match

https://myserver.mycompany.com/sales

Yes

Matches <host>

https://myserver.mycompany.com:8080

Yes

Matches -- port is ignored

https://myserver.mycompany.com:sales?
range=quarter

Yes

Matches -- query parameters are ignored

https://anotherserver.mycompany.com

No

<host> does not match

http://anotherserver.mycompany.com

No

HTTP, not HTTPS
Table 41.   Matching rule example: *.mycompany.com/sales

URL Request

Match?

Comments

https://myserver.mycompany.com/sales

Yes

<host> and <subpath> match.

https://myserver.mycompany.com/sales/west

Yes

<host> and <subpath> match

https://anotherserver.mycompany.com/sales

Yes

<host> and <subpath> match

https://myserver.mycompany.com/salesmeeting

No

Entire <subpath> must match.

https://myserver.mycompany.com

No

Missing required <subpath>

https://myserver.mycompany.com/s

No

Entire <subpath> must match.

If more than one MI_AC_CLIENT_CERT_#_RULE value matches the URL request, the rule with the most number of non-wildcard characters is chosen.

For example, consider four MI_AC_CLIENT_CERT_#_RULE keys with the following values:

Table 42.   Example of similar MI_AC_CLIENT_CERT_#_RULE values

Key

Value

MI_AC_CLIENT_CERT_1_RULE

*.mycompany.com

MI_AC_CLIENT_CERT_2_RULE

*.mycompany.com/sales/west

MI_AC_CLIENT_CERT_3_RULE

myserver.mycompany.com/sales

MI_AC_CLIENT_CERT_4_RULE

myserver.mycompany.com/sales/west

If the app requests URL https://myserver.mycompany.com/sales/west, the request matches all the values, but only one match is chosen. The chosen match is myserver.mycompany.com/sales/west, and the connection uses the corresponding certificate in MI_AC_CLIENT_CERT_4.