Action Required: TeamDynamix Single Sign-On Certificate Rollover (USA Only)

Target Audience

1. Are you a customer in TeamDynamix US SaaS Cloud?
   1. If yes, does your organization utilize Single Sign-On (versus TeamDynamix native authentication or traditional LDAP/Active Directory authentication)?
      1. If yes, is your Identity Provider configured to perform assertion encryption (sometimes called token encryption by Microsoft)?
         1.  Yes. This article applies to you. Please proceed with the steps outlined in this article.
            Please note that some historical Canadian clients are located in the original US region, so this article may apply to you. If a ping yourTeamDynamixDomainHere command in a command prompt/terminal resolves to vip-eus.teamdynamix.com or one of the US-based IP addresses in the TeamDynamix IP Addresses article in the Related Articles Section, this applies to you as well!
         2.  No (not using assertion/token encryption with Single Sign-On). Please still fill out the completion survey below. This is the only action required for your organization. Do not make any other changes in your Identity Provider!
      2.  No (do not utilize Single Sign-On). This article does not pertain to you. No action is required.
   2.  No (not a TeamDynamix US SaaS Cloud customer). This article does not pertain to you. No action is required.
2. Are you a customer in TeamDynamix Canada SaaS Cloud? 
    This article does not pertain to you. No action is required.

Overview

The certificate used by the USA TeamDynamix Shibboleth Service Provider for Single Sign-On (SSO) login interactions will expire on November 1st, 2022. While the SAML specification does not require certificate expiration to be checked because trust is handled through metadata or out-of-band, some software products check it anyway, requiring an update to maintain maximum compatibility.

To best protect user privacy, TeamDynamix has generated a new keypair and issued a replacement certificate that will be valid for another 20 years. Both keys will be considered acceptable for encrypted messages until the beginning of November, but the old certificate will still be used in rare instances where TeamDynamix signs messages.

Steps to Take

If you dynamically pull Service Provider (SP) metadata from TeamDynamix, either directly or through a federation, you likely do not need to take further action. TeamDynamix is part of InCommon, and metadata is exported to eduGAIN for international customers. Verify that the TeamDynamix SP metadata in your systems contains the new certificate below (expiring in 2042). If it does not for some reason, please proceed on with this article.

You should check to ensure that fresh metadata is being used. If you have statically configured metadata or a trust/IdP app for TeamDynamix, to ensure continuity of service, you will need to take three steps at appropriate points in time:

1. Verify that the TeamDynamix SP metadata in your systems contains the new certificate below (expiring in 2042). If for some reason it does not, please proceed to steps 2-4.
2. Acquire the new certificate for encryption. This is done preferably through pulling new metadata available from the Obtaining the TeamDynamix SP Metadata article in the Related Articles section. Alternatively, the certificate itself may be downloaded in various formats in the Attachments section, and is available in text below.
3. Begin using the new certificate to encrypt messages for TeamDynamix. This may be done immediately, but it must be done before November 1st, 2022.
4. Remove the old certificate (if necessary) and pull it from your trust configuration.
5. After completing steps 1-4 above, confirm back to TeamDynamix that you have completed the certificate rollover process using the survey link below. Please complete the survey even if your organization already had the new certificate.
   Take the completion survey

New Certificate Text

