Force a fixe value for a Mapped AttributeDefinition (DocuSign AccountID)

[Jehan PROCACCIA]

I want to send our AccountID (provided by docusign) in order that automatically at 1rst login our users be created with the correct permissions.
in DocuSing (DS)  there's a DS-viewer and a Ds-sender (also a DS-admin), and based on our ldap employeeType attribute I mapped a "DS-Viewer/Sender"

I create a wiki page reagarding that DS integration with shibboleth IDP 4 , because I encountered many customisation needed:
no encryption, specific nameID (persistent + mail based), mapping attributes, metadata exchange ... : 
http://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:shibboleth:docusign
regarding that automation of  profile-permission here it is: 
http://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:shibboleth:docusign#permission_map

but I hope that the StaticDataConnector will fufill my needs by adding the accoundID to the sent attributes

anyway, I'll be glad to have your opnion on my DS integration with IDP 4 , maybe I customized too many things that were not mandatory ? 

thanks

----- Mail original -----
De: "Cantor, Scott" <cantor.2 at osu.edu>
À: "users" <users at shibboleth.net>
Envoyé: Jeudi 28 Janvier 2021 20:11:31
Objet: Re: Force a fixe value for a Mapped  AttributeDefinition (DocuSign AccountID)

On 1/28/21, 1:32 PM, "users on behalf of Jehan PROCACCIA" <users-bounces at shibboleth.net on behalf of jehan.procaccia at tem-tsp.eu> wrote:

>    Now  I need to map a fixe accountID that must be unique for all users.

I would note that I support Docusign and have not had to do that. We do have two tenants, but they're test/prod, so it's possible multiple "real" tenants might create a scenario where such a thing is being imposed.

I do have a rule that I never do that. If a vendor asks me to pass them a fixed value, I tell them to stuff it, as that's not something any IdP should be expected to tell them about their own service.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net