LocalDynamic + MetadataFilters = possible bug?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
I ran into an issue that I was wondering if anyone else has seen this.

TLDR: Sometimes our high volume services are not getting any attributes released when they should be. We created a static filter policy for the only high volume service we've seen the problem for and that has resolved the user complaints, but we're not happy leaving it there.



We originally thought maybe it was a problem without database during sync jobs. But we observed the sync process in close detail and found nothing that would explain a lack of attributes in the response.

So we started looking at the Metadata providers, and we think there may be a problem with using MetadataFilters the way we are.

Here's the config context.

We load services with LocalDynamicMetadataProvider and MetadataFilters, like this:

    <MetadataProvider id="default " xsi:type="LocalDynamicMetadataProvider" sourceDirectory="%{idp.home}/metadata/eg/default"
        failFastInitialization="false"
        refreshDelayFactor=".75"
        minCacheDuration="PT10M"
        maxCacheDuration="PT1H"
        maxIdleEntityData="PT1H"
        removeIdleEntityData="true"
        cleanupTaskInterval="PT30M">
        <MetadataFilter xsi:type="EntityAttributes">
            <saml:Attribute Name="urn:mace:upenn.edu:blah:blah:blah:attribute:name">
                <saml:AttributeValue>urn:mace:upenn.edu:blah:blah:Default</saml:AttributeValue>
            </saml:Attribute>
            <ConditionRef>shibboleth.Conditions.TRUE</ConditionRef>
        </MetadataFilter>
    </MetadataProvider>

And have an attribute filter like this:

    <AttributeFilterPolicy id="default_services">
        <PolicyRequirementRule xsi:type="OR">
            <Rule xsi:type="EntityAttributeExactMatch" attributeName=" urn:mace:upenn.edu:blah:blah:blah:attribute:name" attributeValue=" urn:mace:upenn.edu:blah:blah:Default"/>
        </PolicyRequirementRule>
        <AttributeRule attributeID="eduPersonPrincipalName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="eduPersonAffiliation">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="eduPersonScopedAffiliation">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="surname">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="givenName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="displayName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="email">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
    </AttributeFilterPolicy>

We stick our SP md files into the directories, and they get dynamically injected EntityAttributes on load, that control which attributes they get.


We use IdP v4.0.1 and never saw this problem in v3.4.6. I was wondering if the md localdynamic process is loading the md file and sending it to the IdP as loaded before the metadata filter finishes adding the dynamic value. I didn't think it was possible, and I'm sure it isn't. But I'm trying to understand the root cause.

Thanks,
Steve


--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 10/14/20, 12:03 PM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

>    We stick our SP md files into the directories, and they get dynamically injected EntityAttributes on load, that control
> which attributes they get.

I don't have any filters on my LocalDynamic case, but I do for MDQ, they're working fine.

>    We use IdP v4.0.1 and never saw this problem in v3.4.6. I was wondering if the md localdynamic process is loading the
> md file and sending it to the IdP as loaded before the metadata filter finishes adding the dynamic value. I didn't think it
> was possible, and I'm sure it isn't. But I'm trying to understand the root cause.

It's not. Check your log for errors at startup and when the filter runs for that SP, you might just be hitting the XML namespace bug that crops up with some filter configs. But that would be all the time, not just per-transaction.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
I agree that all of my LocalDynamic filters are also working fine, 99.99% of the time. This single service out of thousands has been the lone problem.


Regarding checking my logs, the IdP has no errors during runtime or startup. We inspected logs all around the time we would see the error and found nothing. The sp metadata file in question has been unchanged since April 2019.

The reason it's odd is that the errors were so infrequent that we had to setup an alert to watch for audit log lines that were missing attributes for this specific SP, and it was happening for about 30 minutes (sp metadata cache life, also resolved attributes cache life) sporadically every 3-4 weeks over 3-4 months, when nothing else about the config changed.

We used aacli for the specific users reporting problems to test during the 30 min error window to confirm that the IdP did resolve attributes for that user correctly in the error window. We originally believed it might be related to our database swapping in new synced data. Everything appeared to be unrelated so that's how we ended up at the possibility that the MetadataFilter was a problem.

Even my own stress testing on a sandbox idp to try to get the MetadataFilter to fail proved unsuccessful.

My own assessment of the problem might also be incorrect, but we have found nothing to explain how occasionally an SP will receive no attributes in the assertion.

I was curious if this was happening to anyone else.

- Steve
--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 10/14/20, 1:00 PM, "Mak, Steve" <[hidden email]> wrote:

>    I agree that all of my LocalDynamic filters are also working fine, 99.99% of the time. This single service out of
> thousands has been the lone problem.

I would be thinking duplicate metadata then, perhaps, from a different source.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
It's not duplicate metadata either. I've looked through every source found in the metadata providers file and no duplicates.

