Shibboleth Developers

[Chad La Joie <>]

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.

Correct, the HA-Shib extension offers replacements for the Name and 
Artifact mapper functions.  It stores it's information in-memory but 
replicates states across cluster nodes (so all the in-memory state on 
all the nodes is synched).

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124