alternate attribute names

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

alternate attribute names

Baron Fujimoto
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 <[hidden email]> :: 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Klingenstein, Nate

Baron,


All the SAML names on the wire are totally independent from those used internally by the IdP.  Maybe you could try following your traditional strategy and be sure to set friendlyName="mail" (or whatever else they want) on the relevant attribute encoder.


Take care,

Nate.


From: users <[hidden email]> on behalf of Baron Fujimoto <[hidden email]>
Sent: Monday, June 18, 2018 2:25:10 PM
To: Shib Users
Subject: alternate attribute names
 
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 <[hidden email]> :: 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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Greg Haverkamp
In reply to this post by Baron Fujimoto
s 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.)


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 <[hidden email]> 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 <[hidden email]> :: 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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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=[hidden email]}"          ]
  },

  {
    "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 <[hidden email]> 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 <[hidden email]> :: 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Greg Haverkamp
Because the condition is on the SAML2 encoder, you’ll need to use —saml2 on aacli.  (And, of course, you’ll want it eventually on your single-valued attribute.)

Greg

On Fri, Jun 22, 2018 at 9:58 PM Baron Fujimoto <[hidden email]> 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=[hidden email]}"          ]
  },

  {
    "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 <[hidden email]> 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 <[hidden email]> :: 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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Baron Fujimoto
Ahh, thanks for that saml2 parameter tip.

However, output now looks like

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="_1d8848884cf6b33ea0cd0dc9ba95232b"
    IssueInstant="2018-06-25T19:57:32.053Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml2:Issuer>https://idp-test.its.hawaii.edu/idp/shibboleth</saml2:Issuer>
    <saml2:AttributeStatement>
        <saml2:Attribute FriendlyName="mail"
            Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">[hidden email]</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute FriendlyName="givenName"
            Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Baron</saml2:AttributeValue>
        </saml2:Attribute>
    </saml2:AttributeStatement>
</saml2:Assertion>

It still does not seem to use the test name "arcgis_mail" as defined in my attribute definition
which should mach the relying party in the activation condition list?

I neglected earlier to provide the activation condition bean I defined:

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


On Fri, Jun 22, 2018 at 11:53:38PM -0700, Greg Haverkamp wrote:

>Because the condition is on the SAML2 encoder, you’ll need to use —saml2 on
>aacli.  (And, of course, you’ll want it eventually on your single-valued
>attribute.)
>
>Greg
>
>On Fri, Jun 22, 2018 at 9:58 PM Baron Fujimoto <[hidden email]> 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=[hidden email]}"          ]
>>   },
>>
>>   {
>>     "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 <[hidden email]> 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 <[hidden email]> :: 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
>> [hidden email]
>>

>--
>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>To unsubscribe from this list send an email to [hidden email]


--
Baron Fujimoto <[hidden email]> :: 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Greg Haverkamp
In reply to this post by Baron Fujimoto
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 <[hidden email]> 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=[hidden email]}"          ]
  },

  {
    "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 <[hidden email]> 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 <[hidden email]> :: 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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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=[hidden email]}"          ]