On 10/14/20, 13:10, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    On 10/14/20, 1:00 PM, "Mak, Steve" <[hidden email]> wrote:

    >    I agree that all of my LocalDynamic filters are also working fine, 99.99% of the time. This single service out of
    > thousands has been the lone problem.

    I would be thinking duplicate metadata then, perhaps, from a different source.

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

--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 10/15/20, 8:53 AM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

>    It's not duplicate metadata either. I've looked through every source found in the metadata providers file and no
> duplicates.

Unless it's consistently always unable to attach the tags I don't have any obvious suggestions. I could imagine bugs that would prevent the attachment because of something unexpected or untested in the XML but not something non-repeatable. That sort of problem would almost have to point to an attribute lookup issue.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
Is there documentation I can read that shows a deeper dive into the attribute resolution process?

I need a better understanding of the process order to rule processes out.

Is this the correct order?

md resolution starts > md filters applied > md resolution ends > md resolution cached > ...skip auth/c14n > (sp scoped) attribute resolution > attribute resolution cached > (sp scoped) attribute filtering > build SAML assertion/response

- Steve

On 10/15/20, 08:58, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    On 10/15/20, 8:53 AM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

    >    It's not duplicate metadata either. I've looked through every source found in the metadata providers file and no
    > duplicates.

    Unless it's consistently always unable to attach the tags I don't have any obvious suggestions. I could imagine bugs that would prevent the attachment because of something unexpected or untested in the XML but not something non-repeatable. That sort of problem would almost have to point to an attribute lookup issue.

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

--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 10/15/20, 11:05 AM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

>    md resolution starts > md filters applied > md resolution ends > md resolution cached > ...skip auth/c14n > (sp scoped) > attribute resolution > attribute resolution cached > (sp scoped) attribute filtering > build SAML assertion/response

I guess roughly. But attribute resolution has very complicated failure modes and many of the options to limit the affects of errors don't even work right, leaving static failovers about the only way to prevent even minor errors from suppressing everything.

It's extremely common for a configuration to react to even a single transitory issue by producing nothing for a request, and the connector "stay dead" period can keep on breaking things for subsequent requests until it goes back online.

If the status page really claims that nothing has ever failed, then that probably can be trusted, but there's no explanation for any of this outside that step. There's just no way the metadata could be the problem unless there's a duplicate.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
Is it possible for the MetadataProvider cleanupTaskInterval to kill cached md before the user finishes logging in?

On 10/15/20, 11:13, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    On 10/15/20, 11:05 AM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

    >    md resolution starts > md filters applied > md resolution ends > md resolution cached > ...skip auth/c14n > (sp scoped) > attribute resolution > attribute resolution cached > (sp scoped) attribute filtering > build SAML assertion/response

    I guess roughly. But attribute resolution has very complicated failure modes and many of the options to limit the affects of errors don't even work right, leaving static failovers about the only way to prevent even minor errors from suppressing everything.

    It's extremely common for a configuration to react to even a single transitory issue by producing nothing for a request, and the connector "stay dead" period can keep on breaking things for subsequent requests until it goes back online.

    If the status page really claims that nothing has ever failed, then that probably can be trusted, but there's no explanation for any of this outside that step. There's just no way the metadata could be the problem unless there's a duplicate.

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

--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 10/15/20, 11:26 AM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

>    Is it possible for the MetadataProvider cleanupTaskInterval to kill cached md before the user finishes logging in?

No. Java just keeps the reference to all of the objects around until they're gone. The lock is long released but swapping in new metadata won't affect a request that already fetched the old copy. Whenever all the old requests are done, nothing else references the old metadata and it's eligible to be collected.

That's what makes Java easy and C++ painful. The IdP can scope locks very easily around a swap of the entire service configuration because anything old is still around being referenced as long as it needs to be. The SP has to use formal read/write lock patterns to prevent service reloads from taking effect until no requests are active. The IdP doesn't have to care.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
Hey all,

I'm still seeing SP md reloads not picking up dynamic metadata filter entity attribute additions every now and then. And the result is complete lack of attributes because the filter rules then don't apply to the SP. The next time it reloads within the hour, the attributes come back, so it HAS to be related to this.

There's definitely something happening but nothing in the non-debug logs indicate a problem and we only see this in our production environment that is very high traffic.

The previous workaround for one SP we saw this with was to explicitly define an attribute filter policy for that SP that did not rely on the MetadataFilter. So far no reports of that SP missing attributes since. This leads me to believe SOMETHING is not working correctly with the MetadataFilter in Java.



LOG lines before the problem appears and before the problem goes away (exact match 45 minutes to an hour later):

