Hi,

During SSO communication, for mapping users between Creatio and the Identity Provider (in this case, Entra), we use the Name ID claim from Entra and the username field in Creatio. The Name ID claim can be set to pass any attribute from Entra — by default, it is the email, but this can be customized. (On the Creatio side, user identification is always based on the username, and this cannot be changed.)

If JIT (Just-In-Time) provisioning is enabled (which I suspect, since otherwise login would not occur when the user is missing in Creatio), a new user will be created automatically, and the username will be set to the value of the Name ID claim.

Based on your description, it looks like you are passing something other than the email in the Name ID claim. I recommend ensuring that the correct value (e.g., the user’s email) is being passed as the Name ID.




 This value will then be used to map with  the username in Creatio.

Alternatively, if JIT is disabled, you need to create the user in advance in Creatio with the username b.simon@mydomain.com, and only then test the login.

Also, make sure the user being created or used is of the Internal user type. For External users, the username field is not available — this could be the case.

Additionally, for internal debugging, you can use the following Chrome extension:
🔗 SAML Tracer

It allows you to inspect the request and response bodies and see which claims are being received from the Identity Provider.

If you have any further questions, we recommend reaching out to our support team at support@creatio.com.

Hello,

In Creatio, organizational and functional roles are transmitted using the "role" attribute. This attribute is not listed in the JIT mapping but can be found in the SsoServiceProvider table under the SamlUserRole column.

To pass user roles to Creatio, simply create a claim named "role" on the Identity Provider side. For example, in Entra ID, this would be configured accordingly.

The claim should contain the attribute value where your roles are stored.

!Important: Role names must exactly match the role names in Creatio, including case sensitivity.

Regarding SSO technology and implementation, we can only assign existing roles to a user. Roles are not created automatically because:
 

1. 1. A role must have predefined permissions or inherit from another role;
   
   2. The SSO protocol does not allow retrieving a full list of roles from the Identity Provider—only data about the current user can be obtained. So we only get the name of the role of the logged-in user, not the entire organizational role hierarchy.
   
   I hope this answers your questions.

Hi Pavlo, 

That answers my questions more completely than I was hoping. Thank you for your expertise and for including screenshots!

Joshua,

You also need to create the corresponding attribute in the SsoServiceProvider table in the SamlUserRole column, following the instructions above, and then fill it in on your SSO provider side.

Hello,

Creatio supports Single Sign-On (SSO) via Microsoft 365. In this context, "Microsoft Entra AD" is indeed the same as "Microsoft 365" when referring to the SSO setup described in the article you referenced: Set up SSO via Microsoft Entra AD.

For your second question regarding an on-site environment: the MS Exchange integration service (Email Listener Synchronization Service) is not required for configuring SSO via Microsoft Entra AD. SSO and email synchronization are separate functionalities.

The Email Listener Synchronization Service specifically supports email-related tasks, such as synchronizing and sending emails within Creatio. It does not affect or play a role in SSO configuration.

Dymytriy Vykhodets,

Thank you for the information.

Hi Jose,

You can achieve this goal by activating SSO auto-redirect for your site. This way, users who enter your site's link will be redirected to the SSO login page. Meanwhile, users who want/need to log in using credentials can use a bypass link to open the regular login page.

To activate this auto-redirect, please contact our support team.

Have a great day!

We're also facing this same requirement for our client and haven't seen an option for this - would be great to hear if it's possible and if not if it could be added to Creatio.

Harvey Adcock, Shivani,



It is possible. Do you use cloud or on-premise?



BR,

Bhoobalan Palanivelu.

Hi Bhoobalan, it is possible on cloud instances by contacting Creatio to enable it. The implementation isn’t great unless all your users (including dev/admins) use SSO though, as the auto-redirect will be cached meaning you cannot log in using Creatio username and password without using a fresh incognito window every time - it’s quite frustrating. They need to add a link that can always be used to log in via non-SSO means. 

Sourav, 



Hope that I understand your question well. 



User creation during the 1st login occurs only if JIT is enabled. 

Unfortunately, there is no OOB tools or examples of implementations of  this functionality we can provide you with. 



