Hello @3dl5q (3dl5q)​ Thank you for reacting out to our Community!

Usually the JIT option is enabled on the SP side, in this case DocuSign. Looking at their documentation JIT should be possible without the 2 attributes mentioned, please see below:

https://support.docusign.com/s/articles/How-do-I-utilize-just-in-time-provisioning-as-an-Organization-Administrator?language=en_US&rsc_301

Also, when you add an application with SAML, on the sign on tab you have the option to send additional attributes in the SAML assertion. However it seems the version of DocuSign does not have these options and without enabling provisioning this is not possible. I would recommend to just enable Provisioning as this is an available feature.

Community members help others by clicking Like or Select as Best on responses. Try it today.

Watch and Learn: New Okta how-to videos, plus what's new this month in the May newsletter.

So I managed to set up custom assertions that added the correct values for accountid and permissionprofileid. This is confirmed by checking the SAML assertion response. But I hit a roadblock, it looks like the way DS is setup with user provisioning, you have to make use of their JIT functionality to assign a user to a specific account with a specific role and this can only happen if the account doesn't exist and the custom attributes present in the SAML assertion is present in the first SSO login attempt (with JIT enabled in DS).

This means that if a user account is already present within DS I wouldnt be able to make any changes to that account with those SAML assertions even though they are present in the SAML response they are ignored by DS.

The standard user provisioning using SCIM is of no use if you have multiple accounts on DS. You can only assign users to a default account albeit with any permission. The only time the "accountid" custom attribute is accepted is in a JIT scenario when the account has not been created yet in DS and even though if you have multiple E-Sig accounts you can only assign one during the account creation phase.

Yes I have. I cloned the original DocuSign integration for how many eSignature accounts we use. Then I shared the cert of the original DocuSign integration with the other clones so that DocuSign recognizes the clones as the original. The difference between the clones is each cloned integration is a custom attribute reference added to the corresponding DS User (associated with the corresponding DS integration). I disabled SCIM, created both the accountid and profilepermissionid custom attribute which contained each account ID for the individual accounts associated with DS and the profilepermissionid for each profile associated with the respective DS account. I split these into each cloned instance, meaning for example clone 1 - account 1 with account 1 permissions, clone 2 - account 2 with account 2 permissions etc. Then re-enabled SCIM and referenced the values for accountid and permissionid in the SAML assertion as custom attributes. On all integrations I enabled SCIM but disabled "account creation" and kept JIT enabled on the DS instance to allow for seamless onboarding flow. The result was as good as it can get, I've spent over 50 hours testing all difference scenarios, this is the best for the workflow we have.

@3dl5q (3dl5q)​ I still not understand what's your environment like. as my is one organzation with two accounts.

Hi,

I managed to redirect a new user to a specific instance based on his AD group's membership. If a user is not member of a specific group, it will be redirect to our default instance.

In our environment we have 20 Docusign instances linked to our organization. We created 20 AD groups synced in Okta.

I use theses AD groups and the two attributes "API Acccount ID" and "PermissionProfileID" to assign the correct instance and the default DSViewer Role.

• I created a custom SAML App and did the SSO configuration with Docusign
• In the SAML App, I added the following attributes :
  • For accountid and permissionprofileid, I use "appuser.XXX"
  • emailaddress - unspecified - user.email
  • givenname - unspecified - user.firstname
  • surname - unspecified - user.lastname
  • accountid - unspecified - appuser.accountid
  • permissionprofileid - unspecified - appuser.permissionprofileid

• After that, I created two rules based on group membership to assign to the right instance and the default role permission (Ds viewer in my case)

Let's say we have 3 instances and 1 default instance. The two rules check the group's membership of a user :

IF a user is member of group1, SET ap_instance_id value. IF NOT , verify if member of group2 etc... ELSE SET the default instance ID

#AccountID rule

isMemberOfGroupName("ADgroup1")?"api_instance_id1":

isMemberOfGroupName("ADgroup2")?"api_instance_id2":

isMemberOfGroupName("ADgroup3")?"api_instance_id3":"api_default_instance_id"

#permissionprofileid rule

isMemberOfGroupName("ADgroup1")?"permissionprofileid1":

isMemberOfGroupName("ADgroup2")?"permissionprofileid2":

isMemberOfGroupName("ADgroup3")?"permissionprofileid3":"default_permissionprofileid"

These two rules will be added to the Docusign SAML app mapping profile

• Go to profile > docusign app, add two attributes

• DisplayName : accountid
  • variableName : accountid
  • Scope : User personnal Checked
  • DisplayName : permissionprofileid
  • variableName : permissionprofileid
  • Scope : User personnal Checked

• After that, Go to Mappings > Okta user to Docusign app

Copy / paste each rule in the right attribute and choose "Apply mapping on user create only"

Example :

• Verify if a user has a the correct values based on his group with the Preview button
• Save mappings if it's ok

TEST

Assign the new user to the docusign Okta app. Verify if the user has the correct values.

Try to log on in Docusign and verify that he has been redirected to right instance and has the default role you specified (Ds viewer in my case)

PS : sorry for my english.