Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Implementing custom Realm to inject user Principals

 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I started that post it was a query, at the end it was a blog.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18020
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18020
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My approach may or may not help, but the comments are pretty interesting.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys, they help.
Simon, I should hope you'd take an interest, since your Pebble code is the second application mentioned
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic