my dog learned polymorphism*
The moose likes Security and the fly likes concept of security desgin Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "concept of security desgin" Watch "concept of security desgin" New topic
Author

concept of security desgin

Peter Primrose
Ranch Hand

Joined: Sep 10, 2004
Posts: 755
Howdy,

My question is more conceptual, less technical with reference to the software security. I am building an application where users has different level of access and belong to different groups (each group is characterized with different level of access and so forth).

Example: say I have a button call SAVE. Only users belong to the group: ACCOUNTING and with LEVEL 2 can press this button (the settings can be changed in the future).

I wonder if anyone know a good book/site which can guide me of how to write secrurity desgin.

Right now I�m doing this and please feel free to criticize if.




Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41052
    
  43
If you want to go all the way -and this is a big application-, then the way to do it would be using a Java API called JAAS. That allows you restrict access down to the method level. It's involved, though, and may be overkill.

Apart from that, don't hardcode values like 2 or 3 - make them constants, and -even better- keep those in a DB table.

Also, instead of sprinkling "Security.getLevelAndGroup" calls all over the code, bundle all those checks in a single method, which also takes a kind of "action" parameter. In this case the "action" would be a constant for "click the save button". That way, all security checks are in one place, which makes it much easier to see who is allowed what, and change it later.


Ping & DNS - my free Android networking tools app
Peter Primrose
Ranch Hand

Joined: Sep 10, 2004
Posts: 755
Ulf, thanks for the pointer.
I'm, not sure I fully understand the second part of your answer, you wrote:

instead of sprinkling "Security.getLevelAndGroup" calls all over the code, bundle all those checks in a single method, which also takes a kind of "action" parameter

what do you mean by "boundle all those checks in a single method" can you provide an example? Do you mean to have a method like:
public void save()
{
//do check here?
}

thanks, I'll check the JAAS
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41052
    
  43
No, I mean to have a method like this:

This would handle all the access checks, and would be the only method in need of change in case your security requirements change.

There are a number of reviews of security books in the Bunkhouse.
[ June 18, 2006: Message edited by: Ulf Dittmer ]
Peter Primrose
Ranch Hand

Joined: Sep 10, 2004
Posts: 755
It looks better, however, wouldn't that cause this particular method to be huge (consider all action possabilities) also, what if one day someone decides to change the name of the button?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

I don't know if it is possible for you, but my preferred approach is to not show buttons to people if they aren't allowed to press them. Or at least to make the buttons disabled in that case.

That means you have to do the access checking before, not after, you display the form. But the amount of programming work is still reduced because you don't have to code "You weren't supposed to press that button" dialogs. Besides which, those dialogs are user-unfriendly. My response to such a thing would be "Then why is it on the screen?"
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41052
    
  43
Originally posted by Peter Primrose:
It looks better, however, wouldn't that cause this particular method to be huge (consider all action possabilities) also, what if one day someone decides to change the name of the button?


You could break the method into several ones that reside in the same class, maybe grouped by functional areas. But you're right, it may become big. But having it all on one place still beats having it all over the code.

As to the action parameter, that would not be the label of a button, it would be an abstract constant that signifies the save operation, and is used whereever you ckeck permissions that have to do with that particular operation (which can be as large or as small as you like).
Robin Wilson
Greenhorn

Joined: May 10, 2006
Posts: 22
Actually, the method could be quite small. You'd have a parameter file or database table that would have the list of actions+level+role that would grow to match all the actions you wanted to protect, but the method could be quite simple... (Look up action requested, check level and role, call action or fail and throw exception...)

You'd probably want to explicitly deny access for any actions not listed (i.e., if the action lookup failed, don't allow it), but that depends on how high the security bar is set for your application.

(PS, make sure you protect the parameter file/db table from inappropriate access - since it holds the keys to your app...)

Of course, by the time you do this, you might as well have implemented JAAS.

Also, I tend to agree with the other poster - you want to perform the check _before_ you provide the optional action. So that the button never shows up if they aren't allowed to use it.

Of course, you _still_ need to perform the check on the actual action, otherwise you'll leave a gaping security hole in your application - where someone can call an action without proper authority, if they can figure out a way around your user interface limitations. Web applications are easy to get around, just message the server directly with a POST or GET... Native Java apps might be a tad bit harder, but it can still be done.


--<br />Robin D. Wilson
 
wood burning stoves
 
subject: concept of security desgin
 
Similar Threads
XML DOM & children nodes
Record Locking in multi-user
Linking security role for deployment
Many to Many Relation Error Driving Me Mad
Struts Security. JAAS?