Your organization can now use federated Single Sign-On (SSO) with their existing identity provider (IdP) for authenticating and accessing Acoustic applications and cloud services. When your users log in, they are directed to your organization's login page; taking advantage of all your existing identity security controls. That's one less user ID and password for your users to remember.

Our new capability uses Security Assertion Markup Language 2.0 (SAML 2.0) and OpenID Connect. To use this capability, you need to federate your organization's IdP with the Acoustic ID. In this article, learn more about federation, and remember, we're here to guide you along the way.

Benefits

With federated SSO combined with your identity security controls, you can:

• define account lockout procedures and the number of times a user can try to log in
• use Multi-factor authentication
• centralize identity logging
• perform access reviews

Supported identify providers

The following active directories are supported:

• Azure AD
• Facebook
• Google
• LinkedIn
• Microsoft
• Okta
• Other OpenID Connect IdPs
• SAML 2.0

 IdP requirements

Your organization must have an identity provider to federate your organization’s IdP with your Acoustic ID. Review these requirements before setting up federation.

• The organizational IdP must support SAML 2.0 or a supported identity provider and be able to support signed SAML assertions.
• While identity provider-initiated flows are allowed and supported, service provider initiated flows are highly preferred for the most optimal user experience. Your Acoustic login/username will be the same as your email address.
• The SAML "Nameid" returned by the organization’s identity provider must be set to equal the valid email address for the organizational user’s email address and format:emailAddress.
• The following SAML attributes must be provided in the SAML assertion, with these exact attribute names: firstName, lastName, country, and emailAddress. These attributes must have NameFormat. These required SAML attributes will be mapped to OpenID Connect standard claim per OIDC specification:
  • email (required): Maxlength 100. Validated as an email format.
  • firstName (required): Maxlength 50.
  • lastName (required): Maxlength 50.
• Optional SAML attributes include:
  • login
  • middleName
  • honorificPrefix
  • honorificSuffix
  • title
  • displayName
  • nickName
  • profileUrl
  • secondEmail
  • mobilePhone
  • primaryPhone
  • streetAddress
  • city
  • state
  • zipCode
  • countryCode
  • postalAddress
  • preferredLanguage
  • locale
  • timezone
  • userType
  • employeeNumber
  • costCenter
  • organization
  • division
  • department
  • managerId
  • manager
• The organizational identity provider must provide a metadata file that includes both signing and encryption certificates. If the encryption certificate is missing, we need to manually duplicate it from the signing cert even if encryption is not going to be performed, and a copy of the signing certificate can be used for that purpose.
• If metadata XML cannot be generated, then these elements are required to configure IdP:
  • IdP Issuer URI: The issuer URI of the identity provider. This value is usually the SAML Metadata entityID of the Identity Provider Entity Descriptor.
  • IdP Single Sign-On URL: The binding specific Identify Provider Authentication Request Protocol endpoint that receives SAML AuthN Request messages from Acoustic.
  • IdP Signature Certification: The PEM or DER encoded public key certificate of the identify provider used to verify SAML message and assertion signatures.
• Acoustic prefers to leverage SHA-256 as signature algorithm for request and response.
• Any other attributes provided by the organization in the SAML assertion will be sent through to the end Acoustic service being used by the user but will not be persisted in the Acoustic ID system in any way. 
• The attributes "uid" and "groupid" will be ignored and removed from SAML assertion. Make sure your IdP does not use them. These attributes are not case sensitive.
• CRL (Certificate Revocation List). In case your signing certificate supports CRL, the URL must be public so that the Acoustic server can reach it.
• CA issue certificates are required to have CRL (Certificate Revocation List). 
• Self-Signed certificate will be accepted.
• Add a new signing CA issued certificate before your current one expires. 

MFA with supported IdPs

Although Multi-factor authentication (MFA) is not required for apps today, we recommend that you use MFA when using federation. Check your organization’s MFA requirements.

• When federation is not applied, MFA is globally turned on by default for any product or service that uses an Acoustic ID.
• When federation is applied, it is up to your organization’s security policy to determine the best MFA to use.

The following IdPs are supported:

• Microsoft ADFS (Active Directory Federation Services)
• Azure AD for IdP

If you are using a different IdP, you will need to configure MFA on your IdP.

MFA with supported IdPs

Find a list of requirements to support the MFA option:

