Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It should be noted that there's clearly (at this point unknown) memory overhead for installing a Meter per service and user, and the intention is that this be enabled for only services known to be offending frequently enough to make that worth it. To help with this, the Predicate class is configured with a map of SP entityIDs/names that should be monitored and a map value that names the Meter. This provides a "safe" label for the Meter instead of the entityID (and even allows for mapping multiple services to one Meter, though that seems unlikely to make sense). Of course the "warning" flow itself has to be enabled for the services to monitor as well, though enabling it for unmapped services will do nothing.

In addition, the example demonstrates a second optimization, adding a precursor condition that only applies the loop detection logic for SSO-based requests (i.e., requests that report out as having not prompted the user for authentication, since loops inherently are an SSO-based phenomenon). The theory is that this will limit the creation of timer metrics for any users that are just “one and done” most of the time, which tends to be a higher proportion of usage than one might expect.

Configuring this is quite simple (note per the WarningInterceptConfiguration topic, you need to enable the relevant Module first). In the example below, a single service is monitored, and a view template must be created in views/intercept/loop-detected.vm to render. The example also applies a warning "duration" of zero, which is a signal that the warning should always appear when the condition is met rather than only at some lower interval. The trigger is set by the threshold property, which defaults to 20 requests in a minute.

...

Expand
titleconf/intercept/warning-intercept-config.xml
Code Block
languagexml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:c="http://www.springframework.org/schema/c"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
                           
       default-init-method="initialize"
       default-destroy-method="destroy">

    <!--
    The map keys are the names of view templates to render if the condition evaluates to true.
    
    The values are of type Pair<Predicate<ProfileRequestContext>,Duration>. The condition determines whether
    the warning is displayed, and the duration is the interval between warnings.
    -->
    <util:map id="shibboleth.warning.ConditionMap">
        <entry key="loop-detected">
            <bean parent="shibboleth.Pair">
                <constructor-arg index="0">
                    <bean classparent="netshibboleth.shibboleth.idp.profile.logic.LoopDetectionPredicateConditions.AND" c:_0-ref="custom.OnlySSO">
                        <constructor-arg index="1">
                            <bean parent="shibboleth.Conditions.LoopDetection" p:threshold="20">
                                <property name="relyingPartyMap">
                                    <map>
                                        <entry key="https://sp.example.org/shibboleth" value="example" />
                                    </map>
                                </property>
                                <property name="usernameLookupStrategy">
                                <bean parent="shibboleth.Functions.Compose"
                                    c:g-ref="shibboleth.PrincipalNameLookup.Subject"
                                    c:f-ref="shibboleth.ChildLookup.SubjectContext" />
                                </property>
                            </bean>
                        </constructor-arg>
                    </bean>
                </constructor-arg>
                <constructor-arg index="1">
                    <bean class="java.time.Duration" factory-method="parse" c:_0="PT0S" />
                </constructor-arg>
            </bean>
        </entry>
    </util:map>

    <!-- This adapts an existing function that signals whether SSO applied, and adapts it into a Predicate. -->
    <bean id="custom.OnlySSO" class="net.shibboleth.shared.logic.PredicateSupport" factory-method="fromFunction" c:_1="false">
        <constructor-arg index="0">
            <bean parent="shibboleth.Functions.Compose">
                <constructor-arg name="g">
                    <bean class="net.shibboleth.idp.authn.context.navigate.PreviousResultLookupFunction" />
                </constructor-arg>
                <constructor-arg name="f">
                    <ref bean="shibboleth.ChildLookup.AuthenticationContext" />
                </constructor-arg>
            </bean>
        </constructor-arg>
    </bean>
</beans>

You may also wish to suppress the potentially large number of Meters from appearing via "standard" access to the full set of metrics, which can be done quickly by adding to conf/logback.xml:

...