jni and c/c++ on iseries

I have created a java class file, created the c header file using jni, and compiled the c source file as a iseries service program ... everything works fine.

My question is security.  I call the service program from java by doing a System.loadLibrary("SVCPGM") and then calling the methods exposed.  How can I do the following?
1.  secure the communications between the java class and the service program?
2.  how can I secure the service program so that it couldn't be replaced with an intruder program?

Please note that I'm asking for programatic methods of doing this if there are any.  
dhenderson12Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

daveslaterCommented:
Hi
I am not too sure about the comms but for the service program you can use the
edtobjaut command to set the authorities.

EDTOBJAUT OBJ(mylib/mysrvpgm) OBJTYPE(*SRVPGM) .

This will restrict access to the object so it can not be replaced.

Dave
0
tliottaCommented:
dhenderson12:

1. You would generally secure comm by encryption. I've never actually looked to see how a Java program calls a service program, so I'm not at all sure if that's even necessary. If the call must pass through a server such as Remote Command/Distributed Program Call, as it might for a remote call, then encryption is the only choice I can think of. An exit program could potentially monitor transactions that weren't encrypted. I'll see what I can find out. If the service program attaches more directly with Java (perhaps through internal APIs in the JVM), then the "comm" isn't really "comm" at all -- it's more direct procedure calls and there's nothing to 'secure'.

2. Dave has the basic answer to the object security question. You secure access by revoking authority to the object. Just like any other object is secured. However...

It depends on exactly what you mean. If you're talking about simple security within your own system (your employer), then you set authorities according to the security policy. But if you're talking about something like distributing your Java and service programs to someone else's system, then you can't stop it from being replaced. You won't be able to stop an *ALLOBJ user no matter what.

You can, of course, code hand-shaking procs so the caller and callee must identify themselves to each other. As long as you're the only one who knows the challenge/response sequence, either side can tell if the other has been compromised.

Tom
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tliottaCommented:
Added note -- As near as we can determine, jni activations of and calls to service program procs are direct. I.e., no host server activity occurs between them. Therefore, communications security is generally irrelevant as long as all such activity is confined within the same system.

Tom
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.