2021-01-12 10:53:55,557 - INFO [org.opensaml.saml.metadata.resolver.filter.impl.EntityAttributesFilter:238] - Adding new EntityAttribute (entitygroup) to EntityDescriptor (redacted sp-entityID)
2021-01-12 10:53:55,557 - INFO [org.opensaml.saml.metadata.resolver.impl.AbstractDynamicMetadataResolver:1078] - Metadata Resolver LocalDynamicMetadataResolver md-1: Successfully loaded new EntityDescriptor with entityID 'redacted sp-entityID' from origin source



Config follows:

metadata-providers.xml (maxIdleEntityData and maxCacheDuration are the only non-default attributes)

    <MetadataProvider id="md-1" xsi:type="LocalDynamicMetadataProvider" sourceDirectory="%{idp.home}/metadata/eg/somelabel"
        failFastInitialization="false"
        refreshDelayFactor=".75"
        minCacheDuration="PT10M"
        maxCacheDuration="PT1H"
        maxIdleEntityData="PT1H"
        removeIdleEntityData="true"
        cleanupTaskInterval="PT30M">
        <MetadataFilter xsi:type="EntityAttributes">
            <saml:Attribute Name="entitygroup">
                <saml:AttributeValue>somelabel</saml:AttributeValue>
            </saml:Attribute>
            <ConditionRef>shibboleth.Conditions.TRUE</ConditionRef>
        </MetadataFilter>
    </MetadataProvider>


attribute-filter.xml

    <AttributeFilterPolicy id="afp_releaseToEntityLabel1">
        <PolicyRequirementRule xsi:type="OR">
            <Rule xsi:type="EntityAttributeExactMatch" attributeName="entitygroup" attributeValue="somelabel"/>
        </PolicyRequirementRule>
        <AttributeRule attributeID="eduPersonPrincipalName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="eduPersonAffiliation">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="eduPersonScopedAffiliation">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="surname">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="givenName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="displayName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
        <AttributeRule attributeID="email">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
    </AttributeFilterPolicy>

--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
I don't personally have any filters applied to LocalDynamic, I just put them in the metadata. So I guess I couldn't say there isn't a bug but given the layering it makes little sense for it to be specific to one metadata source, and I have tons of filters running against the InCommon MDQ service with no issues.

Perhaps Brent has some idea for what's special about LocalDynamic that might trigger something. You can file it, but I don't really expect much progress on it.

Does it seem to be specific to a particular SP?

-- 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: LocalDynamic + MetadataFilters = possible bug?

Mak, Steve
No. It's a variety of SPs.

We have about 1200 SPs in one metadata-provider group and I'm wondering if maybe there's some java memory issue.

On 1/12/21, 13:38, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    Does it seem to be specific to a particular SP?

--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 1/12/21, 2:07 PM, "users on behalf of Mak, Steve" <[hidden email] on behalf of [hidden email]> wrote:

>    We have about 1200 SPs in one metadata-provider group and I'm wondering if maybe there's some java memory issue.

The metrics and status page track heap usage.

That is far more than I have but if they're not really used at the same time it doesn't mean much. Memory exceptions don't always get reported but if it didn't work, the whole metadata instance would most likely not be loaded.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Brent Putman
In reply to this post by Cantor, Scott E.


On 1/12/21 1:38 PM, Cantor, Scott wrote:
I don't personally have any filters applied to LocalDynamic, I just put them in the metadata. So I guess I couldn't say there isn't a bug but given the layering it makes little sense for it to be specific to one metadata source, and I have tons of filters running against the InCommon MDQ service with no issues.

Perhaps Brent has some idea for what's special about LocalDynamic that might trigger something. You can file it, but I don't really expect much progress on it.

Sorry, took me a couple of days to get to this.

I think I may have found something suspicious.  It's about the EntityAttributes filter issue Scott filed in OSJ-321 and the cloning change/fix in OSJ-324.

In the AbstractDynamicMetadataResolver (super class for both LocalDynamic- and the MDQ one), when persistent caching is enabled we do clone the metadata document before filtering since the filters can mutate the DOM and we need to keep the original bytes around for the persistent cache:

    XMLObjectSupport.cloneXMLObject(input, CloneOutputOption.RootDOMInNewDocument);

Scott, you understood the OSJ-321 EntityAttributes issue and attribute subsystem interaction better than me.  Is this the same issue and/or could it be related?  This case seems weirder because I think Steve is saying it only happens some of the time.  But not sure if that's confirmed.

If it's the same fundamental root cause, then nominally this is already fixed for 4.1, due to the fix we applied in OSJ-324.

--Brent



--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 1/14/21, 5:45 PM, "users on behalf of Brent Putman" <[hidden email] on behalf of [hidden email]> wrote:

