This article discusses functionality that is included in the Aha! Knowledge Advanced plan. Please contact us if you would like a live demo or want to try using it in your account.
You can use Microsoft Active Directory Federation Services (ADFS) as an identity provider for users in your Aha! account based on SAML 2.0. You will need to be an in your Aha! account and an administrator in ADFS to configure SSO.
Click any of the following links to skip ahead:
In ADFS
In Server Manager, click Tools → AD FS Management.
Click Add Relying Party Trust under Actions. This will open the Add Relying Party Trust Wizard.
In the Welcome step, click Claims aware, then Start.
-
In the Select Data Source step, choose Import data about the relying party, then enter your Aha! account URL in the Federation metadata address field. The URL should be in the following format:
https://<accountname>.aha.io/auth/saml/metadata.The metadata URL will only work once SAML authentication is enabled in your Aha! account.
In the Specify Display Name step, name your relying party (e.g. "Aha!").
The Configure Certificate step is optional. Click Next.
The Configure URL step is optional. Click Next.
In the Configure Identifiers step, enter your Aha! account URL in the following format:
https://<accountname>.aha.io.In the Choose Access Control Policy step, choose to Permit everyone.
Review your settings on the Ready to Add Trust step, then click Next.
On the Finish step, click Close. This will open the Edit Claim Rules modal.
On the Issuance Transform Rules tab, click Add Rule....
Select the Send LDAP Attributes as Claims template.
-
Click Next. Name your rule, select Active Directory as the attribute store, and then add the following mappings:
LDAP Attribute
Outgoing Claim Type
NameID
NameID
Given-Name
Given Name
Surname
Surname
Each user in your Aha! account needs to have a unique
NameID. This value must be unique — an email addresses cannot be used as aNameID. This ensures that any changes to a user's email address can be reflected in your Aha! account. Click OK.
On the Issuance Transform Rules tab, click Add Rule... again.
Select the Transform an Incoming Claim template, then click Next.
-
Name the rule and make the following selections:
Incoming claim type: NameID
Outgoing claim type: NameID
Outgoing name ID format: Unspecified
E-Mail Address: E-Mail Address
Pass through all claim values
Click OK.
In your Aha! account
Log into your Aha! account and go to Settings ⚙️ → Account → Security and single sign-on → Single sign-on.
Select SAML 2.0 as your Identity provider.
Name your configuration.
For the Metadata URL, enter the URL to the metadata xml listed in AD FS 2.0 console, e.g.
https://adfs.<company>.com/FederationMetadata/2007-06/FederationMetadata.xml.Enter the remaining fields following the SAML 2.0 configuration instructions.
User attributes
The SAML identity provider must be configured to provide four attributes:
EmailAddress
FirstName
LastName
NameID
The NameID attribute must be included in the subject. Your Aha! account uses it to uniquely identify the user (separately from their email address). We recommend using a persistent, unique identifier in this field, rather than the user's email address. You must use a unique identifier so that Aha! can maintain a mapping between the user record in Aha! and within your identity provider. This ensures that any changes to the email address within the identity provider will be transparently reflected in your Aha! account.
Each user in your Aha! account needs to have a unique NameID. This value must be unique — an email addresses CANNOT be used as a NameID , or else your single sign-on configuration will error.
Your Aha! account will use these attributes to properly identify the user and automatically provision users. You can also configure your provider to include two additional optional attributes:
ProductRole
ProductPrefix
By default, users are provisioned with no access or any assigned role. Therefore, an administrator in your Aha! account will need to set the roles for all users. The exception to this is when the administrator is setting up custom attributes to provision specific users to specific roles and/or permissions, such as when using ProductPrefix and ProductRole.
EmailAddress
Every user in your Aha! account is required to have a valid email address, even when using SSO. Since the identity provider is responsible for managing user information, it must send the user's email address to your Aha! account in its assertion. Identity providers use different naming conventions, so your Aha! account will look for an email address in the following attributes sequentially:
EmailAddress
email
Email
mail
emailAddress
User.email
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
-
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
This attribute is supported for older versions of Azure. It is not recommended.
FirstName
Just like email addresses, identity providers may send the first name in several common fields. To provide out-of-the-box compatibility with most identity providers, your Aha! account will try to find the first name in the following attributes:
FirstName
first_name
firstname
firstName
User.FirstName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
LastName
Just like email addresses, identity providers may send the last name in several common fields. To provide out-of-the-box compatibility with most identity providers, your Aha! account will try to find the last name in the following attributes:
LastName
last_name
lastname
lastName
User.LastName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
NameID
Each user in your Aha! account needs to have a unique NameID. This value must be unique — an email addresses cannot be used as a NameID. This ensures that any changes to a user's email address can be reflected in your Aha! account.
Troubleshooting
We have created an article to help you troubleshoot common SSO configuration issues, complete with explanations and resolutions.
The best place to start in most of these situations is the Recent SSO events for your SSO configuration, at the bottom of the configuration page. Those messages will help diagnose and solve the problem.
If you get stuck, please reach out to our Customer Success team. Our team is made up entirely of product experts and responds fast.