Hey Dirk,
I thing you have found a strange missing feature inside the cluster
implementation. Currently
all other realm MemoryRealm, DataSourceRealm,JNDIRealm, JAASRealm and
JDBCRealm create a GenericPrincipal that used inside the
DeltaRequest.setPrincipal method. The UserDatabaseRealm create a
o.a.c.users.MemoryUser principal. Very bad thing!! Integrate a spezial
handling for this is easy, but.... :-(
I have tested with MemoryRealm successfull with basic auth. Sorry, but
this means that at every request a message is replicated.
The session principal is set at every request. I don't like this
behaviour. Any ideas to change it are very welcomed!
Please open a bug report that we can work together at this auth topic
and documened it well at changelog.
Thanks for reporting this.
Peter
Peter Rossbach schrieb:
Hmm,
I have look inside source of DeltaRequest
public void setPrincipal(Principal p) {
int action = (p==null)?ACTION_REMOVE:ACTION_SET;
SerializablePrincipal sp = null;
if ( p != null ) {
sp =
SerializablePrincipal.createPrincipal((GenericPrincipal)p);
}
addAction(TYPE_PRINCIPAL,action,NAME_PRINCIPAL,sp);
}
....
public synchronized void execute(DeltaSession session, boolean
notifyListeners) {
...
Principal p = null;
if ( info.getAction() == ACTION_SET ) {
SerializablePrincipal sp =
(SerializablePrincipal)info.getValue();
p =
(Principal)sp.getPrincipal(session.getManager().getContainer().getRealm());
}
session.setPrincipal(p,false);
break;
}//case
....
....
and this look like that we explizit replicated the principal.
I will test you use case with the newest 5.5.x code base again and
describe
the results later.
peter
PS: SingleSignOn is currently not supported at the cluster
implementation :-(
Dirk de Kok schrieb:
hi all,
we are having a problem with our Tomcat 5.5.9 cluster. We run 2 Tomcat
instances on physically different machines. For security we use normal
container managed security, configured in the web.xml. Session
replication
works fine, and session id's are same across the two instances. We
only have
trouble with the authentication.
For instance, if you are logged in on instance1, if in case of error the
load balancer redirects subsequent request to instance2, you have to
login
again. Turning on Single Signon did not help.
Browsing through the Tomcat source code I noticed that very explicit the
security Principal is not saved in a serialized session. Has anybody
an idea
why this is not done? What way would we be able to let the security
information propagate throughout the cluster?
Configuration:
- OS: RH 4
- App server: Tomcat 5.5.9
- Session replication: in-memory, pooled
- Load balancing via hardware load balancer (Cisco) with sticky sessions
tia,
Dirk
- Lost Boys creates and delivers internet & mobile solutions -
Dirk de Kok | Java Specialist
Lost Boys B.V. | Joop Geesinkweg 209 | 1096 AV Amsterdam The
Netherlands |
Tel: +31 20 4604500 | Fax: +31 20 4604501 | [EMAIL PROTECTED] |
www.lostboys.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
