I understand this isn't your standard question, but I need to join our existing (custom) measures with the Tomcat security management so that we can get Tomcat to remember a Principal created by us so that it can be passed (via SSO) to another content in the same container.
ie user logs in to our application, we tell Tomcat about the user, user visits the other context and that context knows who the user is.
1. Setting the Principal on the Request The org.apache.catalina.connector.Request Class has a method to set the userPrincipal, but that is the method that should be used by the container to pass it to us, if we set the Principal there it would have no effect beyond that request. Anyhow, the Request is wrapped by the org.apache.catalina.connector.RequestFacade and is not accessible without doing nasty things.
2. Creating a custom Realm This is where I am at the moment, but Realms are used to provide the user details to the Container after the user is challenged via an authentication setting. eg security detects a role requirement, authentication challenges user, credentials tested by Realm The actual place you want to tap into the code is the AuthenticatorBase.register(...) method but buggered if I can see a way there.
To rehash: we have not defined container managed security settings since the securing of pages, the login forms and login process are all managed already and are not compatible with other implementations.
Maybe I'm over complicating this. If the aim is to provide SSO across two contexts then I can do this without Tomcat's help. Even though they supply an SSO valve, it too required the registration above and we go around the circle again.
Principal isn't a class, it's an interface. So all you really need to do is present an (apparently) identical interface to each domain in the SSO realm.
I have experience in creating custom Tomcat Realms, I can be bribed.
However, there's already existing SSO infrastructure for that. Aside from the convenience, SSO is **** near essential when running multiple sources into a portal. Unless users really LIKE logging in repeatedly to every panel on the dashboard.
If neither of the above solutions doesn't suit, It's not really that for you hard to write a custom Realm. I just happen to already be familiar with the ins and outs and have some free time to do it in.
Customer surveys are for companies who didn't pay proper attention to begin with.
Oh wait. You mean you already have a bunch of apps with DIY security and now you've discovered one of the reasons I recommend using the JEE security (container-based) standard instead - mods to the security paradigm break program code.
I hope that the app than needs Principal isn't also a DIY model. A bastard hybrid of standard and non-standard security services is going to confuse the heck out of anyone coming in to do maintenance - there'll be no predicting whether a given JEE security function will work at any given moment.
I do know a clean way to bolt add-ons to JEE security in Tomcat, but ramming JEE security structures into a non-JEE system is a lot uglier.
I'd say that one of the cleanest ways to get JEE security signed on from a DIY system is to have the DIY system do an internal request to a dummy container-based security app in the same realm and forward the signon credentials.