Shibboleth Developers

[Von Welch <>]

Ok, I understand. Don't think I've ever heard that explicitly said  
before.

Von



On Oct 7, 2005, at 9:03 AM, Scott Cantor wrote:

> > My issue with this approach, if I understand the mechanics correctly,
> > and this is purely an issue with today's implementations - is that
> > the Shib AA demuxes on the Format attribute to call the appropriate
> > namemapper plugin. Since the encrypted handle approach shares with
> > the default Shib Handle, in practice this means a Shib IdP can do one
> > or the other. Meaning if we go this route, folks have to use a non-
> > default IdP configuration (encrypted vs regular handles).
>
> Nobody uses the memory implementation today if they're serious  
> about the
> software. It's not usable in a cluster, and this is a service that  
> has to be
> reliable. Chad's extension is a possible alternative, but even then  
> I think
> it's a replacement/extension for the in-memory mapper, though I  
> could be
> wrong about that.
>
> So there's "default" and there's "useful in anything but a pilot".
>
>
> > Now I understand from a technology perspective, it should all just
> > work, but I'm concerned from a deployment perspective that if we tell
> > folks, "you can use our stuff, you just have to change how your IdP
> > does handles for all clients and SPs" they are very likely to go
> > "yeah, right" and even if they do take this path, they end up in a
> > murky backwoods of the community since it's not the Shibboleth  
> > default.
>
> It is the only practical version used in Shibboleth today. It's not  
> the
> default only because it requires generating a key.
>
> -- Scott