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

[Jehan PROCACCIA]

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 https://wiki.shibboleth.net/confluence/display/IDP4/StaticDataConnector sample) 

<DataConnector id="staticDSAccountID" xsi:type="Static">
        <AttributeEncoder xsi:type="SAML2String"
                name="urn:oid:1.3.6.1.4.1.7399.5.1.1.1" friendlyName="staticDSAccountID" />
    <Attribute id="staticDSAccountID">
        <Value>ai4dc9cfa7-dd39-aad1-884c-2f9b17574224</Value>
    </Attribute>
</DataConnector>

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 net.shibboleth.utilities.java.support.component.ComponentInitializationException: Service 'shibboleth.AttributeResolverService': could not perform initial load
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
Caused by: net.shibboleth.utilities.java.support.component.ComponentInitializationException: Service 'shibboleth.AttributeResolverService': could not perform initial load
        at net.shibboleth.utilities.java.support.service.AbstractReloadableService.doInitialize(AbstractReloadableService.java:180)
Caused by: net.shibboleth.utilities.java.support.service.ServiceException: 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 osu.edu>
À: "users" <users at shibboleth.net>
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 shibboleth.net on behalf of jehan.procaccia at tem-tsp.eu> 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 https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net