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 1:27 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 6/8/15, 4:09 PM, "users on behalf of Jeffrey Crawford" <
> users-bounces at shibboleth.net on behalf of jeffreyc at ucsc.edu> wrote:
>
> >My goal is to use entity attributes to determine which attributes are
> released. For my locally managed metadata I just add the EntityAttributes
> to our copy of the metadata.
>
> Right, but what I need to know is *what* is broken.
>
> The filter is not broken that I can see. So what is? What is it that is
> supposed to be triggering on what you're adding that isn't triggering?
>
​I think the <MetadataFilter xsi:type="EntityAttributes">​

​ may be broken​

>
> The consent engine does not care about EntityAttributes, so that statement
> made no sense to me unless what you meant is that you're trying to create a
> RelyingParty override to override a ProfileConfiguration bean to turn on
> the consent flow.
>
​correct I just meant that I was using the consent page to see if my rules
are working correctly or not​.

>
> >For incommon I'm trying to use the metadata filter as described to
> "virtually" add these same attributes so they trigger the attribute filter
> rules based on the entityID's (This is only done to entities that don't
> request attributes) Each attribute value will trigger a particular filter
> rule.
>
> Ok, then that's not the consent engine at all, that's the filter engine.
> So maybe the EntityAttribute-based filter rule is broken.
>
> >That way sp1 would have attr-1 attr-2 attr-3 and attr-4 be released,
> where sp2 only gets attr-2 and attr-4. However it behaves as though only
> the first match wins, the others don't have attributes
> > added that then match to attribute filters.
>
> You have this backwards, that's what I'm telling you. The attributes *are*
> added. The bug is not there, it's at the other end.
>
​Correct attributes are added as long as the ​<Attribute Name="xxx" doesn't
already exist

>
> I don't know how you would be able to conclude that the attributes are or
> are not added, other than by trying to use them. What I'm saying is, the
> bug is in what's using them, and so that requires that I know what's using
> them to pin down the location of the mistake.
>
> I actually looked at the RP override conditional logic and I'm actually
> fairly sure it does look at every Attribute it finds, not just the first
> one. So I would be interested to see if you can create such an override in
> relying-party.xml based on one of the tags that you don't think is being
> added. I think it will work

​The behaviour I'm not expecting is in the MetadataFilter EntityAttributes
type functionality. The attribute filter is working fine as is the relying
party. I'm obviously not explaining this well so I'm going to try and
explain this another way. If the following exists in the metadata whether
it's really in the metadata or added from a previous MetadataFilter
EntityAtrributes rule:

    <mdattr:EntityAttributes
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      <saml:Attribute Name="some-name"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>iWantAttributeA</saml:AttributeValue>
        <saml:AttributeValue>iWantAttributeB</saml:AttributeValue>
      </saml:Attribute>
    </mdattr:EntityAttributes>

and I add the following to the metadata-providers.xml

        <MetadataFilter xsi:type="EntityAttributes">
            <saml:Attribute Name="some-name">
                <saml:AttributeValue>iWantAttributeC</saml:AttributeValue>
            </saml:Attribute>
            <Entity>https://somesp.example.edu/shibboleth</Entity>
        </MetadataFilter>

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.


> I have not looked at the filter plugin yet.
>
> -- 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/1b7a426a/attachment.html>