-----BEGIN CERTIFICATE-----
MIID/zCCAmegAwIBAgIUCZgPi/KPH1TorWbsQlXmzTZbMkkwDQYJKoZIhvcNAQEL
BQAwGjEYMBYGA1UEAxMPc2Fhcy1zaGliLXByZDAxMB4XDTIyMDIxMjA0NDYzNFoX
DTQyMDIwNzA0NDYzNFowGjEYMBYGA1UEAxMPc2Fhcy1zaGliLXByZDAxMIIBojAN
BgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEAzal2dH7U+G24WX0/Nz1bOrIloH3I
oIddStWdoRxLn7IgQh/blOMTJmj7C6hlyHTemABGPOnCQEWUYVzitLkSaWR0DyrF
Xe2aNS/hyWGxD7X7i9/amk3zz+jFmqZguTOjWrZXbxy4cgS1W8cRL7k84N6JQ3NT
9YWhlZnyvLSB27xfwpkNXwQ4yXxCF1+TfttVQFLUuh+CrMkd7hMatUbUUibWhxgJ
Vh3/dPwEcFsXYWU2tMfmxiYBxirHUxUFtlLEzjRKFbJgGTJ32SrsaZFCWKcq/Df9
5Jk9P8pBc1kNCY/yiWGX7dFd4WNhaObWGj/l0qrpJPllNWZFtZMJvVwDVVVi2JoF
b562UD5E0BJ4zT4NFBMqvsAsz7pMiRVZfogtO1TMMvo93RjieaZgXDcVw0IMy62J
DQcKoYZmLOb0AHyMHpKGxJE4EqowOQ+81633UXiAVp088hynuEpsjQPAo4p93jga
3+QDOsVLxOUcIYxAGy543Yv6pstPerX4fVIBAgMBAAGjPTA7MBoGA1UdEQQTMBGC
D3NhYXMtc2hpYi1wcmQwMTAdBgNVHQ4EFgQUGg3giCHmKfHr2byBZUsJvMt2lKow
DQYJKoZIhvcNAQELBQADggGBAKg9nPxPAqxzijENwHouw8oYjbmunyS8aNXewqq5
d9/Is3kO5XGxqXtEsn7wfkirGHgaCRsEh0pKG3fjlKw/0iRp/nhz0kCywd7qxoTM
RCaTel9EMZsrcpzbGi9tVKOAJkerryLAj/3OyXtnwfo1Wgph5WQUfB/kxAAXUe94
nME31H9YyUlVjjGTzNEaA/dpX/pxIYDZFWx6vXvASZHIZoetQgPegEZ7QSlmR7dM
M1CYJvYCN/0DL2lwGl64Z6ADS/wYVa1FvLchnm+g5hGop1DpCNKUfwlatAtldJNF
UBVmx4tySeG4mD3dVXAQhfgHeR5OcdUDIXKklRfQHm00CJqUPG1BCFJyRMhCmJIC
Ctg9Pd2tHiuCgDqORg9Xj4x6OqzTINZ0E1gr7ZBdv5c1md+LWM6XfOC8QjDrVHHn
WTdq2Ukz+TcklSWvM00CFq2wTo0KXSQJBQsN6D8K5miyjJWXvmUOv38wnRYHxOzO
xwZaguzRIcyfc0U/8mFPQo8FJw==
-----END CERTIFICATE-----

Identity System-Specific Instructions

We have also compiled specific instructions for the most commonly used identity providers amongst our clients for your convenience.

Shibboleth IdP

Shibboleth is capable of pulling service provider metadata dynamically. It is recommended that you obtain metadata using the MDQ protocol. If you prefer, you can also acquire metadata directly from TeamDynamix. 

Shibboleth can also use static metadata. If you have a saved copy of the TeamDynamix metadata on disk, please replace it and then reload the metadata service in the IdP.

Azure Active Directory (Azure AD / AAD)

To replace a certificate in Azure AD, you must import the new certificate manually using the Azure Portal and then activate it for use. TeamDynamix can support multiple certificates at one time, so you may do this at any time. It is requested that you perform a test login to ensure that the new key is being used.

To upload a new signing certificate:

1. Log into Azure Portal.
2. Locate the AAD Enterprise Application you configured for TeamDynamix SSO.
3. Click the Security > Token encryption tab in the left nav bar.
4. Import the new certificate file (use one of the files from the Attachments section of this article).
5. Click the three dots ... to the far right of the newly uploaded certificate in the grid and choose to Activate token encryption certificate.
6. Repeat step #5 for any old certificates located here but instead choose Deactivate token encryption certificate.

Active Directory Federation Services (ADFS)

