Shibboleth Developers

["Scott Cantor" <>]

> 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.

I think it should be noted that Shibboleth promises to maintain a stable (if
evolving) interface for plugins. That's it. There's nothing else it can or
should do. This attribute can be implemented in many ways, but it CANNOT be
stably implemented by saying "I'm going to use the code in the distribution
of each version that demonstrates how it might be done."

When you deploy it in some way, you have to take ownership of that plugin
and make it your own.

This isn't a big deal because it's quite easy to set up a production deploy
that lays local plugins into the build without complicating upgrades (I went
from 1.2 to 1.2.1 and it was painless and automatic).

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

I will say though that Bob's point is valid in terms of why there's no code
in cvs for this. We can't do it well enough without taking into account the
specific databases and approaches to replication that people are willing to
support (without massive overkill anyway). So whatever JDBC-based design we
stuck in cvs would just be the same as the current plugin, a starting point
to build on.

Advance warning that 2.0 is not gonna change that. We will have lots of
interfaces to handle the protocols that 2.0 allows, but very little "real"
implementation except to demonstrate how they work. Especially on the SP
side. I can tell you it's time to logout or that a username changed, but
it's the PHP/ASP/Java/Perl/etc app that has to follow through.

-- Scott