>>   },
>>
>>   {
>>     "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 <[hidden email]> 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 <[hidden email]> :: 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
>> [hidden email]
>>

>--
>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>To unsubscribe from this list send an email to [hidden email]


--
Baron Fujimoto <[hidden email]> :: 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Marvin Addison
In reply to this post by Greg Haverkamp
On Mon, Jun 18, 2018 at 5:51 PM Greg Haverkamp <[hidden email]> wrote:
I haven't decided if it's better or worse, but I've lately started using activation conditions for these requests.

We've tried many solutions and I'm comfortable saying that activation conditions are the way to go for one-off attribute names. We're seeing an uptick in the number of integrations that require specific (and in many cases non-standard) attribute names, and activation conditions allow us to focus on these quirks by adding additional attribute encoders that are toggled with an activation condition as your example demonstrates. If you're doing consent or other flows that work on attribute sets, you'll appreciate the benefit of this approach even more.

Marvin at Virginia Tech


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

IAM David Bantz
I found this an interesting thread. I have several times followed exactly the tack suggested by Nate
(encode a specially constructed attribute with name and friendlyName to meet special requirements of an SP).
So it's interesting a little concerning to read Marvin's recommendation for what seems a more convoluted method
using activation conditions. Marvin or others, could you elaborate on why this is a superior approach?

Thank you!

David Bantz
UA OIT IAM

On Thu, Jun 28, 2018 at 10:43 AM, Marvin Addison <[hidden email]> wrote:
On Mon, Jun 18, 2018 at 5:51 PM Greg Haverkamp <[hidden email]> wrote:
I haven't decided if it's better or worse, but I've lately started using activation conditions for these requests.

We've tried many solutions and I'm comfortable saying that activation conditions are the way to go for one-off attribute names. We're seeing an uptick in the number of integrations that require specific (and in many cases non-standard) attribute names, and activation conditions allow us to focus on these quirks by adding additional attribute encoders that are toggled with an activation condition as your example demonstrates. If you're doing consent or other flows that work on attribute sets, you'll appreciate the benefit of this approach even more.

Marvin at Virginia Tech


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Greg Haverkamp
In reply to this post by Marvin Addison
On Thu, Jun 28, 2018 at 11:44 AM Marvin Addison <[hidden email]> wrote:
On Mon, Jun 18, 2018 at 5:51 PM Greg Haverkamp <[hidden email]> wrote:
I haven't decided if it's better or worse, but I've lately started using activation conditions for these requests.

We've tried many solutions and I'm comfortable saying that activation conditions are the way to go for one-off attribute names. We're seeing an uptick in the number of integrations that require specific (and in many cases non-standard) attribute names, and activation conditions allow us to focus on these quirks by adding additional attribute encoders that are toggled with an activation condition as your example demonstrates. If you're doing consent or other flows that work on attribute sets, you'll appreciate the benefit of this approach even more.

Well, I'll have to admit much of the reason that I questioned the value of them is because I apparently can't read.  I viewed the conditions as a "service", and I've been operating under the impression that any time I added a new predicate, I had to restart the IdP, because there was no reloadable service.  But just now, I re-read the ReloadableServices page, and realized that those beans get loaded by the services themselves, and so now I feel stupid.  (With local sessions, I can gracefully restart the IdP, but it takes a while, as I wait for the load balancer's sticky sessions to eventually drain everyone who's mid-login to switch.  And so I made the last user of an integrated application wait 2 or 3 days for me to restart...)
 
So, the only reason I saw a completely new attribute as a potentially better approach was because I could reload the service. 

Greg



Marvin at Virginia Tech

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: alternate attribute names

Cantor, Scott E.
In reply to this post by IAM David Bantz
> So it's interesting a little concerning to read Marvin's recommendation for
> what seems a more convoluted method using activation conditions. Marvin
> or others, could you elaborate on why this is a superior approach?

Just style, it depends what you'd rather do. I think logically keeping the internal names of the attributes consistent and just encoding them selectively is clearer. Having a filter rule say to release employeeNumber is cleaner to me than having a rule to release employeeNumberWorkaroundForSP.

YMMV, and I imagine the requirement for Spring syntax to define those activationConditions is enough to put plenty of people off it. I just think that's putting off the inevitable, if you want to run this software, you're going to learn Spring basics or eventually get rid of it as too much of a pain to get anything done.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Greg Haverkamp
In reply to this post by IAM David Bantz
On Thu, Jun 28, 2018 at 12:30 PM IAM David Bantz <[hidden email]> wrote:
I found this an interesting thread. I have several times followed exactly the tack suggested by Nate
(encode a specially constructed attribute with name and friendlyName to meet special requirements of an SP).
So it's interesting a little concerning to read Marvin's recommendation for what seems a more convoluted method
using activation conditions. Marvin or others, could you elaborate on why this is a superior approach?

We don't do consent, so I'm not sure where those wins are.  For me, the huge win is not having to worry about filtering.  Before I shifted to using the activation conditions, I'd create the entirely new attribute, with an entirely new attribute ID, and then I'd have to go write add to a filter policy to release that attribute.  But if some vendor comes along and wants uid released as an attribute named "username" instead of "urn:oid:0.9.2342.19200300.100.1.1", I can do that just in the resolver, in an existing attribute definition, without a bunch of copied boilerplate in two files.   

I have some idea bubbling around in my head based on what Martin wrote, but I probably shouldn't speculate too much.

Greg

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: alternate attribute names

Rod Widdowson
In reply to this post by Greg Haverkamp
> So, the only reason I saw a completely new attribute as a potentially better approach was because I could reload the service.

Stating the blindingly obvious for the archive (since you sussed this out by way of realizing the scoping) - Make sure that new Predicate beans are declared inserted at the service level (files referred to by lines services.xml) rather at the global level (in global.xml).  

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Baron Fujimoto
In reply to this post by Greg Haverkamp
On Thu, Jun 28, 2018 at 01:10:01PM -0700, Greg Haverkamp wrote:

>On Thu, Jun 28, 2018 at 12:30 PM IAM David Bantz <[hidden email]> wrote:
>
>> I found this an interesting thread. I have several times followed exactly
>> the tack suggested by Nate
>> (encode a specially constructed attribute with name and friendlyName to
>> meet special requirements of an SP).
>> So it's interesting a little concerning to read Marvin's recommendation
>> for what seems a more convoluted method
>> using activation conditions. Marvin or others, could you elaborate on why
>> this is a superior approach?
>>
>
>We don't do consent, so I'm not sure where those wins are.  For me, the
>huge win is not having to worry about filtering.  Before I shifted to using
>the activation conditions, I'd create the entirely new attribute, with an
>entirely new attribute ID, and then I'd have to go write add to a filter
>policy to release that attribute.  But if some vendor comes along and wants
>uid released as an attribute named "username" instead of
>"urn:oid:0.9.2342.19200300.100.1.1", I can do that just in the resolver, in
>an existing attribute definition, without a bunch of copied boilerplate in
>two files.

I've also learned from this thread, thanks. I can see benefits to having the alternate names defined with the activation condition. A minor(?) downside I see is that when I release the attribute in the attribute filter by its AttributeDefinition ID, it also releases all other alternate named versions of the attribute as well. Or am I missing some means to limit the released attribute to just the variant intended for that relying party?

--
Baron Fujimoto <[hidden email]> :: 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: alternate attribute names

Marvin Addison
In reply to this post by IAM David Bantz
On Thu, Jun 28, 2018 at 3:30 PM IAM David Bantz <[hidden email]> wrote:
Marvin or others, could you elaborate on why this is a superior approach?

Scott said it's a matter of style, and I suppose that's true to some extent, but the real driver for us is policy. I would characterize Virginia Tech as very conservative with data handling and as such we have a lot of policy around attribute release. Consent is one policy aspect, but approvals and documentation are equally if not more important. Since I'm not a bookkeeper I need as few policy enforcement points as possible, and minimizing the number of attributes and defining named bundles have been two strategies we've adopted to keep things simple. Our clients request a couple bundles, and we release them with signals in the metadata (entity attributes). That keeps my hands out of the configuration as much as possible. Yay!

I have learned to be very strict about attribute bundles, which precludes adding or subtracting from them in order to meet the unique requirements of poorly implemented SAML in some SPs. Our workaround is to add encoders to existing attribute definitions and enable/disable via activation conditions. That keeps our policy points invariant under the wonky demands of the integrations we get with what seems like increasing regularity.

Best,
Marvin


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]