aspose file tools*
The moose likes Servlets and the fly likes J2EE Security Concerns and Confusions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "J2EE Security Concerns and Confusions" Watch "J2EE Security Concerns and Confusions" New topic
Author

J2EE Security Concerns and Confusions

Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
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.

Sean Clark ---> I love this place!!!
Me ------> I definitely love this place!!!
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41885
    
  63
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 ... ?


Ping & DNS - my free Android networking tools app
Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
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
Marshal

Joined: Mar 22, 2005
Posts: 41885
    
  63
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

Joined: Jul 09, 2007
Posts: 426


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
Marshal

Joined: Mar 22, 2005
Posts: 41885
    
  63
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

Joined: Jul 09, 2007
Posts: 426
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
Marshal

Joined: Mar 22, 2005
Posts: 41885
    
  63
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

Joined: Jul 09, 2007
Posts: 426
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
Mr Obi Orjiekwe
Greenhorn

Joined: Feb 03, 2004
Posts: 5
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
R. Grimes
Ranch Hand

Joined: Aug 23, 2009
Posts: 42
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
Naren Chivukula
Ranch Hand

Joined: Feb 03, 2004
Posts: 577

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


Cheers,
Naren
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: J2EE Security Concerns and Confusions