I will create an idea for the responsible team to consider the possibility of adding such  functionality in future.  



Thank you. 

Hi All,

Can anyone answer on this?

Thanks,

Sourav

Dear Sourav, 



I would suggest you to carefully check the web.config file located in the root folder of Creatio. 

In this file you can find the list of login providers (the place where you enabling JIT by the guide):



        <provider name="SsoAuthProvider" type="Terrasoft.WebApp.Loader.Authentication.SSO.SsoAuthProvider, Terrasoft.WebApp.Loader">

          <parameters>

            <add name="UserType" value="General" />

            <add name="UseJit" value="false" />

          </parameters>

        </provider>

        <provider name="SSPSsoAuthProvider" type="Terrasoft.WebApp.Loader.Authentication.SSO.SsoAuthProvider, Terrasoft.WebApp.Loader">

          <parameters>

            <add name="UserType" value="SSP" />

          </parameters>



If you want to enable JIT for portal user you need to make sure that key <add name="UseJit" value="false" /> is added to the block related to the "SSPSsoAuthProvider"

so it looks like:

    <provider name="SSPSsoAuthProvider" type="Terrasoft.WebApp.Loader.Authentication.SSO.SsoAuthProvider, Terrasoft.WebApp.Loader">

          <parameters>

            <add name="UserType" value="SSP" />

            <add name="UseJit" value="true" />

          </parameters>



After that please make sure that SspLogin.aspx is specified in all keys instead of NuiLogin.aspx to make sure that user will get a proper portal cookie in case if you want to use a Service Provider initiated SSO flow to create portal users. 

Also please note that in this case ordinary company employees will have to login via direct link only or use the link to NuiLogin.aspx module if they want to use SSO as well. 



Kind regards,

Roman

Roman Brown,

Does this mean we can only use Jit either for Portal User or for Company Employee user?

Regards,

Sourav

Hello,

Yes, it is possible to set up SSO through OKTA. Unfortunately, we do not have specific instructions for this product, but you can use the Single Sign-On via ADFS Academy article for your reference. 

Best regards,

Bogdan

Bogdan,

We are also trying to configure from OKTA's side as well. But there are certain ask that we are unsure about. Could you please suggest on the following questions from Creatio perspective?

• Single Sign On URL - https://site.creatio.com/ServiceModel/AuthService.svc/SsoLogin
• SP Entity Id -
• Default Relay state -

Thanks,

Sourav

Bogdan,

Is there any information on this?

Thanks

Sourav, 



This application is in "Upcoming" state meaning that it will be available in Future. 

As for your first question, you need to insert following values:

 

• Single Sign On URL - https://site.creatio.com/ServiceModel/AuthService.svc/SsoLogin
• SP Entity Id - https://site.creatio.com/
• Default Relay state - you can leave it blank. 

Kind regards,

Roman

 

Roman Brown,

What is the LocalCertificateFile and where to get this for onsite applications?

Thanks,

Sourav

Hi Anusha, 

it's now allowed in HTTP/2 (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.5), which specifies: 

8.1.2.5.  Compressing the Cookie Header Field
 
   The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
   cookie-pairs (or "crumbs").  This header field doesn't follow the
   list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
   prevents cookie-pairs from being separated into different name-value
   pairs.  This can significantly reduce compression efficiency as
   individual cookie-pairs are updated.
 
   To allow for better compression efficiency, the Cookie header field
   MAY be split into separate header fields, each with one or more
   cookie-pairs.  If there are multiple Cookie header fields after
   decompression, these MUST be concatenated into a single octet string
   using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
   before being passed into a non-HTTP/2 context, such as an HTTP/1.1
   connection, or a generic HTTP server application.
 
   Therefore, the following two lists of Cookie header fields are
   semantically equivalent.
 
     cookie: a=b; c=d; e=f
 
     cookie: a=b
     cookie: c=d
     cookie: e=f

Please also check out this article:

https://datatracker.ietf.org/doc/html/rfc6265#page-7

Best Regards, 

Bogdan L.

Bogdan Lesyk,

Thanks Bogdan. It was really helpfull, will check alternative way to process from the client API side.