• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

J2EE Security Concerns and Confusions

 
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have no knowledge about j2ee security but I am giving it a second look now. I have been studying this for a while now
but cant get my head to understand all the concepts.

I have been involved in web projects that runs on the company's local Intranet only.
As I have checked, there's no security constraints appended to it.

Here's how security is being done by me.
1. All apps have Login Page where users are required to Login.
2. Sessions are stored per each user on successful login
3. To protect URL from certain access, I have setup a filter that intercepts all request then check the
session for any principal. If not they get redirected to the LoginPage
4. All user privileges are stored as session attributes. User designation or Roles such as finance/production/admin/system admin is
stored in DB. Enabling/Disabling/Showing/Hiding of buttons and pages are largely based on the enrollment. If you dont have
access then it is not shown.

Now, here's where I get confused on my brief readings. Security is done either declaratively or programatically and Roles are assigned
on XML files. But what if I need to add a new Role? Do I have to change the XML file again? I think enrolling everything in DB is better.

I am not sure but can you comment on my authentication scheme. I dont want to hardcode all user roles on an xml file.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the XML file you mentioned - web.xml? But that would imply you're using container-managed security, and it doesn't sound like you are ... ?
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ulf,

What is the XML file you mentioned - web.xml



Yes, its the web.xml files

But that would imply you're using container-managed security



Yes, I am not using any container managed security. I have been following this link on web security
but I cant get my head to understand some of the concepts regarding appending Roles in my Tomcat XML files.

My thought is that why should I do the mapping of the Roles in my XML files compare to what I am doing now. Is my authentication scheme not yet sufficient?
Sorry, I might sound very confusing but thats really what I am now..

Thanks.

 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mixing declarative and programmatic security is indeed a hassle, so most people don't set up multiple roles in web.xml. Instead, there's just a single for all users-which ensures that anyone using the application needs to log in- and then within the app everything is based on the user information read from the DB.

That means some more work on the developer's part -e.g., you need to make sure non-accounting users really can't access accounting pages- but IMO that beats having to maintain all those role/URL mappings in web.xml.
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Hi Ulf, this is exactly my first impression. Though I cannot say that I am correct since I just started learning about Web Security.

Just would like to know how others are implementing security in bigger project. My project wont scale as to what others have been doing but I still would like to continue studying
security.

Thanks.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's been a while that I encountered a project for which pure declarative security would have been sufficiently powerful - mostly for making directories of static files accessible to certain user groups.

For web apps, I'd generally opt for a home-grown solution that checks login credentials against a DB, and then stores the pertinent details in the user's session. Coupled with a servlet filter that looks at all requests to make sure users are logged in (or redirects them to the login page if not), that provides more flexibility -especially at runtime, w/o the need to alter web.xml- than servlet security.
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

For web apps, I'd generally opt for a home-grown solution that checks login credentials against a DB, and then stores the pertinent details in the user's session. Coupled with a servlet filter that looks at all requests to make sure users are logged in (or redirects them to the login page if not)



Hi Ulf, this is exactly what I outlined above... So do you think this is more than enough as a security mechanism?

I still have not read that far regarding security, but judging from what I have read.. I still prefer the approach you outline above rather than hard coding everything in my xml files..
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So do you think this is more than enough as a security mechanism?


How much is "enough" depends on the overall risk landscape - what kinds of attacks are likely, how big is the damage if the system is breached, how valuable is the data to be protected etc. For some things, no security is fine; others require something akin to Fort Knox. For everything in between there's Mastercard it's a judgment call.
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

For everything in between there's Mastercard





it's a judgment call.



I think I need to study more on this subaject. For the mean time, I am quite satisfied with my security scheme
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The filter as a security check is overkill - unless you really have to use programmatic security. Take a look at the specs.

You may find it easier to write a Login Module and hook it up to a realm (GlassFish and tomcat support this, others?). This way you let the App Server handle authentication and authorization and cleaner propagation of the security context in your application. Allows for better abstraction of security architecture from a dev point of view.

read the Java EE 5 tutorial on security. clarifies things a lot
 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm basically doing what you suggest: set up a User file in the DB where the session info is stored, along with their permissions and roles.

One thing that I do to increase security is, not only require the sessionId be passed on each service operation request, but a secondary confirming piece of information. Let's say a customer requests to view an invoice, the client must call the web service with the sessionId, customer #, and invoice #. On the service side, I can both check the validity of the sessionId and make sure the passed-in customer # matches the customer # recorded in their User record. In this way, I have much greater assurance they are requesting an invoice belonging to them, which would not be the case if I only required sessionId and invoice # from the client. This prevents a mischievous user from modifying the request's invoice value and pulling in the info for some other customer.

I know you didn't ask about this, but, since we're discussing security, I thought it was worth mentioning.

Ron Grimes
 
Ranch Hand
Posts: 577
Tomcat Server Notepad Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been seeing a living hell working with security code when migrating my applications to Jboss server. Like Ulf mentioned, though it was much of a hassle for me at the beginning to work with declarative and programmatic security together, at the end I'm seeing how powerful they could be together.

But what if I need to add a new Role? Do I have to change the XML file again? I think enrolling everything in DB is better.


Web.xml only contains mappings to various security role references, the actual role definitions (roles with users) could be in LDAP, XML (e.g tomcat-users.xml), DB or elsewhere. So, if a new role is added, you might be still updating web.xml to provide authentication to various urls linked to this new role.

Cheers,
Naren
reply
    Bookmark Topic Watch Topic
  • New Topic