permaculture playing cards*
The moose likes Security and the fly likes Custom Policy, Security Manager? Best approaches? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "Custom Policy, Security Manager? Best approaches?" Watch "Custom Policy, Security Manager? Best approaches?" New topic
Author

Custom Policy, Security Manager? Best approaches?

Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
I'm a bit confused on what is the best practice that should be taken in regard to a security implementation that addresses the following:

I'm working on the security portion of a Java client desktop application (SWT). They want to use JAAS for authentication and authorization.
The authentication piece seems pretty straightforward, but I'm running into difficulty on the best approach in regard to handling Permissions.
Permission access is going to be defined by making a call to a local DB so using a policy file won't be of much good. I could create the Permission objects at startup by querying the DB or I could possibly make runtime DB checks.

Some ideas I was thinking of...

1) Create a custom Policy class that would query the DB on app startup and create the user Permission objects. The O'Reilly "Java Security" book I have mentions this approach but doesn't talk much about it, other than that both approaches (programattically or using the security file) have problems (class loading, boot classpath, etc.) I haven't been able to find many examples of this approach really being done either.

2) Use my own custom SecurityManager? I can overwrite the checkPermission() method in my own SecurityManager and possibly do the permission check at run time in this method, which would eliminate the need for even using a Policy? I could also programmatically load this SecurityManager which would mean I wouldn't have to rely on passing in a security manager through the command line.

I'm curious how other people are handling custom security approaches? Maybe I'm missing some other ideas?

Thanks a lot.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41180
    
  45
I'm not quite clear on what you are trying to achieve by using Permissions and security managers inside of the application. If the application is trusted, it can be run without a security manager and all is well (because it is allowed to do everything). If it is not trusted, then it should be run using a security manager, and any permissions it needs must be part of an external security policy. After all, if it's untrusted, then you wouldn't want the app to specify its own security policy, now would you

I guess I'm missing something here.
[ August 13, 2007: Message edited by: Ulf Dittmer ]

Ping & DNS - my free Android networking tools app
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
Originally posted by Ulf Dittmer:
I'm not quite clear on what you are trying to achieve by using Permissions and security managers inside of the application. If the application is trusted, it can be run without a security manager and all is well (because it is allowed to do everything). If it is not trusted, then it should be run using a security manager, and any permissions it needs must be part of an external security policy. After all, if it's untrusted, then you wouldn't want the app to specify its own security policy, now would you

I guess I'm missing something here.


You probably aren't missing anything, I'm just doing a poor job of explaining things and handling JAAS/Security in a client app is a new area for me.

The app itself is a trusted application, but what is done within the application will need to authorized (and authenticated to start with as well). The client application is an application that is installed on user's machines and when in 'connected' mode will end up synching up some local file database information. What the user can do within the application depends on his/her NT Login (these laptops are administered by the company to the users.)

So yes, it definitely needs to be run using a security manager. What I'm wondering about though is how to best build the authorization piece so that the access rights can be determined using JAAS. The access rights need to ultimately be determined from a local db running with the application so I don't think going against a policy file makes much sense. Unless I'm missing something, the default security manager uses the system policy file and the user policy file if it exists.

I'm just wondering on an implementation basis if it's better to create my own Policy that the application should use to determine Permissions or to maybe use a custom SecurityManager?

Please let me know if I'm still not making sense (which probably is the case
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41180
    
  45
Actually, I don't think that this is a case of using a security manager. It sounds to me like many (or all) actions inside of the application will be guarded by JAAS, though (which may use a security manager internally, but it sets that up itself).

The critical issue here isn't so much how the application interacts with the system it's running on (which is what is governed by policy files enforced by security managers), but rather what a properly authenticated user is authorized to do within the application - which is something JAAS can do.

I'm no expert on JAAS, so I'm not sure how it would pick up the Windows login information (unless you want to have the user enter it, and then re-verify it against an LDAP/AD server).
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
Originally posted by Ulf Dittmer:
Actually, I don't think that this is a case of using a security manager. It sounds to me like many (or all) actions inside of the application will be guarded by JAAS, though (which may use a security manager internally, but it sets that up itself).

The critical issue here isn't so much how the application interacts with the system it's running on (which is what is governed by policy files enforced by security managers), but rather what a properly authenticated user is authorized to do within the application - which is something JAAS can do.

I'm no expert on JAAS, so I'm not sure how it would pick up the Windows login information (unless you want to have the user enter it, and then re-verify it against an LDAP/AD server).


The authentication part, getting the username is fine. That part isn't a problem.

When you say "It sounds to me like many (or all) actions inside of the application will be guarded by JAAS," that to me is the problem/issue. What a person is granted/authorized to do is supposed to be guarded by JAAS but the implementation detail is how to best have the Policy created.

You mention the policy file, but this really doesn't work well for a situation where the Permissions that need to be set up are custom and will be based off who a user is in the DB.

Maybe I'm wrong, but I don't think it would be a good idea to write out on app start up every single possible user permission to a policy file (We're talking fine grained access rights here, not things like File or Socket access). Just for an example, maybe a user need to be checked to see if he's authorized to edit "formB." This kind of Permission would be stored in a custom "OurAppPermissionObject." The object tree of these available user Permission objects could be established when the application starts up. Since these permissions are not known until the application starts up, it would be a waste to have them to written to a file, only to have to read them into memory by the Policy (why not just give what you are reading out of the DB to the Policy in the first pass?)

Out of curiosity is there a way to tell you application to read a policy file that exists inside of a jar (I know you can use -Djava.security.policy to pass in a file to use, but not sure how that works for a file in a jar)? I'm assuming also then I could sign the jar and this would ensure that someone hasn't tampered with the custom policy file that I'm trying to use? I sort of wanted to stay away from using a policy file altogether since it seems too easy for the user to possibly create their own startup script that could use their own policy file using the -Djava.security.policy paramater. There must be a way to ensure that your application is only using a policy file that matches one that the author intended to be used?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Custom Policy, Security Manager? Best approaches?
 
Similar Threads
runtime exception
A setter that can only be called by framework
Probably a stupid question, the benefit of policy files?
NX: What's wrong with me server?
Signed jar becomes unsigned if loaded by URLClassLoader