AuthHub SAML - ADFS - Migrating from Auth0 to AuthHub

search cancel

AuthHub SAML - ADFS - Migrating from Auth0 to AuthHub

book

Article ID: 379143

calendar_today

Updated On:

Products

CloudHealth

Issue/Introduction

When you make use of ADFS for Single Sign On, and have a previous relying party trust configured please take the following steps to migrate the connection.

If you require the Token to be encrypted please open a ticket with CloudHealth Support first as we will need to request a change be made to the connection on our side before you can proceed with the migration.

Resolution

Open the ADFS Management Console
Open the Relying Party Trust folder, and right click the Relying Party Trust setup for CloudHealth, and select properties.
Under the Monitoring tab, if the Monitor Relying Party is checked, uncheck the box to allow the configuration to be modified.
Switch to the Identifiers tab -

Update the Display Name field if required (display name for relying party trust), and remove the existing Relying Party Identifier -
Once removed add the following Identifier - https://access.broadcom.com/default in the Relying Party identifier field and select Add -
Navigate to the Endpoints tab – remove the existing endpoints
Select the Add SAML option, and add the following Endpoints -

- https://access.broadcom.com/default/saml/v1/sp/acs

- https://access.broadcom.com/default/saml/v1/sp/acs?sp=53359bda-9a9c-4264-a114-9a246544c372

Navigate to the Signature tab -

You will find the Certificate references CN=cloudhealthtech.auth0.com

Remove the Certificate as it will need to be updated to the Certificate for Authhub

AuthHub Cert -

Add the following Certificate by:

1. Copy the value above into notepad.
2. Save as AH.CER into a directory
3. Select Add -> and select the AH.CER file from the directory.

The Signature tab should now appear as -
Navigate to the Encryption tab. This will be filled with a Certificate by default if you imported the connection from the Auth0 Federation Metadata file.

This is optional however, if you do not require the SSO token/assertion to be encrypted remove the certificate and move to the next step.

If you do require the token to be encrypted replace the certificate with the AH.CER certificate from Step 9, there is a further step required by Engineering on the CloudHealth side to enable this however please submit a support ticket and do not publish the changes to the connection.
Confirm the changes and hit apply. Right click the Relying Party Trust and select Edit Claim Issuance Policy -

Ensure that the email claim is setup as the following by selecting the rule, and selecting edit rule

If the outgoing claim type is set to another value, overwrite it by typing email”

If you need to create this claim rule, select Add Rule -> Send LDAP Attributes as Claims, and specify a name and populate the values in the screenshot above.
Edit the Name claim, the following example uses “upn” as the source attribute -

No matter what attribute you’re using as the source, ensure that the Type under the => issue portion of the rule is set to name, and does not include a namespace -

See following examples of Display Name, and Windows Account Name below also -

Windows Account Name -

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(Type = "name", Value = c.Value);

Display name -

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("name"), query = ";displayName;{0}", param = c.Value);

UPN -

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "name", Value = c.Value);

If you need to add this in manually select Add Rule -> Send LDAP Attributes as Claims and then populate the rule syntax as above.
If you are making use of a claim rule to pass roles - ensure that the "Outgoing claim type" field is overwritten with roles as per the screenshot below - repeat this for all roles claim rules.
If you are making use of a claim rule to pass a value for user group mapping, ensure that similar to step 13 that the =>Issue Type is set to the key name, without a namespace.
Under AD FS Management -> select Certificates -> right click Token – Signing Certificate -> View Certificate.

In the window select the Details tab ->
Under the Certificate Export Wizard select Base-64 encoded X.509 (.CER) option -

Select Next
Set a Path for the Certificate -> and hit Next and then Finish on the next page.

Open the Certificate and capture the value, this will need to be set as the Signing Certificate in CloudHealth AuthHub SAML.
Open the Federation Metadata file for the ADFS server, typically available from https://<server host name>/FederationMetadata/2007-06/FederationMetadata.xml

Within the file locate the Entity ID, found under the EntityDescriptor element under Entity ID =

Typically in format – http://<domain name> /adfs/services/trust
Pull the Login Service URL – this will be located within the Federation Metadata document – typically in format https://<server domain name>/adfs/ls
Populate these values under Setup -> Admin -> Single Sign On -> AuthHub SAML
Validate the connection by attempting to sign in via an incognito browser.

Feedback

thumb_up Yes

thumb_down No