• 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

security: declarative vs. programmatic

 
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All of my servlet and JSP stuff in the past has had some code that I wrote that keeps people from seeing the information without my permission.
Recently, I inherited a project where they go into web.xml and declare who is allowed to access any jsp or servlet. The web.xml file is enormous. The idea is that if the user doesn't have an appropriate "role" in the session, when requesting a JSP, they get redirected to the login.
Apparently, this technique is called "declarative" (what I did in the past is called "programmatic") and this is part of the J2EE spec, so it is supposed to work the same way on all systems.
So now I'm curious: is this the way that is the best way to handle who gets to see what? Or, is this just "a" new way and might not be the best way.
So far, my feeling is that while it might push a standard way of doing things, it seems that we give up some control. Sometimes giving up control is worthwhile. Sometimes it isn't.
What do you guys think: Is declarative the wave of the future? Or is it a lot of extra hassle without little (or even negative) payback?
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In favour of programmatic security -
1. custom made security.
2. can be guaranteed to be portable (i.e, implementation is not vendor dependent).
3. Rich set of roles, authorizations can be easily developed, and maintained.
In favour of declarative security -
1. best for simple roles and authorization schemes.
2. can make use of existing external security providers / accounts like LDAP, Kerberos, WinNT, and Unix user accounts.
3. immensely scalable across modules, applications, and even servers.
I've tried to list above thoughts such that those points in favour of one are implicitly against the favour of the other.
-GB.
 
Gopi Balaji
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Other thoughts -
If you *have* to make use of an existing authentication scheme, declarative is the way to go.
Well designed programmatic security can be made fine-grained.
One could use declarative security for authentication, and programmatic security for authorization.
-GB.
 
paul wheaton
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Gopi, this is exactly the kind of info I'm looking for.
What do you prefer?
 
Gopi Balaji
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gopi Balaji:

One could use declarative security for authentication, and programmatic security for authorization.


This, or a variation of this is what I would prefer.
A variation only in chosing the method of declarative security. Memory realm for simple requirements, JDBC realm for slightly more complex ones. LDAP, Unix/NT user accounts, and other exotic authorization schemes only if the requirements demand it.
But a point to note is that support for LDAP, and/or Unix/NT user accounts are available only if the App Server provides it.
Authentication is therefore taken care of. To maintain authorization schemes, I think it is best if done programmatically. Else, it could result in web.xml getting bloated beyond recognition. A simple and neat design of authentication can be done using filters (for page-wise/url-wise authorization), or using JSP tags (for more fine tuned authorization - segments of the page can be independently authorized).
Using a programmatic authorization scheme also allows for us to provide a custom UI to modify it.
Have you formed any preferences?
-GB.
 
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think J2EE wants us to do most of the work in a standardized manner, which should encourage us to use even authorization declaratively. I can't see any reason not to do it this way, when it can be easily accomplished using the rich set of options inside the <security-constraint> element.
I guess the J2EE developers would have done a better job than my starting to re-invent the wheel.
Thanks, Sudd
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm been teaching some J2EE design patterns and identity services both lately, and drawing from a lot of architect/designer experience in the room, as well as a few observations of my own. So let me start one level up:
The consequence to programmatic security, done bit by bit, is that you end up spreading related logic all over the place. With some refactoring, you can of course centralize this, and treat authentication and authorization (just call it A&A from now on) as a cross-cutting service. Still, you're writing code to protect code, meaning you get to recompile when your policies change, or design a suitable pattern for reading from files that must be maintained (not unlike declarative security after all), or whatever. As a rule of thumb, I think of recompilation as anathema to ease of maintenance, so that's my particular bias.
Declarative security is better, in my book, for a few reasons. a) It lets the container do work it was designed to support;
b) the XML syntax carries you right into being smart, by thinking of roles and policies rather than people and which services they want. This layer of abstraction is important, even for small development groups. The only reason I can think to poo-poo is if you know your user base won't grow and you plan to quit if it does;
c) get a decent XML editor, one that browses tagged objects in a clean, collapsible way, and the size of web-apps.xml loses its first and foremost burden of being tedious to edit;
d) most importantly, when either the declarative or programmatic stuff gets unwieldy, it's far easier to factor declarative stuff into -- ta daaaa! -- some form of identity service.
The missing strategy in the question is exactly that -- a standalone process to handle A&A on behalf of the entire container. These are alternatively called identity servers or directory access management servers, but all they are is a directory server fronted by a web server using serlvet/JSPs just to map the authenticated to their authorized services.
Boy I hope Map doesn't see this, but with a simple XSLT widget you could probably take a massive A&A declared scheme and import it into an identity server -- with programmatic controls, you have a bit of work to do to make the switch.
HTH
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally: always declarative.
I was against declarative when I first stared using it, but the only reason for that was that I was uncomfortable releasing security control to the container.
Let the container do the stuff it does well so you can get into other solving the big problems.
The other big advantage I find with declarative is that you can easily secure non-JSP and Servlet resources, like images, PDFs and Word docs. With programatic you can design a secured Servlet as a Proxy to the resource, but why bother if you don't have to?
I also like the ability to easily define directories as secure or not. The ability to secure a resource simply because it is in the secured directory and be confident about the security of that resource is a big relief.
Another advantage to the way it is managed in J2EE is that it protects against other applications in the same container from accessing privacy info, which is not guaranteed in programatic solution. Under declarative, you can't even get access to the user's password in your own container! Aside from stopping programmers from writing password loggers or passing the password somewhere they shouldn't, it makes it harder for external access to get hold of this information. (this is a slight lie, the container can make it available for authentication across distributed resources, but it doesn't change that it isn't available to the JSP programmer)
That's all I have to say about that
(in my best 'Forrest Gump' voice)
Dave
 
