Logo

Single Sign On - SAML 2.0

Become a Client

Active Directory Federation Services Setup

If you are using Microsoft ADFS (Active Directory Federation Services) as your Identity Provider, this section will guide you through the configuration specific to ADFS. (If you use a different IdP, you can skip this, though the general concepts of importing metadata and claim rules still apply in your context.)

Prerequisites: You should have ADFS installed and running, and you should have Administrator access to the ADFS Management console. Also, ensure you have obtained the IDC SAML metadata file or URL for the environment you are configuring (test or production).

Configuring ADFS

1. Add Relying Party Trust: In ADFS Management, go to Trust Relationships > Relying Party Trusts and select Add Relying Party Trust… (usually under Actions menu).

  • Choose the option “Import data about the relying party from a file” and browse to the IDC metadata file (which you downloaded from …/saml-metadata/CompanyCode). Alternatively, you could use the metadata URL directly if ADFS allows URL import (depending on version).
  • ADFS will read IDC’s metadata, which includes the relying party identifiers and endpoints.
  • Give it a display name, e.g., “IDC CAS – SAML” for identification.
  • For user access, you can choose Permit all users to access this relying party (unless you want to restrict which AD groups can use IDC – but typically, if they have an IDC account, they should be allowed).
  • Finish the wizard. Do not configure any claim rules yet if prompted; we’ll do that next (uncheck the “Open the Edit Claim Rules dialog” if it appears).

2. Adjust Relying Party Settings (if needed): After creation, you might want to double-check settings:

  • In the ADFS trust properties for IDC, on the Endpoints tab, ensure the ACS (Assertion Consumer Service) URL is present (from metadata) and binding is POST.
  • On the Encryption (or Certificate) tab, IDC’s encryption certificate might have been imported via metadata. IDC might not encrypt assertions (if they use SSL anyway), but if metadata included a certificate, ADFS will use it to secure the SAML response.
  • On the Advanced tab, you might see the secure hash algorithm. SHA-256 is default in new ADFS, which should be fine as long as IDC supports it (they should). If IDC had any requirement for SHA-1, they’d mention it, but likely SHA-256 is fine.

3. Claim Rules – Send LDAP Attributes: Now set up the output claims to send the required user attributes:

  • In the IDC relying party trust, click Edit Claim Issuance Policy….
  • Add a new rule, choosing the template “Send LDAP Attributes as Claims.”
  • Name it something like “Send AD Attributes”.
  • Data Source: Active Directory (if that’s your attribute store).
  • In the mapping table, select the following:
    • LDAP Attribute: E-Mail-Addresses → Outgoing Claim Type: E-Mail Address (this will produce the claim emailaddress).
    • LDAP Attribute: Given-Name → Outgoing Claim Type: Given Name
    • LDAP Attribute: Surname → Outgoing Claim Type: Surname
    • (Optionally, LDAP: Display-Name or CN → Outgoing: Common Name if you want to send CommonName.)

      Ensure the claim types match exactly the ones IDC expects. In ADFS’s UI, “E-Mail Address” corresponds to the URI …/claims/emailaddress, etc.

  • Add the rule and finish.

4. Claim Rules – Transform NameID: Next, create a rule to set the NameID. If you are using the user’s email as NameID, you can transform the incoming email claim to NameID. If you want a persistent unique ID that’s not email, you might transform a different attribute or generate one.

  • Add another rule, choose “Transform an Incoming Claim.”
  • Call it “Transform Email to NameID” (if using email).
  • Incoming claim type: E-Mail Address. (This refers to the claim we issued in the previous rule.)
  • Outgoing claim type: Name ID.
  • Outgoing Name ID Format: choose Email if using email (or Persistent if you have a stable persistent ID to send).
  • Pass through or transform: select Pass through the incoming claim value (assuming you want the NameID value to be the email itself).
  • If you were to use a different ID, you might instead choose an LDAP attribute like ObjectGUID and send that as NameID in Persistent format – that requires converting the GUID to a string. For simplicity, many just use email.
  • Save the rule.

Now you have two rules: one sends the attributes, one sets NameID. The order of rules can matter in some cases, but here it should be fine.

5. Test: With the trust and rules in place, your ADFS is ready to issue SAML to IDC. Use the test procedure (next section) to try a login. Monitor ADFS’s logs (Event Viewer under AD FS > Admin logs) if something fails – it will often log claim issuance events or any errors.

Note: If you have multiple environments, you might replicate this setup for IDC’s test and production separately. Possibly one trust for saml.idc.com (test) and one for www.idc.com (prod), each with their own metadata and rules.

Troubleshooting ADFS integration

  • If you get an IDC error after a login attempt saying attributes missing, check that your claim rules are firing. You can enable ADFS auditing to see the outgoing claims.
  • If IDC simply redirects back to login or shows a generic SSO error, it could either be a NameID or a certificate issue.
    Ensure IDC has the correct IdP metadata (if your ADFS federation metadata changed or you have multiple certificates, they need the right one).
  • If using IdP-initiated from ADFS (clicking “Log in to IDC” via IdP portal), you might need to set a RelayState to direct to a specific page. IDC mentioned that for ADFS IdP-initiated, additional config (like enabling an Identity Provider-initiated SSO support) may be needed. ADFS by default doesn’t easily support IdP-initiated with RelayState, but there are workarounds (like using the RelayState to carry the destination).