IDP Cluster going forward (JDK 7)

[Manuel Haim]

Paul Hethmon wrote:
> I'm not seeing anything marked as a transient field, but if there were,
> then it would be up to that object to reconstitute the value when it's
> de-serialized from the DB in my mind. That's the whole purpose of
> transient.

Thanks Paul and Scott...

However, repopulating transient fields after de-serialization seems to  
be left as an exercise to the programmer.

This problem exists at least with the Kerberos login handler or the  
x509 login handler: After serialization and de-serialization, the  
transient information has gone and will not be recovered, thus the  
shared object is worthless. I also tend to remember that these plugins  
use a default javax.security.auth.kerberos.KerberosPrincipal or  
javax.security.auth.x500.X500Principal with some private transient  
fields which can only be set through a constructor. How would one set  
such a field within an already existing object? I think I need to dig  
deeper into the Java Reflection API there.

Another problem was with the default vt-ldap JAAS module that comes  
with Shibboleth: This returns a javax.security.auth.Subject containing  
a new Set<java.security.Principal> by default, some of which elements  
do not implement the interface "Serializable", thus serialization  
fails. One has to explicitly use setLdapPrincipal="false" within the  
JAAS configuration to prevent the principal set being populated, or  
write a custom login handler.

Within the Subject, you may also have the transient fields  
publicCredentials (if retainPublicCredentials="true" is set) and  
privateCredentials. These may be used within the attribute resolver,  
but are lost if the Subject has been serialized and de-serialized  
in-between.

Our Memcache plugin makes use of the Apache BeanUtils. Whenever a  
local object is synchronized with an global object from Memcache (and  
the global object is newer), I need to beancopy its values to the  
local object (in order to retain the current object reference which is  
already held by some other method of the current IdP instance). Of  
course, a dumb StorageService (e.g. keeping only Strings and being  
queried on every data change or retrieval) would solve that problem,  
but that's not the way how the current IdP 2.x utilizes the  
StorageService. (Instead, the whole Session object is usually  
retrieved only once on each HTTP request, and then heavily altered  
every now and then, without ever being put back.)

So long for transient fields and non-Serializable classes.

-Manuel