StoredID/persistentID only when used?

[Simon Lundström]

On Fri, 2016-09-09 at 14:25:05 +0000, Cantor, Scott wrote:
> […]
> So, in looking at what you're saying here, I think your problem is that you're using the resolver, which is deprecated for this use case. If you don't use the resolver to produce the persistentID, you won't have this issue. The IdP only runs the generators if it needs to, which is the behavior you want, essentially using the IdP to decide when this is needed.

Thank you Scott for the in depth description of "don't do that!" ; P

Since ~90% of the SPs in the persistent ID DB was ours and we don't use
eduPersonTargetedID (except on one SP; to be able to test that it works
; ) we decided to adopt a regex blacklist and whitelist list to solve
the problem.

We configured our DataConnector in attribute-resolver.xml for StoredId
with an activationConditionRef just as explained in the wiki[1].

Then we added our activition condition to global.xml:
<!-- If either of these are true release the eduPersonTargetedID attribute -->
<bean id="ReleaseEPTID" parent="shibboleth.Conditions.OR">
  <constructor-arg>
    <list>
      <bean parent="shibboleth.Conditions.RelyingPartyId">
        <constructor-arg>
          <!-- A whitelist of entityIDs to release ePTID to -->
          <list>
            <value>https://sp-test.it.su.se/Shibboleth.sso</value>
          </list>
        </constructor-arg>
      </bean>
      <bean parent="shibboleth.Conditions.NOT">
        <constructor-arg>
          <bean parent="shibboleth.Conditions.RelyingPartyId">
            <constructor-arg>
              <!-- Never release ePTID to su.se SPs except the whitelist above -->
              <bean class="com.google.common.base.Predicates" factory-method="containsPattern"
                c:pattern="^https://(.+)\.su\.se/" />
            </constructor-arg>
          </bean>
        </constructor-arg>
      </bean>
    </list>
  </constructor-arg>
</bean>


Here are two CPU graphs on the DB, monthly:
<https://stockholmuniversity.box.com/shared/static/tjrg208o6wbatpjr4mzhmrlppv763hxm.png>
and weekly:
<https://stockholmuniversity.box.com/shared/static/dwn7napuz89jrkm4o3l7nej2grn4emwv.png>

You can clearly see that the students arrived on the 29th. See how the
top is flat on 29th and 30th? That's because it was at 100% for a while.
We gave it doubled CPUs and RAM after that hence 5th and 6th is so much
higher.

Oh and you can see that I made our above change yesterday. The DB does
nothing now = )

Thanks again Scott!

BR,
- Simon

1, <https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions#ActivationConditions-AttachingConditions>