alternate attribute names

[Baron Fujimoto]

Doh! Well, that's embarrassing. Fixed typo, works now. Hope it works out with the vendor next. Mahalo!

On Mon, Jun 25, 2018 at 01:22:21PM -0700, Greg Haverkamp wrote:
>I think it's a typo:
> <RelyingParty id="https://arcgis"
>vs
><bean id="singleValueMailSPs" parent="shibboleth.Conditions.RelyingPartyId">
> ...
>                <value>https://arcggis</value>
>
>Greg
>
>On Fri, Jun 22, 2018 at 9:58 PM Baron Fujimoto <baron at hawaii.edu> wrote:
>
>> 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
>> --
>> 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
>>

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


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