Interoperability issues between Avaya Aura Device Services and the third-party identity provider

Last Updated : Jun 10, 2026 |

Condition

Avaya Aura® Device Services cannot communicate with the third-party identity provider. Avaya Workplace Client cannot use SSO capabilities.

Solution

To communicate with a third-party SAML v2.0 identity provider, Avaya Aura® Device Services must negotiate certain SAML v2.0 parameters with the identity provider. To prevent issues, upload the identity provider’s IDPSSODescriptor metadata file to Avaya Aura® Device Services when you enable OAuth2 authentication support on Avaya Aura® Device Services. The IDPSSODescriptor file automatically populates many identity provider settings on Avaya Aura® Device Services.

After you configure the identity provider on Keycloak, it generates the SPSSODescriptor metadata file. You can provide this file to the identity provider. You can find this file at the following location:

https://<AADS FQDN>/auth/realms/SolutionRealm/broker/<SAML ALIAS>/endpoint/descriptor. In this URL, <AADS FQDN> is the Avaya Aura® Device Services front-end FQDN, and <SAML ALIAS> is the alias of the identity provider.

You can prevent many issues by exchanging the IDPSSODescriptor and SPSSODescriptor files. However, if the metadata files contain information that is incorrect or not supported by Avaya Aura® Device Services, interoperability issues might still occur.

If you continue to experience problems, verify the following settings on the third-party identity provider and Avaya Aura® Device Services Keycloak.

Procedure

  • The identity provider that you use must support the Service Provider-initiated (SP-initiated) SAML v2.0 flow.
  • The NameID format option must be set to emailAddress.
  • The identity provider must support the HTTP POST binding.
  • The identity provider and Avaya Aura® Device Services must use the same time synchronization service.
  • Ensure that no network firewalls must block access from Avaya Aura® Device Services to the identity provider.
  • The certificates specified in the identity provider’s IDPSSODescription file must be valid.
  • For attribute mapping, Keycloak must use the same spelling for attribute names as the identity provider. These attribute names are case-sensitive.
  • The attribute names that the identity provider releases must be correctly mapped as friendly names or attribute names on Keycloak.

    By default, Keycloak maps the friendly name of the attribute.

  • Role information must be correctly released to Avaya Aura® Device Services, so that the correct user role can be assigned to each user.