Acquia will work with the third-party Identity Provider (IDP) to reinforce your organization policies. Also, it will bring an authentication login layer to protect your request and maintain your organization’s security. Single sign-on (SSO) is the ability of Acquia to forward authentication or login requests to a third-party IDP.
The Security Assertion Markup Language (SAML) integration is your standard pattern that supports many IDPs, which includes Okta, AWS, Google Cloud, and Azure. It provides:
- Authorization: It is the process of giving the user permission to access a specific resource or function with IDPs.
- Authentication: It is the act of validating that users are who they claim to be in CDP. The CDP Support team is responsible for maintaining and managing user’s authentication roles and permissions across modules such as Campaigns, Analytics, Integrations, Data Erasure, and Interactive Query.
Your IT team is responsible for maintaining and managing user’s authorization like password and network access to CDP through your administrative selected IDP.
Important
Your standard SSO is a single domain authentication credential that is specific to your organization. For example, @companyX.com. As a result, any of your partner or vendor authorization to CDP will be revoked after the standard SSO is enabled. To avoid such a scenario, you must configure a Federated Identity Management (FIM) for each of your partner or vendor to allow their organization domain (@partnerX.com) to stay authorized with Acquia. For more information about FIM, see Federated Identity Management. Ensure that you have completely analyzed this scenario before implementing SSO with Acquia.
Requirements
The following are the requirements for SSO:
- Request for SSO integration.
- Acquia support will provide the following details:
- TenantId
- Assertion Consumer Service (ACS)
- Service Provider (SP) EntityId
- Ensure that you have access to the CDP’s staging environment. If not, you must contact Acquia Support and request access.
- Provide the IDP metadata.xml file for the staging and production environments.
- Acquia Support will work with you to deploy SSO first in the staging environment and then in the production environment.
If your organization uses multiple tenants, then you must provide a metadata. xml file for each staging and production environments.
Acquia recommends you to always enable SSO first in the staging environment and then in the production environment.
Setting up single sign-on
To set up your single sign-on:
- Configure the Service Provider metadata in your preferred IDP. To get Service Provider metadata, contact Acquia Support.
- Configure Acquia metadata in the staging and production environments:
SAML Assertion Consumer Service (ACS). For example:
https://cs-auth.agilone.com/sso/tenantId/vega/samlService Provider EntityId. For example:
https://cs-vega-green.agilone.com/tenantId- NameId-format = urn:oasis:names:tc:SAML:1. 1:nameid-format:emailAddress.
- Application username = Email
- Assertion encryption = Unencrypted
- Signed response = true
- Signing option = Sign SAML response
- Signing algorithm = SHA 256
Share the generated IDP metadata.xml with the Acquia Support team, ensuring that the file includes the following:
- EntityId
- Login url
- x509 certificate
For troubleshooting information related to the x509 certificate, see FAQs and Troubleshooting.
- Acquia Support will configure your IDPs parameters in CDP’s security service.
- After Acquia Support performs configuration in the staging and production environments, Acquia Support will assist you in executing the test scenarios.
- After the test scenarios are successful, Acquia Support will coordinate with you to decide the official date and time when you want Acquia to deploy SSO in your production environment.
Testing single sign-on
CDP will prompt you to provide names and emails of three testers. The testers will test both positive and negative access. The following are the scenarios:
| User | Has Acquia CDP account | Has IDP permission on your end | Expected successful outcome |
|---|---|---|---|
| User A | Yes | No | User cannot access CDP |
| User B | Yes | Yes | User can access CDP |
| User C | No | Yes | User cannot access CDP |
Each tester will test one scenario. Acquia will set the appropriate access in the staging environment and will ask you to set the testers up in your IDP.
Important points
- New User creation: You can create a new user in the IDP or through Acquia by creating a Support ticket. Acquia Support team will provision the CDP user accounts with specific levels of accessor roles.
- User Login: Users will use their SSO username and password after the SSO is activated on a CDP production tenant. You do not need to use your old password.
- Password policies: Password policies will no longer be managed by Acquia. Your IDP settings will have full control to set the password requirements. There is no character limit for the password. You can enter as many characters as you want. You can define your character limit as per your organization policy.
- Forgotten Password or Lockouts: You will not encounter it with SSO unless a user forgets their SSO password. If you encounter password issues, you can contact your IT team or IDP administrator as they will log in through your IDP.
- IQ Access (if applicable): If you have Acquia Interactive Queries access, follow the normal login procedure.
- Service Provider Metadata: The generated IDP metadata.xml that contains IDP keys, services authentication, URLs defining SAML endpoints, and SPEntityID of CDP.
- Service Provider EntityID: Acquia’s unique URL that contains the environment and the application ID for an SSO.
- Federated Identity Management: A management identity within your IDP that establishes a trusted connection between separate organizations and domains. It allows vendors and partners to share user identities and authentication across various domains to different applications. For example, a partner or vendor will have authentication access to your third-party application such as Acquia, Salesforce, Zoom, and Workday.