Shibboleth Developers

["Cantor, Scott E." <>]

> Is it possible to use a fall back data source for attribute resolution 
> without
> the need to invest in expensive database clustering or development work
> requiring releasing the persistent ID from a clustered LDAP directory (we 
> did
> this on IdP 1.3)?

If you can't cluster the data source you'll need to explore alternative 
mechanisms for generating the values. You can't use fallbacks for this, it 
would cause state management issues when the main source recovered, and end 
up changing the values.

> If there is no default fall back mechanism, is it possible for the attribute
> resolver to detect a problem (SQL Exception) with the StoredID data
> connector, and switch over to the Computed ID data connector?

That would change the values any time the data source failed. If you don't 
have a reliable back-end, you should really be computing them to start with.

I believe Jim Fox has also frequently noted an approach that doesn't involve 
replicating, but can still store the values.

Please use -users for follow-up, this isn't a dev question.

-- Scott