We are testing out creating additional org roles and want the users to automatically get assigned when they SSO in. One user can have multiple org roles.
We saw there’s some SSO fields already mapped to Contact like branch -> Branch, displayname -> Name and that kind of thing, but I’m stuck on figuring out how they get assigned to org role.
I found VwSysRole that spells out all the different roles and SysUserInRole where they give individual role assignments for each user (multiple ok).
Just can’t find the gap - how they go from SSO JIT to assigned to an org role. Any chance you know?
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. 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.
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. 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.
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.
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.
We are on the process of implementing SSO and the users testing are getting confused because they are used to enter their credentials on the Creatio Login page (basically clicking on the Single Sign on link is foreign to them.)
Is it possible to have two different login pages? One with the Creatio Login page and another just with the SSO link?
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.
I am setting up Single Sign On configuration in Creatio version 8.1.2.3942 (.NET 6.0.33) and I'm getting error while the connection is secure and certification is valid.
However when I try to setup it on local instance, it works perfectly fine.
Also, I cannot add or modify a new SSO custom OPEN ID as shown is picture below:
We have enabled Azure AD SSO for our customer. One issue we face is that every time the customer hits the login page, they are required to click on the "Login with Single Sign On" link. Is it possible to auto redirect to SSO (assuming that users are signed in)?
Could you also please let us know if there are any config related changes we need to enable to auto login via SSO?
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.
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.
When a new user is provisioned through SSO, we want restrict the user creation or restrict the user from 1st time login, so that we can implement an addition approval layer.
I am trying to implement JIT when a user is not present. But by default it is creating a user as "Company Employee". Any suggestions how I can identify and create either Company Employee or Portal user based on the response that has been received in the SAML token.
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"
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.
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.
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?
From the /ServiceModel/AuthService.svc/Login authorization API respond with 4 Set-Cookie headers in the response. But according to the spec [https://datatracker.ietf.org/doc/html/rfc6265#section-4.1] , "Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name." From the client application, it can't get the all 4 header values, only first one retrievable. Could you please give a fix or suitable workaround for this.
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
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
