• 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

Custom Policy, Security Manager? Best approaches?

 
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Rick Reumann
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
reply
    Bookmark Topic Watch Topic
  • New Topic