Rick Reumann

Ranch Hand
+ Follow
since Apr 03, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rick Reumann

Originally posted by Mark Herschberg:
You can just put the rest of the code in a code block to mimic this behavior. Isn't that what Java does under the hood anyway with a break?




--Mark



How would that help with an each closure? or are you suggesting you wouldn't use an each closure at all - if that's the case, I think that's sort of limiting.

If your suggesting use a closure within the each closure, I'm not sure how that would help?

I'm sure I'm missing what you're suggesting.
11 years ago
Are there any plans to allow a way a "break" from an each closure? In other words, sometimes I'd like to do ..

collection.eachWithIndex{ it, i ->
//do stuff with it
if ( someCalculation == i ) break

}

But there is no way that I see to break out of an each closure?
11 years ago
Sun's site has two download links to the EJB3 spec and JPA spec:

http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

However, the document specs on each page seem to be the same. Are the specs on each page the same, or are there slight differences between them?

If there are differences, which set of docs is better to use for studying from?

The differences seem to be either the:

"Specification for evaluation or to build an application that uses the Specification"

or

"Specification to build an implementation of the Specification"

Yet again, both appear at first glance to refer to the same documents?
After doing even more research, I think what I was doing in JBoss wasn't really standard. Not positive though.
12 years ago
I'm coming from a JBoss background and in some apps I've worked with we'd define common jars that are ejb and war needed in our application.xml file and everything worked fine. I'm now stuck at a place using old Bea Weblogic 8.1 and it seems like I can only define the shared jars in the manifest file definitions. When I try and use application.xml to declare the shared jars that I want my ejb and webapp to use, weblogic complains with class not found errors.

The docs seem to be confusing on the issue. On one hand they have these docs on application.xml
http://e-docs.bea.com/wls/docs81/programming/app_xml.html#1007302

but in another area it mentions having to use the manifest files for declaring external jar dependencies.
12 years ago

Originally posted by Shiaber Shaam:
[QB]Hi all,
Could anyone please provide me a link of basic EJB Tutorial.
/QB]



I have a few here using EJB2 and EJB3 on JBoss...

http://www.learntechnology.net/

I try to keep it very simple. Not a lot of discussion of the technology, mostly how to get a simple app up and running.

Originally posted by Ulf Dittmer:
The theory is that the user is in charge of his own machine (and is trusted to do the right thing), whereas the application by default is not. If the user feels that the application can be trusted, he can allow it to do more things than an untrusted application. Since that requires a conscious act of the user, that is considered OK.



I figured as such, but it does seem to create an interesting situation when it comes to authorization. I'll explain the approach I opted for at the end of this post, but I'll start with the 'problem.' (Some of this in another post, but I'm going to link to this one from that post.)...

Let's assume the user installs his company's Java swing application on his machine. We'll assume this client application has a direct connection to the internet as well (ignoring off-line mode.)

The developers of the application know about JAAS and figure they should use that to help enforce what things the user could do within the client app.

Authentication works nicely by pulling the user's windows username and cert and doing an online check to get possibly a list of roles the user has.

The developer now wants to implement authorization checks on various parts of his client app. For example maybe only an "Amdin" role could perform an "edit" function. An easy non-jaas approach is to simply let the developer of the client hard code logic into the application, looking up a role and then allowing it.. ie...

if ( loggedInUser.hasRole("AMDIN") ) {
//allow him to call editSomething()
}

The above might be an ok approach, but the developers want to use JAAS and call:



So the question now comes up as to where to store the allowable Permissions for user roles.

Let's assume we want to use a policy file. Obviously for this approach to work, we'd have to make sure the application comes installed with a custom file policy that declares all the role permissions. We also have to make sure the user can't modify this file, for if he could, he could grant himself "AllPermissions." We also have to make sure there is no way that the user can start up the application passing in his own policy file as an arg and bypassing our policy file. We also have to make sure he can't disable using a SecurityManager. For example, we'd be in trouble if we only relied on an editable startup script that passed in the args for the securityManager and the policy file (since the user could just remove or replace them as they wish.)

Here's the overall approach I ended up with....

1) Do not rely on any security args being passed in to start your application.

2) Create a policy file and bundle it in your jar. The policy should grant AllPermissions. (Considering the client is
trusting you application to install on the machine, this isn't that big of a deal.)

3) Create your config file that declares your Login module and bundle that in your jar as well.

4) Create your own Permission class to handle what you want to authorize.

5) Create your own Policy class or your own Security Manager to work with the Permsission class you created. If you create your own Policy you won't need
to rely on a policy file and can ensure that your test in the implies method of the Policy file really checks for Permssions that you can manually give to the user/codeSource. (Without a custom Policy or SecurityManager, there might be a hole where somehow the user managed to pass a policy file that granted AllPermissions.
We only have our policy file (with AllPermissions) around just so that we can pass through any Permissions we don't care about to be handled by the default Policy.

6) Load your policy and config files from your jar and then initialize your Policy and the default or custom SecurityManager (in this example I'm showing a custom Policy and using the default SecurityManager). I do this in a static block. It should be in a class that first gets loaded. This is nice also since it also forces a SecurityManager to be used - and doesn't rely on passing in the securityManager arg by command line.



My Policy looks something like...


[ August 16, 2007: Message edited by: Rick Reumann ]
12 years ago

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?
12 years ago

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
12 years ago
It seems like if you are relying on a policy file to define security for a client application, isn't this a bad idea? For example, if your client app starts up with a shell script that has a jvm arg:

-Djava.security.policy=./dir/my.poilcy

A user could modify this file or simply modify the script and swap out the policy file with their own and open up all permissions? - just have one grant entry: permission java.security.AllPermission; ?
12 years ago
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.
12 years ago
I managed to get everything working ok using

grant {
permission java.io.FilePermission "<<ALL FILES>>", "read";
...
}

Eventually I'd like to somehow use relative paths but I couldn't figure out to get that to work correctly. For now the ALL_FILES will work ok.
12 years ago
Ok, I made a bit more progress when I removed commons-logging and just went to use log4j without the commons wrapper (with the log4j.properties file in each jar). However, I'm still stuck on the jars not finding the log4j.properties file when I use the security.manager. (Also if I give all permissions grant to the jars, logging DOES work with the security manager in place, but problem then is that everything passes when I really try to use this with JAAS.)

I've vastly simplified things in the new example that I put out here:

http://www.learntechnology.net/TestLoggingWithSecurity.zip

('ant run' will build and run test.)

The code is just 2 simple classes and does nothing with jaas (I stripped everything out.) The bootloader thing is removed as well (as that was an artifact from something else I was trying.)

I'm posting what I think is the relevant code below. The ant build and policy file---

MyJAAS.policy


build.xml



Test.java
12 years ago

Originally posted by Paul Clapham:
If it was in the root of the jar thenshould not find it. But you said initially that it did. That's what led me to believe you didn't put it in the root of the jar.



Maybe I should have added that that path above was to a log4j.properties file that was 'not' in the jar (even though I left it in the jar for trying things to get it picked up from there without using PropertyConfigurator). The above path was a full path to a file in the project.
12 years ago

Originally posted by Paul Clapham:
But do make sure you put it in the root of the jar, where the classpath points to. One of your earlier examples seemed to suggest you had put it in a directory inside the jar file.



No, it was just in the root of the jar (not in a directory) and that actually worked really well except for of course when I threw in the wrench of using the security manager as a jvmarg: <jvmarg value="-Djava.security.manager" />
12 years ago