StoredID/persistentID only when used?

[John Morrison]

We here in Sweden (SWAMID) need to use ePTID for some services still.
Yes it's depreciated, but no-one seems to have a plan to use SAML
persistent ID as of yet!

I have an issue with CAS inside IdP 3.2 generating ePTID unnecessarily
with multiple URI locations. This causes the StoreID in the resolver to
generate a bucket load of entries. We use CAS on one of our biggest
portals here. The time for them to move to shib, hasn't really surfaced
so well with developers as of yet.


I have tried doing this condition and it works but still it generates
into the database.

Made a condition file, added it to services. Referenced it in the
resolver the condition wasn't met and not released.

2016-09-19 14:05:47,794 - DEBUG
[net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:372] -
Attribute Resolver 'ShibbolethAttributeResolver': Resolving dependencies
for 'eduPersonTargetedID'
2016-09-19 14:05:47,811 - DEBUG
[net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:388] -
Attribute Resolver 'ShibbolethAttributeResolver': Finished resolving
dependencies for 'eduPersonTargetedID'
2016-09-19 14:05:47,811 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractResolverPlugin:179] -
Resolver plugin 'eduPersonTargetedID': activation criteria not met,
nothing to do
2016-09-19 14:05:47,811 - DEBUG
[net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:270] -
Attribute Resolver 'ShibbolethAttributeResolver': Attribute definition
'eduPersonTargetedID' produced no attribute
2016-09-19 14:05:47,885 - DEBUG
[net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:415] -
Attribute Resolver 'ShibbolethAttributeResolver': Removing result of
attribute definition 'eduPersonTargetedID', it is null


GREAT!  but:


net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:720] -
Stored Id Store: Storing new persistent ID entry
2016-09-19 14:05:38,327 - DEBUG
[net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:720] -
Stored Id Store: Storing new persistent ID entry
2016-09-19 14:05:38,338 - INFO
[net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:495] -
Stored Id Store: Data source successfully verified
2016-09-19 14:05:47,795 - DEBUG
[net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:555] -
Stored Id Store: Obtaining persistent ID for source ID: johmo542
2016-09-19 14:05:47,797 - DEBUG
[net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:577] -
Stored Id Store: Getting active and/or last inactive persistent Id entry
2016-09-19 14:05:47,806 - DEBUG
[net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:599] -
Stored Id Store: Issuing new computed persistent ID
2016-09-19 14:05:47,806 - DEBUG
[net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:720] -
Stored Id Store: Storing new persistent ID entry
2016-09-19 14:05:47,810 - DEBUG
[net.shibboleth.idp.saml.nameid.impl.StoredPersistentIdGenerationStrategy:167] - Obtained persistent ID entry: PersistentIdEntry{persistentId:sBWOhqwCMrRgdKu9dNadLRsdqQ8=, localEntityId:MYIDP:URL, recipientEntityId:SOMESP_URL, sourceId:MYUID, principalName:MYUID, peerProvidedId:null, creationTime:2016-09-19 14:05:47.806, deactivationTime:null, }
2016-09-19 14:05:47,810 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractDataConnector:139] - Data
Connector 'StoredId': produced the following 1 attributes during
resolution [persistentId]
2016-09-19 14:05:47,811 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractDataConnector:143] - Data
Connector 'StoredId': Attribute 'persistentId': Values
'[StringAttributeValue{value=jatj4t0j05t90t0r9090rg0uas90dgsd0fgj0ajr9}]'
2016-09-19 14:05:47,811 - DEBUG
[net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:347] -
Attribute Resolver 'ShibbolethAttributeResolver': Data connector
'StoredId' resolved the following attributes: [persistentId]


Help,

John








On Tue, 2016-09-13 at 06:46 +0200, Simon Lundström wrote:
> 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>