This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
docpublic:systemes:shibboleth:docusign [2021/01/28 11:44] procacci@tem-tsp.eu [NameID] |
docpublic:systemes:shibboleth:docusign [2023/10/24 14:46] (current) adminjp [shib IDP attribute-resolver] |
||
---|---|---|---|
Line 2: | Line 2: | ||
This page shows how to enable a shibboleth IDP v4 to authenticate and send attributes to a DocuSign Service Provider . | This page shows how to enable a shibboleth IDP v4 to authenticate and send attributes to a DocuSign Service Provider . | ||
+ | |||
+ | external references : | ||
+ | |||
+ | * https:// | ||
+ | * https:// | ||
===== DocuSign demo SP ===== | ===== DocuSign demo SP ===== | ||
Line 33: | Line 38: | ||
{{: | {{: | ||
- | We also set thet we use signe AuthN an use Post Method . | + | We also set that we use signed |
==== DocuSign SP Metadata ==== | ==== DocuSign SP Metadata ==== | ||
Line 55: | Line 60: | ||
=== SP metadata certificate === | === SP metadata certificate === | ||
- | the ducosing | + | the DocuSign |
get certificate from SP metadata element X509Certificate : | get certificate from SP metadata element X509Certificate : | ||
Line 207: | Line 212: | ||
these are the mandatory attributes : | these are the mandatory attributes : | ||
- | * sn surname | + | * sn (surname) |
* givenName | * givenName | ||
Line 213: | Line 218: | ||
and optionnally | and optionnally | ||
+ | * permissionProfileId | ||
+ | |||
+ | this one allows to match a permission profile at login, for example sending a employeetyp attribute for Staff people could set their default profile to DS-Sender and for employeetype: | ||
+ | |||
+ | :!: beware that these attributes are define in the interface with their urn/oid code, the " | ||
{{: | {{: | ||
+ | ===== shib IDP attribute-resolver ===== | ||
+ | |||
+ | In the IDP we use the **attribute-resolver-ldap.xml** (or attribute-resolver.xml) | ||
+ | |||
+ | < | ||
+ | [root@idptest conf]# grep attribute-resolver-ldap.xml services.xml | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | ==== mapped attributes ==== | ||
+ | |||
+ | in order to map DocuSign domains ID to our mail domains we need to map values | ||
+ | |||
+ | attribute-resolver.xml mapped employeType | ||
+ | |||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | < | ||
+ | <!-- Values Prod --> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | ... | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | </ | ||
+ | |||
+ | </ | ||
+ | |||
+ | idem for staticDSAccountID | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | name=" | ||
+ | < | ||
+ | <!-- Values DocuSign Prod --> | ||
+ | <!-- < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | ... | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ==== Mail rewriting ==== | ||
+ | |||
+ | because on our campus we use 3 domains names in our users mail addresses, in order to simplify DocuSign domain claims and IDP declaration (+ metadata) , we recorded only one domain at DocuSign SP and manage to rewrite dynamically on our IDP side the 2 other domains to the 1st one , which is the only one declared on DocuSign . | ||
+ | |||
+ | To do that we uses a Mapped Attribute definition like this : | ||
+ | |||
+ | < | ||
+ | | ||
+ | < | ||
+ | < | ||
+ | name=" | ||
+ | < | ||
+ | name=" | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | when a user connect with it's email address of givenName.Surname@**domain2**.eu , it is finally transmited to DocuSign SP as givenName.Surname@**domain1**.eu . | ||
+ | |||
+ | ==== Permission map ==== | ||
+ | |||
+ | We also used a mapped attribute definition in oder to match Roles/ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ==== static AttributeDefinition for AccountID ==== | ||
+ | |||
+ | DocuSign support told us also to send a static value for the accoundID so that automatic profile affectation could be done | ||
+ | |||
+ | we can get our API account ID from the E-Signature parameter screen , left menu => API-Keys | ||
+ | |||
+ | {{: | ||
+ | |||
+ | then we need our IDP to map and send that static value for everyone, so we creted a staticDataconnector and the associated decated static AttributeDefinition for thos DocuSign authZ feature with the creation of a custom staticDSAccountID attribute : | ||
+ | |||
+ | references : | ||
+ | |||
+ | * https:// | ||
+ | * https:// | ||
+ | |||
+ | in conf/ | ||
+ | |||
+ | < | ||
+ | |||
+ | < | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | name=" | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ==== Special case when unsing NAT ( checkAddress=" | ||
+ | |||
+ | clients in specific site which don't have many public IPs addresses use NAT , and it breaks the flow of using a proxied IDP | ||
+ | In that case we must disable " | ||
+ | |||
+ | Analagous to the SP, there' | ||
+ | |||
+ | https:// | ||
+ | |||
+ | |||
+ | from examples in the doc: | ||
+ | * https:// | ||
+ | I understand that I can specify the checkAddress attribute only for those "2nd Hand/ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | <bean parent=" | ||
+ | </ | ||
+ | </ |