Limiting persistentId resolving

[GAMBINI Gilian]

Hello,

Thank you all for precious informations and ideas.
Yesterday, i try FailoverDataConnector attribute and its work perfectly :-) I like this method because it's simple and dont need lot of custom configuration, thank again.

I cant know which RP need eduPersonTargetedId, IdP use external metadatas. I agree, if we can list RPs that need eduPersonTargetId, using relyingPartys attribute is the better method.
Peter, i release this attribute with filter : <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> but resolving occur before filtering :( 

Scott, how can i determine which generation of persistentId i using ? In saml-nameid.properties, on our production environnement, the idp.persistentId.computed attribute is uncommented, i dont know why.
Move to computedId seems be a good idea, i will ask to our security team if it's ok. IdPs is connecting to a redondant mutualised database (3 maria nodes with galera replication and loadbalanced with HAproxy) but cant be 100% available. 

Have a nice day, Gilian.

-----Message d'origine-----
De : users <users-bounces at shibboleth.net> De la part de Rod Widdowson
Envoyé : vendredi 9 août 2019 15:01
À : 'Shib Users' <users at shibboleth.net>
Objet : RE: Limiting persistentId resolving

> I would like to limit eduPersonTargetedId resolving based on AttributeConsumingService of the current relying party. 

That should be OK, but beware that a lot of people have recently been re-discovering that you do *not* have access to any resolved attributes when  evaluating conditions in the context of attribute resolution: it's "too soon".  

We are aware of this issue and are looking at ways to make life easier in V4.

> I try to access requestedAttribute list with a ActivationCondition. 
> This condition is call in activationConditionRef property on 
> eduPersonTargetedId's AttributeDefinition and storeId DataConnector in attribute-resolver.xml.

requestedAttributes is rarely populated and it being empty means "all"..

My suggestions of things to try are
 
1) (If relevant) Make all dependencies of your StoredIDDataConnector are protected by same the activation condition.  Dependencies and activation conditions do not interact - a dependency is resolved even if the resolver which depends on it is turned off by an activation condition

2) Make your activation condition just RP dependant (if that makes sense)

3) Add a failover static (or scripted) connector.:
3a) If producing no EpTID under the "no Database" circumstances is "good enough" fallback to a Static data connector which resolves nothing...
3b)  If you really need the resolution to fail (rather than silently produce no EpTID) try a scripted connector.  This would have access to all the dependencies and return either nothing (which should be like saying "FALSE"/I don't need this in the
activationCondition) or throw an exception if it really has to fail.



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net