Early ADFS versions require that service provider certificates be manually replaced. The easiest way to do this is by opening the ADFS management console and importing the new certificate manually in the Relying Party Trust > Encryption and Signing tabs, but PowerShell may also be used. Please consult the ADFS documentation for your version for instructions. Remove all old service provider certificates for TeamDynamix and replace them with the new one from the Attachments section.

ADFS 3.0 and later supports service provider metadata with multiple certificates. After pulling the latest metadata from the URL you are already monitoring for metadata, you can then designate the new certificate as the primary encryption certificate using PowerShell. If you are not monitoring a URL for metadata, or your ADFS for some reason will not accept multiple certificates, use the previous steps to import the certificate manually.

For hybrid ADFS/Azure AD deployments, please refer to Microsoft’s documentation.

For older ADFS 2.0 (and possibly early ADFS 3.0) Deployments
It appears that ADFS 2.0, and certain subsets of old/unpatched (TDX cannot determine the trigger for this) ADFS 3.0 deployments, are unable to dynamically monitor our Shibboleth metadata URLs (which return multiple certificates). For ADFS 3.0, sometimes patching to the latest Windows patch levels fixes this, but not always. For ADFS 2.0, there seem to be no resolutions at all for which dynamically monitored metadata will work.

If your ADFS 2.0/3.0 deployment will not let you dynamically monitor our metadata in the Monitoring tab of the Relying Party Trust:

1. Turn off monitoring in the Monitoring tab, then click OK/Apply/Save.
2. Go to the Encryption tab.
3. Manually remove our old certificate (expiring in 2022).
4. Manually add our new certificate from this KB (expiring in 2042).
5. Go to the Signature tab.
6. Manually remove our old certificate (expiring in 2022).
7. Manually add our new certificate from this KB (expiring in 2042).
8. Ensure that login sessions still work.
9. Wait for an in-app system message that TeamDynamix has completely removed the old 2022 encryption/signing certificates. This will likely be sometime in Q1 2023. Only resume monitoring in the Monitoring tab after receiving this confirmation or upgrading your ADFS deployment to ADFS 4.0.

Okta

Okta requires that a custom application be created for TeamDynamix because your environment is unique to you as a client. Note that Okta only allows you to specify a single public key to use for encryption per service. Fortunately, the software used by TeamDynamix is capable of attempting decryption with multiple keys, making up for this deficiency and allowing you to perform the key rollover at your leisure.

To perform the key rollover, browse to Okta’s documentation page on custom SAML integrations. Click Show Advanced Settings and remove the existing encryption key. Supply Okta with the new encryption key by downloading the new certificate above, ensuring that it is saved on disk with a .cer suffix, and uploading it using the GUI.

Central Authentication Service (CAS)

CAS is capable of using MDQ, REST, flat files, and more for SP metadata. The documentation does not include any precise guidance regarding key rollovers, but there is an overview of how it works. Simply import the new metadata containing both certificates, or just the new certificate if possible. If you would like, you may remove the old certificate after verifying that the new one is functioning, but dynamically pulled metadata will eventually be updated to include only the new certificate anyway.

SimpleSAML PHP

SimpleSAML PHP is capable of pulling service provider metadata dynamically. It is recommended that you obtain metadata using MDQ. If you prefer, you can also acquire metadata directly from TeamDynamix as mentioned earlier.

SimpleSAML PHP can also use static metadata. If you have a saved copy of the TeamDynamix metadata on disk, please replace it.

PortalGuard by BIO-key

According to the PortalGuard support team, it seems that PortalGuard does not even support performing assertion encryption. This article will not apply to you. Simply fill out the completion survey above.

Google IdP

From the information we can find, it does not seem that Google IdP even supports performing assertion encryption. This article will not apply to you. Simply fill out the completion survey above.

DUO SSO SAML / Access Gateway

From the documentation presented by DUO, the platform as a whole does not support assertion encryption. TeamDynamix does not require assertion encryption, so this article will not apply to you. Simply fill out the completion survey above.

Other IdPs

We will try to add guidance for other IdPs, such as Ellucian Ethos Identity / WSO2 / OneLogin / SecureAuth / etc., as we are able to research it or receive feedback from customer.