>    Scott, you understood the OSJ-321 EntityAttributes issue and attribute subsystem interaction better than me.  Is this the
> same issue and/or could it be related?  This case seems weirder because I think Steve is saying it only happens some of
> the time.  But not sure if that's confirmed.

I don't see how it could be related unless there's a clear warning or error in the log. The issue I hit was not subtle, it just wasn't obvious unless I looked in the log. Certainly it could be happening, but it wouldn't be silent about it. And it wouldn't be intermittent, it was always failing.

Mine was against a batch, so the log only noted it when the metadata was loaded, whereas this would happen at runtime when the filter runs.

However, I considered/assumed that the only likely cause of this was if the LocalDynamic plugin wasn't properly isolating the cached copies in some way between the layers. It seems like there must be a race condition somewhere.

-- 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: LocalDynamic + MetadataFilters = possible bug?

Brent Putman


On 1/14/21 6:00 PM, Cantor, Scott wrote:

I don't see how it could be related unless there's a clear warning or error in the log. The issue I hit was not subtle, it just wasn't obvious unless I looked in the log. Certainly it could be happening, but it wouldn't be silent about it. And it wouldn't be intermittent, it was always failing.


Yes, I would think so as well.  Although, it isn't clear from the config example whether the entity attributes are applied on all entities.  The example seems obfuscated with an "always true" predicate and dummy entity attribute value.  So maybe it is always happening on the metadata that the predicate matches, if the latter is selective.  Hopefully Steve can tell us.



Mine was against a batch, so the log only noted it when the metadata was loaded, whereas this would happen at runtime when the filter runs.


Yes, it would happen when the metadata is fetched the first time, and also later when it's fetched and updated.



However, I considered/assumed that the only likely cause of this was if the LocalDynamic plugin wasn't properly isolating the cached copies in some way between the layers. It seems like there must be a race condition somewhere.


I agree that intermittent usually implies race condition.  But off-hand I don't know how that could be happening here.  The dynamic metadata is fetched and processed under a write lock over the entity ID (of a read-write lock).  Read-only access is then governed by the corresponding read lock.  So no concurrent readers and writers over the same metadata.


--
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: LocalDynamic + MetadataFilters = possible bug?

Michael Grady


On Jan 14, 2021, at 5:11 PM, Brent Putman <[hidden email]> wrote:

Yes, I would think so as well.  Although, it isn't clear from the config example whether the entity attributes are applied on all entities.  The example seems obfuscated with an "always true" predicate and dummy entity attribute value.  So maybe it is always happening on the metadata that the predicate matches, if the latter is selective.  Hopefully Steve can tell us.

I can't speak for Steve, but having a filter on LocalDynamic that uses the "always true" predicate would not be that unusual. We are working with someone who has the exact use case, wanting to "tag" all entries that come our of a particular LocalDynamic directory. Just like one would do for the InCommon MDQ, in place of the old approach of using inEntityGroup when using the aggregate.

That's exactly what the LocalDynamic is replacing for this client, a local aggregate they maintained with lots of partner SP metadata.

So far, that "apply filter to all :LocalDynamic" is working ok, but the switch was just made, so time will tell.

--
Michael A. Grady
IAM Architect, Unicon, Inc.




--
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: LocalDynamic + MetadataFilters = possible bug?

Brent Putman


On 1/14/21 6:26 PM, Michael Grady wrote:


On Jan 14, 2021, at 5:11 PM, Brent Putman <[hidden email]> wrote:

Yes, I would think so as well.  Although, it isn't clear from the config example whether the entity attributes are applied on all entities.  The example seems obfuscated with an "always true" predicate and dummy entity attribute value.  So maybe it is always happening on the metadata that the predicate matches, if the latter is selective.  Hopefully Steve can tell us.

I can't speak for Steve, but having a filter on LocalDynamic that uses the "always true" predicate would not be that unusual.


Sorry, my wording was clumsy.  I didn't mean to say that "always true" wasn't common.  Merely that the example was clearly not the actual config due to the dummy attrib value, so just wanted to get confirmation on what the actual config looks like.  If it is "always true" then the mystery of the intermittent failure deepens...


--
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: LocalDynamic + MetadataFilters = possible bug?

Cantor, Scott E.
On 1/14/21, 6:32 PM, "users on behalf of Brent Putman" <[hidden email] on behalf of [hidden email]> wrote:

>    Sorry, my wording was clumsy.  I didn't mean to say that "always true" wasn't common.  Merely that the example was
> clearly not the actual config due to the dummy attrib value, so just wanted to get confirmation on what the actual config
> looks like.  If it is "always true" then the mystery of the intermittent failure deepens...

That's a possible direction to explore, maybe the condition is failing in some intermittent way, though it would have to be pretty oddly constructed to do that...

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