Customizing certificates for single sign-on in Access
Certificate single sign-on lets you login to cloud services from managed apps on their devices without passwords. You can customize the certificates for single sign-on by selecting SAML Assertions with your SP. The SP requires additional information other than the email address in SAML Assertion's Subject field.
If you are authenticating an original Identity Provider, the SAML message that Access obtains from the original IdP is relayed to the SP with minimal modifications. However, when the user is being authenticated using the Cert SSO, Access must construct the SAML message, and put the appropriate user identifying values from the certificate into the SAML assertion in that message. To provide flexibility in choosing and transforming values from the certificate and putting them in the SAML, MobileIron Access provides a flexible customization capability. Currently, this capability is offered only when you choose the Custom SP.
| • | Configuring SAML assertion fields |
| • | Language to generate values from certificate fields |
Configuring SAML assertion fields
The MobileIron Access UI enabled you to choose the Certificate SAN rfc822Name and NTPrincipalName type values and add them into the SAML Subject or in SAML attributes. However, this might not be sufficient for all issues. For advanced configuration, select Custom and enter the values.
For more information, see Configuring Mobile App Single Sign-on (SSO).
Language to generate values from certificate fields
The values for either the subject or the attributes can be defined using MobileIron Transform expressions or MiTra expressions. The MiTra expressions are a comma-separated list of double-quoted strings. Each String in this list is called a specification. Each specification has a verb, a format and a format-specific pattern. The verb, format, and pattern are all separated by the ":" character. Evaluation of MiTra expressions is left-to-right, with the output of the preceding expression on the left is used as the input to the expression on the right. The first specification must be either a X509 format expression or a Literal format expression, so that values are either derived from the Tunnel certificate or a constant string.
The grammar for MiTra expressions is as follows:
specs = ( X509spec / LiteralSpec ) [ *( ", " spec ) ]
X509spec = "select:X509:" pattern
LiteralSpec = "select:Literal:" pattern
spec = ( "select" / "encode" / "decode" ) ":" ( "HTTP" / "HTML" / "URL" / "Base64" / "CompressedBase64" / "Deflate" / "XML" / "Hex" / "X509" / "RFC2253" / "Literal" ) [ ":" pattern ]
The verb is a general description of the operation to be performed. The encode and decode verbs do not take any arguments. The select verb takes the pattern argument. The pattern specifies the selector within the format. For example, in X509, the pattern can be Subject or SubjectAltName:rfc822Name.
An example of a multi-expression specification is as follows:
select:X509:SubjectAltName:ntPrincipalName,decode:Hex,encode:Base64
The above expression sequence is used in constructing a SAML Subject for Office 365 from a cert that contains an ObjectGUID from an Active Directory. The following formats are supported by MiTra expressions:
|
Format |
Description |
Operations Supported |
Notes |
|
X509 |
X.509 Certificates |
select |
|
|
Literal |
Constants |
select |
Selection pattern is output verbatim. |
|
RFC2253 |
LDAP name simple text representation |
select |
|
|
URL |
URL-encoded data |
select, encode, decode |
Selection pattern is parameter name. |
|
Hex |
Hex-encoded data |
encode, decode |
|
|
HTML |
HTML format string |
select |
Selection pattern is in CSS syntax. |
|
HTTP |
HTTP request stream |
select |
Selection pattern is either header name or Content to select the content. |
|
Base64 |
Base64 encoded data |
encode, decode |
|
|
CompressedBase64 |
Deflate encoded Base64 |
encode, decode |
|
|
Deflate |
Deflate encoded data |
encode, decode |
|
|
XML |
XML-encoded data |
select, decode |
Selection pattern is XPath spec. Decode results in pretty-printed XML. |
Selection pattern description
The selection pattern that appears in a MiTra expression after the second ":", is dependent on the format on which that expression applies. The following is the syntax of the pattern for each format:
| • | X509 Pattern Syntax |
X509pattern = ( "Subject" / sanPattern )
sanPattern = "SubjectAltName:" sub-type [ ":" occurence ]
sub-type = ( "otherName"/ "ntPrincipalName" / "rfc822Name" / "dnsName" / "x400Address" / "directoryName" / "ediPartyName" / "uniformResourceIdentifier" / "ipAddress" / "registeredId" )
occurence = *DIGIT ; ordinal number starting with 1 for the first occurrence.
To select the second SAN extension of type rfc822Name, you must specify the following string:
select:X509:SubjectAltName:rfc822Name:2
| • | Literal |
The pattern is any string that is selected in its entirety.
| • | RFC 2253 |
RFC2253 is the string representation of LDAP names. A certificate's subject or subjectAltName:directoryName might result in a value of type RFC2253 name. To choose a specific value from an RFC2253 name, the pattern specifies the DN component name and optionally its occurrence from the right. For example, a MiTra expression of the form
select:RFC2253:DC:2
from the string
"CN=testuser2521, OU=contacts, DC=mobileiron, DC=com"
results in getting the value mobileiron.