• A specific Microsoft ADFS (MFA) application needs to be created in Okta.
• The “Okta MFA provider for ADFS” needs to be installed on the ADFS instance.
• The SSL certificate of the AD needs to be added to the “Trusted Root Certification Authorities.” Self-signed certificates are supported.
• An Okta MFA provider needs to be enabled as an authentication method.
• Access Control Policy needs to be created for the MFA Provider and added to a Relying Party Application. You can find instructions in the Okta Help Center.

Considerations

Session timeout support

Federated users are not automatically re-authenticated to Acoustic ID via a failover cookie. The default security token timeout is 2 hours. Many federating companies have requested session timeout to force a more frequent authentication. After the Acoustic application or Acoustic ID session times out, the user is redirected back to your IdP for re-authentication. It's up to your IdP's session lifetime settings to determine if the user must authenticate again or not. 

Remember Me

The Remember Me function stores the user's Acoustic ID for future sessions. Note: Passwords are not stored.

Set up federation

The Acoustic ID federation team is here for you to help you onboard. 

1. To get started, gather a list of email domains for users that you plan to federate. Send the list to the Acoustic team.
2. The Acoustic team will determine which users already have an Acoustic ID and then provide that list to you.
3. Review the list to determine how each existing ID should be handled. Acoustic can do one of the following actions based on your direction:
   • Convert existing IDs: For valid organizational employees, Acoustic can change the existing ID to require a federated authentication when signing.
   • Delete the Acoustic ID: For users that are no longer valid organizational employees, Acoustic can delete the pre-existing Acoustic IDs for extra security. 
   • Leave the Acoustic ID as-is: We can also keep the original Acoustic ID as an unfederated Acoustic ID. For example, you might want a few organizational admins to have access to an Acoustic ID service in a non-federated environment for testing and verifying federation.
   • Update the Acoustic ID: If any of the attributes of the pre-existing Acoustic ID needs to change, such as email address, name, or country information, to align better with your organization, then Acoustic can update these IDs during onboarding. 
4. Provide the Acoustic team with the SAML metadata for your identity provider.
   • Email us a file in an XML format of your SAML metadata.
   • Or, send us a URL for us to download the SAML metadata.
5. The Acoustic team will send our Acoustic ID service provider SAML metadata to you. The Acoustic ID service will use the certificate information to validate that the SAML assertions that were issued by the trusted IdP SAML metadata.

Note: To federate successfully, use email, firstName, and lastName attributes exactly as shown in the returned XML file, with no changes to spacing, capitalization, or namespacing.

Updates and maintenance

After the initial setup and onboarding, there are several common changes and updates that might be needed for an organization's federation setup.

Updating SAML partnership details

If anything changes on the organization's identity provider side that may require an update to the SAML partnership, for example, if the signing certificate used by the organization’s identity provider changes, then the organizational admins will need to provide Acoustic with an updated SAML metadata file.

Similarly, if anything changes with the Acoustic ID side (like a service provider) of the SAML partnership, then Acoustic will provide the organizational admins with a new SAML metadata file for Acoustic ID.

Updating federated users

As of the initial release of this enterprise federation capability, Acoustic ID core identity attributes (name, email, organization name, & country) are only synchronized with the organization at the time of onboarding and/or ID creation. Existing Acoustic ID users in the organization’s domain can have their Acoustic ID information updated as part of onboarding, and new Acoustic ID users in the organization are automatically created (for just-in-time provisioning) based on the information provided by the organization in the SAML assertion.

If any of the core user identity information (name, email, organization name, & country) changes after initial onboarding or new user auto-provisioning, then the Acoustic ID team must be contacted to request bulk updates to core identity user data. Acoustic will dynamically update the federated user's Acoustic ID information each time the user authenticates, by looking for changes to this information in the user's SAML metadata.

Note: Some Acoustic applications may use the user email address for authorization and access control. Recycling users may end up with existing authorization and access from these applications.

Remove federation from Acoustic ID

If an organization wishes to remove its federation relationship with Acoustic ID, they should contact Support. The organization will have the choice of removing all Acoustic IDs associated with their organization or converting all of these Acoustic IDs to non-federated Acoustic ID users.

Note: When converting users to non-federated users, all organizational users would be required to go through a forgot password flow on their first-time use after federation is removed to generate a local Acoustic ID password/security credential.

Get support

Our team is here to help:

• when you're ready to set up federation
• if you have questions later after setup