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.

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.

Set up certificate authentication from an AppConnect app

Setting up certificate authentication from an AppConnect app requires the following two main steps:

  1. Configure Ivanti Neurons for MDM with the certificate that the app will use to authenticate to the enterprise service.

    See Configuring a certificate on Ivanti Neurons for MDM.

  2. Add two sets of key-value pairs to the AppConnect Custom Configuration.

    See Configuring a certificate on Ivanti Neurons for MDM.

Configuring a certificate on Ivanti Neurons for MDM

Configure the certificate that the app will use to authenticate to the enterprise service on Ivanti Neurons for MDM.

Procedure 

  1. Add a certificate authority in Admin > Certificate Management > Certificate Authority.

    A Connector installation is required if you are using an external certificate authority.

  2. Create an Identity Certificate setting, in Configurations > Add > Identity Certificate.

    For Certificate Distribution, select Dynamically Generated and for Source, select the certificate you configured in Admin > Certificate Management > Certificate Authority. You will reference the Identity Certificate configuration in the key-value pair in the app’s Custom AppConnect configuration.

Related topics 

  • "Certificate Management" in the Ivanti Neurons for MDM Administrator Guide.
  • "Identity Certificate" in the Ivanti Neurons for MDM Administrator Guide.

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

To set up certificate authentication from an AppConnect app to an enterprise service, you need to set up keys and certificates for all AppConnect apps to use for client-side certificate authorization. This is done in the AppConnect Custom Configuration section of the app.

The two key-value pairs in each set specify:

  • a certificate
  • a URL matching rule

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

Procedure 

  1. In Ivanti Neurons for MDM, App Catalog, edit the setting for the AppConnect app.

  2. Go to App Configurations > AppConnect Custom Configuration.

  3. Edit an existing custom configuration or +Add a new AppConnect Custom Configuration.

  4. Enter the key-value pairs, as described below.

    Key

    Value

    MI_AC_CLIENT_CERT_#_RULE

    Substitute the same digits for # that you used in MI_AC_CLIENT_CERT_#. See Details about MI_AC_CLIENT_CERT_#_RULE.

    The key is case-sensitive.

    Example  

    MI_AC_CLIENT_CERT_15_RULE

    Enter the URL that will use the certificate for authentication.

    Example  

    *.mycompany.com/sales

    myserver.mycompany.com/hr/benefits

  5. In the AppConnect Certificate Configuration section, +Add key-value pairs.

    Key

    Value

    MI_AC_CLIENT_CERT_#

    Substitute digits of your choice for #

    Make sure the number matches the number used in the RULE.

    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.

    Select the Certificate Enrollment setting from the drop-down list.
  6. Click Save.

Related topics 

Details about MI_AC_CLIENT_CERT_#_RULE

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 20.   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 21.   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 22.   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.