Mingle SaaS and SSO

Mingle is compatible with SAML 2.0 but currently supports only Okta as it's third party SSO provider.

*For the time being, we have no immediate plans to support SSO via other SSO providers. However, this may change if we learn our customers are using other SSO providers. However, they must use SAML 2.0. Please let us know if you are curious about integrating with another SSO provider.

Below is a little more information on how Mingle currently integrates with Okta:

1. Granting access via Okta to users who currently do not exist on your Mingle site will automatically create a new user the first time they access Mingle via Okta. If, however, you are only granting access to users who currently exist on your Mingle site, no new users will be created.

2. Please make sure your users’ Okta sign-in name matches their Mingle sign-in name. If not, a new user will be created and you’ll have to change their Mingle privileges so they can access projects accordingly.

If you use a different provider, and would like to test out compatibility, please use the following configurations with your SSO provider. Also, remember that Mingle only works with SAML 2.0.

ACS/Endpoint URL : https://profile.thoughtworks.com/saml/consume?RelayState=site_name
SP Entity ID or SAML Issuer : https://profile.thoughtworks.com

In SP flow:

User opens a Mingle site URL in the browser, then Mingle redirects with a "RelayState" parameter to IDP SSO login URL.
IDP should send a POST request and return back to Mingle after the user signed in successfully.

In IDP flow:

The User will open an IDP portal and click Mingle site URL to login to Mingle. IDP should either choose POST or REDIRECT request with a default RelayState and the ConsumerAssertionURL will be https://profile.thoughtworks.com/saml/consume.

Assertions

User ID is the only thing expected. You should use same format of sign-in name in Mingle as User ID sent to Mingle, so that Mingle won’t create new user after it's hooked up with an IDP service.

ex. If you used email as user's sign-in name in Mingle, then you should send email as User ID.
If you used an email prefix (xli is prefix of xli@thoughtworks.com) as user's sign-in name in Mingle, then you should also send email prefix as User ID

How will the user accounts be created?

The user id (passed from IDP) will be used to map with Mingle user sign-in, if Mingle could not find a user with the sign-in name, a new user with the sign-in name will be created.
And the new user created will only have sign-in name set, need user update their profile in Mingle after logged in.

Mingle does not accept any other fields from IDP.

Request Compression

The request (or response from IDP) should be Compressed.

Authentication Context

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

name_identifier_format = 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'

Please reach out to support@thoughtworks.com if you have any questions or concerns about configuring Mingle with SSO.