alternate attribute names

Mon Jun 25 16:22:21 EDT 2018

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180625/555c3168/attachment.html>