Cintoo SSO Implementation Guide

This article describes advantages and options to choose from for a Single Sign-On, what advantages it gives to the company and what information is to be provided to Cintoo to set up SSO correctly.

TABLE OF CONTENTS

Overview 

Cintoo can be integrated with your corporate Single Sign-On (SSO) solution, to fulfill corporate security requirements and simplify user management.

Cintoo supports OpenID Connect (OIDC) and SAML protocols, and is compatible with the following identity providers:

  • Azure AD (preferred provider)
  • Microsoft ADFS
  • Okta / Okta MyID
  • Ping Federate

Contact Cintoo sales representative or sales@cintoo.com to subscribe to the SSO option for your Cintoo account.

Authentication Flow


Authentication in Cintoo is done in two steps:

  • Enter login (e-mail address)
  • Depending on the domain name (second part of the e-mail after the @ character), redirect to either Cintoo native authentication screen (i.e., with a Cintoo login and password), or to the corporate SSO login screen.


This means that once SSO is activated for the @corp.com domain, any user with a login of the form user@corp.com is redirected to the corresponding identity provider login screen, and there is no way to fall back to the native Cintoo authentication.


Note: customers who subscribed to a custom Cintoo domain (of the form https://corp.cintoo.cloud) can ask to use their own SSO provider for all users, independently of the user’s domain name. See section about External Users below.

User Provisioning


SSO is only used for authentication and has no impact on the way users are created in a Cintoo account. Users still must be invited by an account administrator, or by a project / BIM manager. 

Any user trying to authenticate using SSO without being invited first in the account will not be able to log in.

External Users 


If external users are invited (i.e., with an email in a domain you do not control) to your projects, by default these users will not authenticate with your SSO, as SSO is configured per domain name.

Example:

  • Your company domain name is corp.com
  • You invite user@guest.com to one of your projects
  • If guest.com is also a Cintoo customer and subscribed to the SSO option, then user@guest.com will authenticate through guest.com SSO (notcorp.com SSO). Otherwise, this user will log in through the native Cintoo authentication.


To increase control over your external users, you may want to:

  • Add all external users as guests in your own user directory (e.g., user-guest@corp.com)
  • Subscribe to a custom Cintoo domain, i.e., https://corp.cintoo.cloud (contact Cintoo sales for information). This way you will get your own Cintoo tenant, and all your projects will only be accessible through https://corp.cintoo.cloud.
  • Ask Cintoo IT team to link your custom domain with your SSO provider. This means that any user trying to open a project in https://corp.cintoo.cloud will be redirected to your own SSO, even if they do not have a @corp.com email address.

SSO Implementation Process

 

SSO implementation always follows these steps:

  • Contact Cintoo sales to subscribe to the option
  • Configure your identity provider with OIDC or SAML, and communicate the required information to Cintoo IT team via support@cintoo.com (see details below)
  • Validate SSO configuration with a few users, using a temporary login URL
  • Agree with Cintoo IT team about a cutover date, after which all users in your domain will be redirected to your SSO login screen

Warning: users created in Cintoo prior to the cutover will not be able to connect anymore with their existing Cintoo password.

Identity Provider Configuration

 

Option 1: OpenID Connect


Azure AD Using a Custom Application

 

If you do not want to or cannot provision the generic Cintoo application provided in the Azure AD app gallery, you still have the option to create your own application in Azure AD.

In Azure AD, select App registrations, then New registration

Une image contenant texte Description générée automatiquement


Note: the domain in the redirect URI must match the domain of your Cintoo instance (e.g., aec.cintoo.com, us.cintoo.cloud, [corp].cintoo.cloud).


Once application is created, edit Authentication settings and enable ID tokens option.

Une image contenant texte, capture d’écran, moniteur, écran Description générée automatiquement


Note Application (client) ID and Directory (tenant) ID of the application and communicate these values to Cintoo Support team.

Une image contenant texte, capture d’écran, moniteur, écran Description générée automatiquement


Note: Cintoo tries to match the user based on its email address. If the upn field of Azure AD users does not contain the email address, configure an optional email claim containing the user's email address (in that case Cintoo will look at the email field in the OAuth reply instead of upn).


Here is how to add this optional claim.


It is mandatory to add an API permission for Microsoft Graph to read email address.

Okta


In Okta Administration, create a new app.


Select Web / OpenID Connect.


Add the needed redirect URL.

 

Note: redirect URI depends on the domain name of your Cintoo instance. Check with Cintoo Support team which is the correct one.


In the next screen, General Settings, click Edit and add ID Token with implicit grant permission.


When it is done, go to Sign On tab and note Issuer and Audience fields in OpenID Connect ID Token section.


These values will have to be communicated to Cintoo Support team.

Other Providers


Here is the generic configuration for any other identity provider using OpenID Connect:

  • Create a Cintoo application
  • Configure the redirect URI: https://<domain>/login/oauthcb where domain depends on your Cintoo instance (e.g., us.cintoo.cloud or eu.cintoo.cloud)
  • Allow ID token with implicit grant
  • Allow the following scopes: openID email profile
  • Communicate the following information to Cintoo Support team:
    1. Client ID
    2. OpenID Connect discovery URL (e.g., https://<your_domain>/.well-known/openid-configuration)


Note: Cintoo matches the username based on the email field in the OAuth reply. If there is no email field, the upn field is used instead.

Option 2: SAML

 

Here is the Service Provider Metadata you will need to configure within your SAML identity provider.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://<domain>/saml">
    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://<domain>/saml" index="1"/>
    </md:SPSSODescriptor>
</md:EntityDescriptor>

 

Note: domain must be replaced by the domain name corresponding to your instance of Cintoo (e.g., eu.cintoo.cloud, us.cintoo.cloud, or your-company.cintoo.cloud).


You will need to communicate your IdP metadata URL of file to Cintoo Support team, or at least the following details:

  • IDP entity ID
  • Login URL
  • Signing certificate(s)


Note: Cintoo matches the username based on the NameID field (SAML subject) in the SAML response. The NameID must be same as the Cintoo login, i.e. the user’s email address.