aspose file tools*
The moose likes Tomcat and the fly likes Implementing custom Realm to inject user Principals Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Implementing custom Realm to inject user Principals" Watch "Implementing custom Realm to inject user Principals" New topic
Author

Implementing custom Realm to inject user Principals

David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

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.

Self implemented SSO it is, then.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

When I started that post it was a query, at the end it was a blog.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

Nope, it needs to be a Principal associated with the user. I'll try the JAAS realm next to see if I can get the Principal in...
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

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.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

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.
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
My approach may or may not help, but the comments are pretty interesting.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

Thanks guys, they help.
Simon, I should hope you'd take an interest, since your Pebble code is the second application mentioned
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Implementing custom Realm to inject user Principals