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

Jehan PROCACCIA jehan.procaccia at
Thu Jan 28 21:35:10 UTC 2021

Still these kind of vendors (here DocuSign) don't run a connexion flow as we are used in our academic "eco-systems" with a Discovery Service / WAYF frontend and that's a shame . 
They ask me to declare as much IDPs as there are in our group of Universities/Schools, and because each school may have more than one DNS domains we would need to claim all of our users email domains names in their admin interface in order to allow each user email prefix domains to connect . 
I manage with mapped Attribute to rewrite on the fly (by the IDP) some domains to a common one claimed at DS , but thats another customization burden needed . 

anyway, I'am still having a hard time to create the static attribute for the DS accountID I need , here's how I defined it (from sample) 

<DataConnector id="staticDSAccountID" xsi:type="Static">
        <AttributeEncoder xsi:type="SAML2String"
                name="urn:oid:" friendlyName="staticDSAccountID" />
    <Attribute id="staticDSAccountID">

and associated Error Log at IDP startup : 

2021-01-28 22:16:39,692 -  - ERROR [org.springframework.web.context.ContextLoader:313] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.AttributeResolverService' defined in file [/opt/shibboleth-idp/system/conf/services-system.xml]: Invocation of init method failed; nested exception is Service 'shibboleth.AttributeResolverService': could not perform initial load
Caused by: Service 'shibboleth.AttributeResolverService': could not perform initial load
Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 129 in XML document from file [/opt/shibboleth-idp/conf/attribute-resolver-ldap.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 129; columnNumber: 86; cvc-complex-type.2.4.a: Invalid content was found starting with element '{"urn:mace:shibboleth:2.0:resolver":AttributeEncoder}'. One of '{"urn:mace:shibboleth:2.0:resolver":InputAttributeDefinition, "urn:mace:shibboleth:2.0:resolver":InputDataConnector, "urn:mace:shibboleth:2.0:resolver":Attribute}' is expected.

thanks for your help . 

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

On 1/28/21, 3:01 PM, "users on behalf of Jehan PROCACCIA" <users-bounces at on behalf of jehan.procaccia at> wrote:

>    I want to send our AccountID (provided by docusign) in order that automatically at 1rst login our users be created with
> the correct permissions.

That may be the difference, our system is pre-provisioned I believe.

>    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 ... : 

They certainly support encryption, but they do require persistent NameIDs, I am aware of that. They do update email addresses based on that. It's all a bit under the covers but it matches what I had to do.

>    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 ? 

Only the encryption thing stands out.

I'm simply saying that when a vendor asks me to send them a fixed value for everybody, the obvious response is "why on earth can't you apply the same value at your end?". If the value is not in fact "fixed" but a signal to use a particular role and it just *happens* to be set the same for everyone, that's quite different. It's only fixed as a matter of policy choice, not design.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list