JWS Client???

[jingo]

I am trying to do the following from a java web start client:
i)JAAS compliant login
ii)EJB lookup

Both these actions result in a security exception. What should I do? This is the case for my Applet clients also.

I have searched the complete forum, but could not find a probable solution, all I could see was questions realted to this.

Can somebody answer my query?

Thx
jingo

[jonlee]

For clients on remote machines, you need a security manager and a security policy to connect to other systems using RMI/IIOP. With applets the security is tighter so you need to look at jarsigning. This is to prevent people from writing applets that are deployed to a remote browser and for example, start spamming from the local mail server. So there are connection policies that govern the machines to which an applet can connect. You will need to go to the Sun tutorials on security, security policies and jarsigning.

[jingo]

Now I understand! Thx

I just went through the specs and could not find it talking about having the jar signed? Is it mandatory for any J2EE application client (JWS/Applet) to be signed?
B'cos the spec implicitly says that a list of Permissions are required for any J2EE Application client.

Thx

[jonlee]

An applet can be downloaded from anywhere. Signing guarantees the source of the applet and also defines the only connection point for an applet.

The applet security system uses the credentials in the certificate presented in the signed file to determine the permissions in the policy file granted to the applet provider. You use the public key (that you need to download as part of the procedure of accepting signed jars) to obtain the signer's credentials.

So it does two things:
a) it verifies that the supplier of the applet is who he says he is (and therefore the applet is to be trusted) through the use of certificate and signing
b) it determines the things that the identified applet may do (based on the credentials in the certificate)

This is all necessary because users unwittingly run applets when they download them into a browser.

Applications that the users install and run on their machines is done through conscious choice. Therefore, the same rigour in identifying the source of the application is not applied. Indeed it would be difficult to enforce because a Java run-time environment does not enforce checking the origin of Java archives in the classpath. The default is that they have unrestricted access.

So both cases use security policies. However, the default restrictions are different - with applet restrictions remaining very tight. This unified view of security was introduced in Java 2. It means that you can implement security measures and fine-grained policy control in normal applications to the extent you see in applets.

Permissions are necessary but the default set of permissions depends on the type - application, applet. Other things will impose security requirements - for example most developers of RMI-based systems will impose a security manager to prevent unsecure code access to private system resources - like JBoss.

Hope that helps. That was security in a nutshell and I hope I haven't made things confusing. The security tutorials are much more thorough.