Shibboleth Developers

[André Cruz <>]

On 2007/05/31, at 02:23, Scott Cantor wrote:

> In your case, I'd be concerned about storing a programming object  
> in memory
> that would be shared between servers, seems like that's dependent  
> on having
> a very uniform set of servers. I don't know, maybe I'm not  
> following what
> you meant by a hashtable?

Sorry.. I was thinking in Perl. I can serialize something that  
resembles an STL map.

> Note that each component that uses a StorageService is given a  
> specific
> instance to use or build on. It's a manual sort of dependency  
> injection, not
> a single global instance. My point being that you could have two
> implementations of the API with different performance  
> characterstics and
> configure both at once. The Shibboleth configuration allows any  
> number to be
> instantiated and you can point the higher level objects at the one  
> you want
> them to use.

I looked at the shibboleth.xml.in config in the svn and found the  
SessionCache (lots of contexts with small size) and ReplayCache (one  
big context). Also I found the ArtifactMap which also seems to use a  
StorageService. What is the behavior of this particular cache? Are  
there any more caches I should me aware?

Also, from the ShibDevCPPSP and the commit logs of the rest of the  
repositories I can see that the single logout functionality is not  
even started yet so I guess it will not be present in the beta build  
released this week. In the wiki it is mentioned that strategies will  
be discussed in Chicago F2F but searching for "Chicago F2F" yields  
some interesting results, albeit not relevant to this discussion. :)

So... When can we expect this to be developed? I had to implement a  
cookie based solution here which is not really secure but it was  
supposed to be temporary.... :)

Best regards,
André