The ClusteredSingleSignOn valve's reauthenticate method should bind the Principal returned from the realm to the sso entry.

Without this we see a problem in the following use case:

1) User has several web apps, only one of which has an authenticator configured. The other apps have protected resources and use a custom error page to redirect to that app if Tomcat issues a 403.
2) This setup counts on the SSO valve binding a Principal to the request – the presence of this Principal allows the other apps to have secured resources without the need for configuring an authenticator.
3) This works fine on a single node.
4) In a cluster, the Principal is not part of the replicated SSO entry, as it is not serializable. So, an SSO entry on another node will have no associated Principal.
5) SSO on the other node still works for any app that has an authenticator, as the SSO entry's cached username and password can be used to reauthenticate the user.
6) However, since the Principal is not cached, access to protected resources in the apps without a configured authenticator cannot be granted.

Also, since the Principal is not cached, even in more conventional setups where each app has an authenticator, the effect of not caching the Principal is as if "requireReauthentication" were set to true – each request needs to go the the realm.