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.
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..
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.
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
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.
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..
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
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
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.
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.