IdP attribute filter strategy

[Jeffrey Crawford]

Jeffrey <jeffreyc at ucsc.edu>

Both pilots and IT professionals require training and currency before
charging into clouds!
---------------------------------------

On Mon, Jun 8, 2015 at 2:21 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 6/8/15, 4:59 PM, "users on behalf of Jeffrey Crawford" <
> users-bounces at shibboleth.net on behalf of jeffreyc at ucsc.edu> wrote:
>
> >I think the <MetadataFilter xsi:type="EntityAttributes">​
> >
> >​ may be broken​
>
> It's not broken. Trust me, it's not. You have this backwards. You're
> ascribing bugs in the code that is *consuming* what you're creating to the
> code that's creating it. The creation happens, the consuming code is not
> handling multiple copies of the Attribute. Some of the code does and some
> of it doesn't. The AttributeFilter code doesn't, which is the bug you're
> hitting.​

​Yes, you would know this better than me​

>
> >​Correct attributes are added as long as the ​<Attribute Name="xxx"
> doesn't already exist
>
> No. They are added regardless. There is no way for you to tell that
> though, because nothing would show it either way. You're observing a bug
> and then assuming the cause, but the cause is something else, that's all.
>
> >​The behaviour I'm not expecting is in the MetadataFilter
> EntityAttributes type functionality.
>
> No, it's in the EntityAttribute-based AttributeFilter policy rules. That's
> where the bug is.
>
> >The attribute filter is working fine as is the relying party.
>
> No, it's not. The filter rule will work as long as the AttributeValues are
> all in one Attribute but not if they're separate. That doesn't mean the
> MetadataFilter isn't adding things, it means it's adding them in a way that
> triggers a bug later.
>
> >Then the metadata filter doesn't work (I verify by knowing my
> attribute-filter.xml works via other means and using the consent page to
> see if I'm trying to release AttributeC), however if the metadata did not
> contain <saml:Attribute Name="some-name"
> >​to begin with, then the metadata filter does add the attribute because I
> can see it being released in the consent page. I'm just using entity
> attributes to define which saml attributes I want to release.
>
> You are incorrect about the attribute filter working. It does not work.
> That's the bug. If you want to observe that yourself, just forget the
> metadata filter for now, add the EntityAttribute extension content directly
> into a metadata file, but split the AttributeValues across two duplicate
> Attributes. That's the same thing the MetadataFilter is producing now, and
> it will trigger the same bug. Your rule acting on the second value won't
> fire.
>

​I'll leave you with this. This is what I've been doing with our locally
managed metadata. This does work as I expect when setting up some basic
attributes commonName, givenName, and surname
---------------------------------------------------
attribute-filter.xml
    <afp:AttributeFilterPolicy
      id="commonName">

        <afp:PolicyRequirementRule
          xsi:type="saml:EntityAttributeExactMatch"
         attributeName="urn:mace:ucsc.edu:metadata:attr:profile"
         attributeValue="urn:mace:ucsc.edu:
metadata:attr:profile:filter:common-name"/>

        <afp:AttributeRule
          attributeID="commonName">
            <afp:PermitValueRule
              xsi:type="basic:ANY"/>
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

    <afp:AttributeFilterPolicy
      id="surname">

        <afp:PolicyRequirementRule
          xsi:type="saml:EntityAttributeExactMatch"
         attributeName="urn:mace:ucsc.edu:metadata:attr:profile"
         attributeValue="urn:mace:ucsc.edu:
metadata:attr:profile:filter:surname"/>

        <afp:AttributeRule
          attributeID="surname">
            <afp:PermitValueRule
              xsi:type="basic:ANY"/>
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

    <afp:AttributeFilterPolicy
      id="givenName">

        <afp:PolicyRequirementRule
          xsi:type="saml:EntityAttributeExactMatch"
         attributeName="urn:mace:ucsc.edu:metadata:attr:profile"
         attributeValue="urn:mace:ucsc.edu:
metadata:attr:profile:filter:given-name"/>

        <afp:AttributeRule
          attributeID="givenName">
            <afp:PermitValueRule
              xsi:type="basic:ANY"/>
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

---------------------------------------------------------------------
local metadata:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_6adb70bdbbf7e14ab9d9231e70b7afa4cdd969d5" entityID="
https://idm-test-sp.ucsc.edu/shibboleth">​
...
  <md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport"
                 xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
                 xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi">
...
    <mdrpi:RegistrationInfo registrationAuthority="http://ucsc.edu"/>
    <mdattr:EntityAttributes
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      <saml:Attribute Name="urn:mace:ucsc.edu:metadata:attr:profile"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>urn:mace:ucsc.edu:
metadata:attr:profile:filter:common-name</saml:AttributeValue>
        <saml:AttributeValue>urn:mace:ucsc.edu:
metadata:attr:profile:filter:given-name</saml:AttributeValue>
        <saml:AttributeValue>urn:mace:ucsc.edu:
metadata:attr:profile:filter:surname</saml:AttributeValue>
      </saml:Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
...
</md:EntityDescriptor>


> -- Scott
>
> --
> 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/20150608/4c961845/attachment.html>