You are currently reviewing an older revision of this page.

KB-1153 SAML Authentication FAQ

The purpose of this article is to provide answers to some of the common questions related to SAML authentication in Appian.

Table of Contents:

What is the Service Provider Certificate and where can I find it?

Appian requires a .PEM file as a certificate and it will not be provided by the identity provider (IdP). The certificates from an SSL enabled web server can be used, else self-signed certificates will also work if allowed by the identity provider. If a .PEM file cannot be found in the certificates then the .CRT and .KEY files can be combined to be create this.

See KB-1108 for more information.

Appian is the service provider. Why do customers provide the service provider certificate?

In the context of the cloud-based SAAS, Appian (the company) is the service provider. However, in the context of SAML authentication, Appian (their instance of the software environment) is the service provider. Therefore, since it is up to the customer to configure their environment correctly for their needs, they need to supply their own certificate so that the SAML service provider (their environment) can work correctly. Additionally, this allows the customer control over the certificate to ensure that it meets the requirements of their identity provider and security policy (e.g., number of bits).

My identity provider does not have a field to upload a service provider metadata file. How do I configure SAML?

On the IdP side, if the option to upload a metadata file is not available, open the .XML file generated by Appian and configure SAML using the following:

  1. EntityID: Copy the value of the "entityID" parameter inside the "md:EntityDescriptor" tag.<md:EntityDescriptor entityID="mysite.example.com" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"/>
  2. Assertion Consumer URL: Copy the value of the "Location" parameter inside the "md:AssertionConsumerService" tag. <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mysite.example.com/suite/saml/AssertionConsumer" index="0"/>
  3. Logout URL: Copy the value of the "Location" parameter inside any "md:SingleLogoutService" tag.<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mysite.example.com/suite/saml/LogoutConsumer"/>

Why does a process model published as web service fail after configuring SAML?

Appian requires web service users to use Appian authentication, and web services will fail if these users get authenticated by SAML. To avoid the error, restrict SAML authentication to a specific group and make sure the web service users do not belong to this group. Now, these users will be authenticated by Appian and web services should work correctly. For more details about this, please read the documentation about Publishing Process Models as Web Services

I see "Authentication was successful" in the SAML test window, but admin console says "Login failed...". Why is this?

This means that the identity provider did not provide a response as expected by Appian, but users will be able to log in. The behavior has been fixed in Appian 16.1 and above. In older versions, to enable SAML without testing, configure a SAML users group and use the same settings without being a part of that SAML users group.

What is the purpose of the checkbox called "Use Identity Provider's login page"?

When the option is checked, users navigating to the Appian environment will be redirected to the IdP login page by default. This is SP-initiated SAML authentication. If this configuration is used, users that do not get authenticated via SAML can login using Appian authentication at the URL https://mysite.example.com/suite/portal/login.jspIf "Use Identity Provider's login page" is unchecked, all users will be directed to the Appian login page by default. Users that authenticate with SAML will need to use use one of the following approaches:

  1. IdP-initiated SAML authentication
  2. Appending ?signin=[identifier] to the site URL, where identifier is the value specified in the "Web Address Identifier" parameter.

If using IdP-initiated SAML authentication, users will first need an active session with the IdP before navigating to Appian. For example, some IdPs will have the option to configure an Appian link from an internal portal/intranet page. Note that IdP-initiated SAML is not currently supported from embedded environments or mobile.

Why does accessing a servlet plug-in or web API fail, even when using credentials of a user who isn't in the SAML users group?

The plugin or service that is attempting to access the Appian resource needs to use preemptive basic auth. If you don't authenticate preemptively, you will be challenged to authenticate via SAML and the authentication will fail.

What should we set the "common name" to be when generating a certificate?

Common name can be anything that is desired and/or that one has the ability to generate; there is no restriction on common name from the Appian side

What is the private key used for when generating the certificate?

Private key will only be used for signing SAML assertions; it will NOT be used for SSL encryption via HTTPS communications. Both SP and IdP each have a private key used to sign SAML assertions. The public key of each certificate is passed via the exchanged metadata files so that the SP and IdP can verify the authenticity of the assertions.

Can the certificate be signed by any trusted Certificate Authority (CA), like our internal Microsoft CA, or does it need to be a mutually-trusted cert, like Symantec or other CA?

There is no requirement for a CA signed certificate, so you are free to use a self-signed certificates if you desire. You can follow KB-1108 to generate self-signed certs. For a production environment, however, Appian Technical Support recommends a CA signed certificate.

Does Appian support encrypted SAML assertions?

As of 18.1, Appian supports signed, encrypted SAML assertions up to the AES-256 standard. In order to make use of this capability, the environment must be running on an Appian Cloud instance. Otherwise, on-premise environments will need to be running OpenJDK 8 or have the JCE security JAR installed for the Oracle Java JDK. Once the JCE security JAR is installed, perform the following steps in the Appian on-premise environment:

  1. Restart Appian, so that it picks up the newly installed JCE security JAR.
  2. Regenerate the service provider metadata file in the Admin Console.
  3. Provide this metadata file to your identity provider.

What is the dropdown called "Authentication Method"?

This is the SP preferred authentication mechanism/method. It sets the RequestAuthnContext in the AuthnRequest. With the default method selection, the RequestAuthnContext tag sets the Comparison to "minimum", which the IdP can choose to acknowledge or ignore. If selection from drop-down is None, the AuthnRequest will not contain a RequestedAuthnContext tag. Depending on the IdP implementation, some IdPs may choose to ignore the preferred authentication mechanism

Affected Versions

This article applies to Appian 7.11 and later.

Last Reviewed: June 2018