alternate attribute names

[Baron Fujimoto]

This looks promising, but apparently I'm missing something.

I've defined the the predicat in file named activation-condition-predicates.xml based on the the example from the ActivationConditions doc like so:

    <bean id="singleValueMailSPs" parent="shibboleth.Conditions.RelyingPartyId">
        <constructor-arg name="candidates">
            <list>
                <value>https://sp.example.com/shibboleth</value>
                <value>https://arcggis</value>
            </list>
        </constructor-arg>
    </bean>

I've used the list version to support potential future expansion.

I reference this from my services.xml by adding it to the AttributeResolverResources:
(I believe this the the recommended method based on the docs)

    <util:list id ="shibboleth.AttributeResolverResources">
        <value>%{idp.home}/conf/attribute-resolver.xml</value>
        <value>%{idp.home}/conf/activation-condition-predicates.xml</value>
    </util:list>

It appears to load ok:

INFO [net.shibboleth.ext.spring.util.SchemaTypeAwareXMLBeanDefinitionReader:317] - Loading XML bean definitions from file [/home/shib/idp/conf/activation-condition-predicates.xml]

I have a test relying party entry which defines the relyingPartyId:

    <RelyingParty id="https://arcgis"
            provider="https://idp.hawaii.edu/idp/shibboleth"
            defaultSigningCredentialRef="IdPCredential">
        <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
    </RelyingParty>

An attribute definition based on your example:
(to release the mail attribute as "arcgis_mail")

    <resolver:AttributeDefinition xsi:type="ad:Simple"
            id="mail" sourceAttributeID="mail">
        <resolver:Dependency ref="UH_LDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" activationConditionRef="singleValueMailSPs" name="arcgis_mail" />

A test attribute filter policy:

    <afp:AttributeFilterPolicy id="ArcGIS">
        <afp:PolicyRequirementRule xsi:type="afp:Requester"
                value="https://arcgis" />
        <afp:AttributeRule attributeID="mail">
            <afp:PermitValueRule xsi:type="afp:ANY" />
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="givenName">
            <afp:PermitValueRule xsi:type="afp:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

But when I try a resolver test, it appears to release the attribute as "mail" and not "arcgis_mail"?

$ curl -k 'https://idp/idp/profile/admin/resolvertest?requester=https://arcgis&principal=baron'

{
"requester": "https://arcgis",
"principal": "baron",
"attributes": [


  {
    "name": "mail",
    "values": [
              "StringAttributeValue{value=baron at hawaii.edu}"          ]
  },

  {
    "name": "givenName",
    "values": [
              "StringAttributeValue{value=Baron}"          ]
  }

]
}

I don't see any indication in the logs that it's invoking the singleValueMailSPs predicate
or references to arcgis_mail.

On Mon, Jun 18, 2018 at 02:50:26PM -0700, Greg Haverkamp wrote:
>>
>> is there a way to remap a defined attribute's name (id) in an attribute
>> filter policy, or conditionally specify its source attribute in an
>> attribute definition based on the requesting entityID in the attribute
>> resolver? How can we release our single-valued uhEmail attribute to this
>> SP as 'mail' without disrupting our existing definition or release of
>> 'mail' for other SPs already in use? What's the recommended way to handle
>> this?
>
>
>I haven't decided if it's better or worse, but I've lately started using
>activation conditions for these requests.  (Historically, I just created
>new attributes.)
>
>https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions
>
>We just go ahead and release by ID, so the poorly implemented SP's get our
>other attributes, too.  I gather you could script that out in an Attribute
>Filter Policy if you wanted, but that seems pretty messy.
>
>But in our email case:
>  <resolver:AttributeDefinition xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>id="email" xsi:type="Simple" sourceAttributeID="mail">
>    <resolver:Dependency ref="myLDAP"/>
>    <resolver:AttributeEncoder
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML1String"
>name="urn:mace:dir:attribute-def:mail"/>
>    <resolver:AttributeEncoder
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML2String"
>name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail"/>
>    <resolver:AttributeEncoder
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML2String"
>name="email_address" friendlyName="email_address"
>activationConditionRef="CventComPredicate"/>
>  </resolver:AttributeDefinition>
>
>Cvent just gets urn:oid:0.9.2342.19200300.100.1.3 and email_address (and a
>handful of others I grumbled about for a bit.  Cvent was one of the more
>frustrating integrations I've done in a while.)
>
>Greg
>
>
>
>On Mon, Jun 18, 2018 at 2:26 PM Baron Fujimoto <baron at hawaii.edu> wrote:
>
>> We are working with an SP (ArcGIS) who in unable to properly handle 'mail'
>> as a potentially multivalued attibute. Normally we would offer an
>> alternate attribute we have defined with id=uhEmail which we guarantee to
>> to be single-valued and encode with the same OID as the sandard mail
>> attribute where this is an issue. However, this SP also insists that this
>> attribute they require be named 'mail'.
>>
>> Is there a way to remap a defined attribute's name (id) in an attribute
>> filter policy, or conditionally specify its source attribute in an
>> attribute definition based on the requesting entityID in the attribute
>> resolver? How can we release our single-valued uhEmail attribute to this
>> SP as 'mail' without disrupting our existing definition or release of
>> 'mail' for other SPs already in use? What's the recommended way to handle
>> this?

-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum