TeamDynamix has its own built-in authentication, where users have a password unique to TeamDynamix that’s set and managed within TeamDynamix. However, most clients are interested in their users authenticating using Single Sign-On (with Shibboleth or ADFS) or LDAP/Active Directory.
Are you an InCommon member?
TeamDynamix is an InCommon member. If your institution is an InCommon member, authentication is very straightforward. Go to Admin, click on your entity’s name, and under the “Security” pane on the right click “Configure” by “Single Sign-On.” Enter your institution’s Entity ID and logout URL.
TeamDynamix's entity ID is https://www.teamdynamix.com/shibboleth. (Note: the entity ID is not a valid URL, and that's OK.)
Does your institution have Shibboleth or ADFS?
If your institution has Shibboleth or ADFS then you may be able to use Single Sign-On (SSO) with TeamDynamix.
Before this will work, TeamDynamix needs to know two things:
- your metadata URL. The metadata URL for ADFS looks something like
https://adfs.example.edu/federationmetadata/2007-06/federationmetadata.xml.
Please note: TeamDynamix needs a metadata URL, not a copy of your metadata. TeamDynamix will then be able to download your metadata when it changes.
- your scope for usernames, e.g. "@example.edu".
Please contact your consultant to have your metadata URL and scope added into TeamDynamix’s environment.
For your reference, TeamDynamix’s metadata URL is https://shib.teamdynamix.com/Shibboleth.sso/Metadata.
This knowledge base article describes how to make ADFS work properly with SSO.
Using and Testing Single Sign-On
Please consider the attributes that your Shibboleth or ADFS environment releases to TeamDynamix. At a minimum, please send the user’s first name, last name, and email address. If you configure self-registration profiles then you may want to release other attributes as well.
Briefly, here is how SSO works:
- When someone is on your institution’s TeamDynamix site, e.g. https://example.teamdynamix.com, and they would normally be asked to log in, TeamDynamix will instead redirect them to your environment
- Your environment authenticates the user
- Your environment tells TeamDynamix that the user has authenticated, using SAML
Once TeamDynamix has added your metadata URL (either by your request or because you are an InCommon member), then you can configure SSO.
To test SSO, you can use your sandbox environment or your production environment. Both your production and sandbox environments will work with the same entity ID and settings. Here are steps to test SSO:
- Go to your user record and ensure the “Authentication Username” is populated
- Turn on SSO, by
- going to Admin > Main organization page > Security tab > Single Sign On > "Configure"
- typing in your Entity ID
- typing in your Logout URL (optional)
- clicking "Enable SSO"
- Do not close the browser you were using—you will need it in case SSO does not yet work. In another browser:
- try to make sure you are logged out of your institution’s Shibboleth/ADFS environment.
- try to log into your environment.
- Did you...
- get redirected properly to your environment for logging in?
- get redirected back to TeamDynamix?
- get logged in properly to your account?
- If you logged in properly, that’s great! SSO is working. If you did not get logged in properly, go back to your browser where you turned on SSO and turn SSO off.
Once you have SSO working, you may have situations where you need to log in without SSO. See the article Bypassing SSO to Access TeamDynamix for more information
If your institution does not have Shibboleth or ADFS, but you do have Active Directory or LDAP that TeamDynamix can connect to, then you will use what TeamDynamix calls authentication providers. You can have multiple authentication providers.
You will need to allow TeamDynamix's IP addresses to connect to your Active Directory or LDAP environment.
After you have configured authentication providers, you must configure each user record to use the appropriate authentication provider. For example, some organizations have one authentication provider for staff/faculty and another for students. You can do this one-at-a-time by selecting users from Admin > Users & Roles > Users, or you can do this in bulk via setting the Authentication Provider field when you import people.
See the article Common LDAP Configuration Gotchas for more information.