Shibboleth Developers

[Jim Fox <>]

> But I have to admit that the stored approach makes me nervous since it means 
> that a potentially really large database (number_of_users * 
> number_of_SPs_that_want_tgtids) has to have fast enough response not to
> slow down the attribute delivery process and has to be available to all
> AA instances.  It would be hard to twiddle with (say bulk 
> imports/exports/mods for whatever reasons) since it would be used, and 
> potentially modified, on every authentication.  So I think the calculated 
> approach is more robust, even though somewhat less flexible.  A really nice 
> implementation might permit choosing between these on a per-provider basis.

Not "somewhat less flexible", but "absolutely inflexible" - exactly
the same algorithm, exactly the same data sources, for ever.  Do we
know that the java implementation of SHA will never again change,
as it has before (from SHA to SHA1)?  Even the smallest 'improvement'
to the SHA computation would produce completely inconsistent targeted
ids.  As for shibboleth, its track record is one 'improvement'
to the targeted id per each version change (e.g. 1.1 to 1.2) thusfar.
Is it conceivable that this still immature system, as yet not widely
installed, and tracking moving standards, will never again change
its mind regarding the targeted id?  I think flexibility is, at this
stage of the game, a requirement in itself.

As to the additional overhead of the targeted id database, it seems 
to me an inescapable consequence of a complex system.   If load
on the database becomes a problem, it will not be too difficult to
put a read-only copy on each AA, with the master elsewhere.

Stored targeted ids are admittedly a complication, but computed
values lead to much more serious problems.


Jim