[[DocuSign]]
Differences
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 10:11] procacci@tem-tsp.eu [DocuSign SP Metadata] |
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 82: | Line 87: | ||
| Now that we have the SP metadata, we can load it in our IDP configuration, | Now that we have the SP metadata, we can load it in our IDP configuration, | ||
| - | <!-- SP DocuSign--> | + | < |
| + | [root@idptest conf]# vim metadata-providers.xml | ||
| + | |||
| + | <!-- SP METADATA | ||
| < | < | ||
| backingFile=" | backingFile=" | ||
| - | metadataURL=" | + | metadataURL=" |
| < | < | ||
| certificateFile=" | certificateFile=" | ||
| Line 133: | Line 141: | ||
| </ | </ | ||
| + | ==== NameID ==== | ||
| + | DocuSign expect by default an identifier (SAML NameID) that is persistent and mapped to the mail attribute . By default and design for dataProtection, | ||
| + | |||
| + | this is done in saml-nameid.xml with activating ** <ref bean=" | ||
| + | |||
| + | < | ||
| + | [root@idptest conf]# vim saml-nameid.xml | ||
| + | |||
| + | < | ||
| + | < | ||
| + | |||
| + | <ref bean=" | ||
| + | |||
| + | <!-- Uncommenting this bean requires configuration in saml-nameid.properties. --> | ||
| + | <!-- Jehan --> | ||
| + | <ref bean=" | ||
| + | <!-- | ||
| + | <bean parent=" | ||
| + | p: | ||
| + | p: | ||
| + | p: | ||
| + | < | ||
| + | <bean parent=" | ||
| + | c: | ||
| + | /> | ||
| + | </ | ||
| + | </ | ||
| + | | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | I keept shibboleth.SAML2AttributeSourcedGenerator as commented for example above, that was a way to designated a **candidate** SP dedicated to that NameID Generator, but finally here in this test IDP for docusign , default is persistent ID for all . | ||
| + | |||
| + | in **saml-nameid.properties** we define the use of the mail attribute associated with a Salt | ||
| + | here the **idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator** is defined (no need for a database storage) | ||
| + | |||
| + | < | ||
| + | idp.persistentId.useUnfilteredAttributes = true | ||
| + | idp.persistentId.sourceAttribute = mail | ||
| + | idp.persistentId.encoding = BASE64 | ||
| + | #jehan | ||
| + | idp.persistentId.algorithm = SHA | ||
| + | idp.persistentId.salt = secretpassfor202101isi # needs to long enough ! | ||
| + | |||
| + | # To use a database, use shibboleth.StoredPersistentIdGenerator | ||
| + | idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator | ||
| + | </ | ||
| + | |||
| + | authN is associated with the authn Flow Password process in the IDP: | ||
| + | |||
| + | < | ||
| + | [root@idpt conf]# grep authn.flows idp.properties | ||
| + | | ||
| + | </ | ||
| + | |||
| + | and define the ldap backend with a filter based on mail attribute : | ||
| + | |||
| + | < | ||
| + | [root@idptest conf]# vim ldap.properties | ||
| + | idp.authn.LDAP.userFilter | ||
| + | ## | ||
| + | idp.attribute.resolver.LDAP.searchFilter | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== Mapped Attributes ==== | ||
| + | |||
| + | Now that authN is configured , we also need to send attributes to DocuSign SP in order to match mandatory attributes at first connexion in order to dynamically create account. | ||
| + | these are the mandatory attributes : | ||
| + | |||
| + | * sn (surname) | ||
| + | * givenName | ||
| + | |||
| + | |||
| + | 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=" | ||
| + | </ | ||
| + | </ | ||