sharp shooter, and author
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Again, another vote here for declarative.
However, while declarative security can restrict who sees a specific resource such as a JSP, it can't help with controlling whether or not that person is authorized to see the information displayed on that page.
For example, I log in to a banking application and look at my account. Through the declarative security I am given access to the account page, but I should only be able to see my accounts. To enforce this type of logic you need to mix in some of the good old programmatic security logic. A good place for this type of logic (on the web app side) would be servlet filters or custom tags.
Simon
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow, I am impressed by the expertise here.
I think declarative makes things that change like users easier to maintain.
Meaning if I have to add a user or a role, I can go to the web.xml make the change without having to recompile, send out the new version to all the users, have them upgrade, etc.
It's the decoupling effect here. I mean whether it is programmatic or declarative you will still have to type in the users and roles somewhere, whether in code, a Database, or an XML file. But the real question then comes down to maintenance, and the effect it has on users, and the speed the change reaches the users.
That my 2 cents.
Mark
 
Gopi Balaji
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, people have strong views on this. This could turn out to be the J2EE generation's religious war.
I'm posting this through a dial-up, hence unable to reply to each interesting post.
For the poster who says, J2EE developers re-invent the wheel by not using declarative security, here is a contrarian (more true) view - J2EE has not invented the wheel. It has only given a specification on how to make a wheel. It is an immature technology as of now. There is no already invented wheel which can be used elsewhere or everywhere.
As to using a state of the art XML editor, one has to tile three instances of it (one to define roles, one to view URL mappings, and one to assign authorizations). Imagine doing this for several resources. It is perhaps alright for simple schemes, but would really become cumbersome for intricate policies.
Sure, one could still use web.xml, and avoid compiling. But, the J2EE application has to be re-loaded to give effect to it. Restarting the J2EE app for each and every minute changes is avoidable.
A&A (borrowed terminology) is a cross cutting concern. Very true. If this is viewed as such, and treated as such, A&A can become a simple problem. Using Servlet filters, custom tags, one could eliminate cross cutting concerns. Newer technologies (or, rather philosophies) of Aspect Oriented Programming can be applied to deal with this architecture/design/implementation issue at all levels.
A good design of A&A should make it transparant to maintainers and users alike. Using a right mix of servlet filters, custom tags and aspects (AspectJ-AOP), an excellent, intricate, maintainable, no-need-to-compilable A&A can be achieved.
Food for thought - I have a complex report, which utilizes expensive third party resources, complex statistical analyses to create itself. This is done by a external (external to J2EE) application. This external application pukes the report as a formatted text file(very similar to a well-known stat tool). The life of each report is valid for say, 8 hours.
This report contains information, intermittent parts of which is not privileged / not relevant to all the viewers who are authorized to view it. There are say, 5-7 classes of viewers, and 10-12 members in each class. Organizational changes / or other needs may need not-so-frequent changes in the classes of memebers, definition of new classes of viewers.
Imagine there are several such reports, and each have different intermittent parts with different privileges.
Using only declarative security, is it possible to develop an extensible, maintainable A&A?
-GB.
 
Gopi Balaji
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A few more thoughts -
1. web.xml, or rather any XML file should not be tamperd with by humans frequently (if at all). It was intended to be used by other tools, which render it to a different format more suitable for consumption by humans. XML editors of today which lets us see the elements are not very dissimilar to hex viewers of yesterday. web.xml is a place to hold certain configurable information, which changes from installation to installation, not from user whims and fancies (including security policies) within a single installation itself.
2. Declarative security is fine for whole identifiable resources. It assumes a resource, as indentifiable in web.xml. An identifiable resource could be a file or an URL pattern. What about not easily identifiable resources? Like parts of a file.
3. God forbid, if a portable declarative security mechanism *is* defined, it will have to be extremely complex to allow for all (or most) of the A&A situations in the real world.
Hmm.. by all these articulated thoughts of mine, it would seem that I am against anything having to do with declarative security. I urge you, it is not so. I believe it is a good path, to mix declarative and programmatic security, with declarative handling A (authentication), and programmatic handling the other A (authorization).
-GB.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Simon Brown:
However, while declarative security can restrict who sees a specific resource such as a JSP, it can't help with controlling whether or not that person is authorized to see the information displayed on that page.
...
A good place for this type of logic (on the web app side) would be servlet filters or custom tags.


Good point. The only point where I'd differ is that we tend to enforce this security in the Business layer ie You're what?? Asking for someone elses account details? Here cames a DontBeStupidException
It's the part of Authorisation and Authentication (A&A) that I don't really like since is allows security code to sneak onto Servlets and JSPs. There are several ways to handle it, but they require you to step outside the security model.
Something to be wary of, this is where the security holes creep in
 
reply
    Bookmark Topic Watch Topic
  • New Topic