Troubleshooting SAML

Introduction

Once configuration has been completed, test functionality by following the steps described in Single Sign-On Settings .

Testing

1. Upon navigating to the URL in AppsAnywhere, you should be redirected to your identity provider and one of two things should happen:

   1. You are automatically redirected back to AppsAnywhere and logged into the system

   2. You are presented with the login page of your identity provider

2. If you are faced with the login page of your identity provider, log in as you would usually; you will then be redirected back to AppsAnywhere and hopefully logged into the system

Troubleshooting

A SAML trace tool can be used see what attributes are being passed by the user logging in.
Compare the attributes shown in the SAML tracer logs with the attribute being used in AppsAnywhere Single Sign on settings.
Some example tools can be found below (Edge / Chrome);

1. SAML Chrome Panel - Chrome Web Store (google.com)

2. SAML-tracer - Chrome Web Store (google.com)

• If the identity provider displays an error page after the initial redirect from AppsAnywhere:

  • Check the SAML logs to determine if there was an issue with the AuthnRequest

• If the identity provider displays an error page after you have successfully logged in:

  • Check the SAML logs to determine if there was an issue with the AuthnResponse

• If you are returned to AppsAnywhere but are not logged in (ending up back at the login page):

  • Ensure the appropriate LDAP connections have been assigned to the SSO method

    • If multiple have been set and an alias is used for the user's domain, then also ensure the returned assertion contains an attribute with the user's domain

  • Ensure the set Username Attribute Name is the name and not the friendly name

  • Match an example assertion with the configuration in AppsAnywhere, ensuring all fields are set as expected

    • Pay particular attention to the algorithms and X.509 certificate

  • If the Domain Attribute Name has been set, ensure it is the name and not the friendly name

  • When using a Federated Domain Alias, ensure this matches correctly

  • If multiple domains are in use, ensure the aliases are unique to each connection

  • Ensure the LDAP connection has any required additional domain name suffixes (e.g. if the users UPN is different from the domain name)

In the majority of the cases above, if you are not the administrator of the identity provider you will likely need to request the assistance of the person who is.