I have created a J2ME app and added it as jar in another app. The original app runs with maximum permission and works fine, but when I add it as jar in the 2nd app, I get security exception while making a web service call, and I noticed the app is running in minimum security.
I have added the midlet permissions for http and https in the JAD as well.
javax.microedition.io.Connector.http, javax.microedition.io.Connector.https
Any idea on how to fix this? The error I get is as below:
java.lang.SecurityException: Application not authorized to access the restricted API
at com.sun.midp.security.SecurityToken.checkForPermission(+459)
at com.sun.midp.security.SecurityToken.checkForPermission(+15)
at com.sun.midp.midletsuite.MIDletSuiteImpl.checkForPermission(+20)
at com.sun.midp.dev.DevMIDletSuiteImpl.checkForPermission(+28)
at com.sun.midp.dev.DevMIDletSuiteImpl.checkForPermission(+7)
at com.sun.midp.io.ConnectionBaseAdapter.checkForPermission(+67)
at com.sun.midp.io.j2me.http.Protocol.checkForPermission(+17)
at com.sun.midp.io.ConnectionBaseAdapter.openPrim(+6)
at javax.microedition.io.Connector.openPrim(+299)
at javax.microedition.io.Connector.open(+15)
at org.ksoap2.transport.ServiceConnectionMidp.<init>(+11)
at org.ksoap2.transport.HttpTransport.getServiceConnection(+11)
at org.ksoap2.transport.HttpTransport.call(+51)
at com.vxceed.xnappexpresssync.comm.WebserviceCall.call(+28)
at com.vxceed.xnappexpresssync.comm.WebserviceCall.callServiceMethod(+112)
at com.vxceed.xnappexpresssync.utility.Generic.sendRequest(+22)
at com.vxceed.xnappexpresssync.main.Authentication.authenticateUser(+77)
at app.ui.ServerSync.sendServerRequest(+127)
at app.ui.LoginScreen.authenticateUser(+9)
at app.ui.LoginScreen.isLoginValidate(+76)
at app.ui.LoginScreen.keyPressed(+48)
at app.ui.MainAppScreen$Clean.run(+33)
at java.util.TimerThread.mainLoop(+237)
at java.util.TimerThread.run(+4)
As Jonathan Knudsen states in "Understanding MIDP 2.0's Security Architecture":
The MIDP 2.0 specification defines an open-ended system of
permissions. To make any type of network connection, a MIDlet must
have an appropriate permission. For example, a MIDlet that uses HTTP
to talk to a server must have permission to open an HTTP connection.
The permissions defined in MIDP 2.0 correspond to network protocols,
but the architecture allows optional APIs to define their own
permissions.
Each permission has a unique name; the MIDP 2.0 permissions are:
javax.microedition.io.Connector.http
javax.microedition.io.Connector.socket
javax.microedition.io.Connector.https
javax.microedition.io.Connector.ssl
javax.microedition.io.Connector.datagram
javax.microedition.io.Connector.serversocket
javax.microedition.io.Connector.datagramreceiver
javax.microedition.io.Connector.comm
javax.microedition.io.PushRegistry
If you are using above APIs then your .Jar file must be signed with Proper Sign Certificates.
Check the article mentioned above for more detailed overview about Permissions.
You can buy such Certificate for example from Verisign.
Posting the solution in case it helps someone.
The problem was with the emulator. When I used J2ME SDK 3.0, with the DefaultCldcPhone1 it worked fine.
Related
Im using GWT, GAE to make a web app.
I looked at a bunch of tutorials regarding implementing a login system but most of those tutorials implement it so it's mandatory to login to access the web app. How would I go about making it so that anyone can access the app but if they want to use account specific functionality, they they have the option of signing up for an account.
There are two parts to it.
First, in your client code you check if a user is logged in. If so, you allow access to the "closed" parts of the app. If not, you show a link/button to login and hide tabs/views that are accessible to authorized users.
Second, in your server code you specify which requests do not require authentication and which do require it. This is necessary if a user somehow figures out how to send a request without using your client code.
For example, in my code some requests have checkSession() called at the very beginning. If no authentication object is found for this user in session, this method throws LoginException to the client. If the authentication object is present, the request continues to execute normally and returns requested data to the client.
Further to Andrei's answer, if you want a framework to manage the sessions for you, you can use GWT-Platform, which has an excellent Gatekeeper feature.
I use it for mine and I have a LoggedInGatekeeper class. Simply add #UseGatekeeper(LoggedInGatekeeper.class) to the constructor of each presenter proxy and it checks if the user is logged in. If you want anyone to be able to access that page simply annotate with #NoGatekeeper. Easy!
It takes a bit of setting up but it's a great MVP framework. There are maven archetypes and samples etc.
Hope this helps.
I made an application that uses Push Registry. When I try the application it does not work properly because of the permissions. Then I found out if I sign the application I can reach the always allow option.
But when I try application after signing at Samsung Omnia2 i8910, I click always allow then an alert come up saying it will change to only for this session. Anybody knows why this is? or how can I solve this?
Note: I use java verified R&D signing, and when I try to load at my Nokia 5800 it doesn't load because of certificate error. I don't know what I do wrong. I can load to Samsung.
After some research, I found an article about this problem. This problem occurs because of j2me security polities. J2ME doesn't allow to set always allow for auto start permission and network access. And that cannot be done with signing application. Article says that permissions are mutually exclusive.
"Additionally, the Blanket setting for Application Auto Invocation and the Blanket
setting for Net Access are mutually exclusive. This constraint is to prevent a MIDlet
suite from auto-invoking itself, then accessing a chargeable network without the user
being aware. If the user attempts to set either the Application Auto Invocation or the
Network Function group to "Blanket" when the other Function group is already in
"Blanket" mode, the user MUST be prompted as to which of the two Function groups
shall be granted "Blanket" and which Function group shall be granted "Session"."
ref: http://jcp.org/aboutJava/communityprocess/maintenance/jsr118/MIDP_2.0.1_MR_addendum.pdf
Note: I use java verified R&D signing, and when I try to load at my Nokia 5800 it doesn't load because of certificate error. I don't know what I do wrong. I can load to Samsung.
R&D signed midlet should be run on device with rolled back date, because R&D certificate is given for 7 past days from the date of signing. For example: date of signing is 19.08.2012, work period is from 12.08.2012 to 18.08.2012
I've been a little puzzled with this as I have not seen many examples that gave me the complete picture. The best explanation I found so far is this.
By defining a security role in web.xml such as "admin" for example, and having my login form with all the necessary fields (i.e j_security_check as action, and fields j_username, j_password), how/where does the actual authentication occur?
I plan to use a custom authentication using username/passwords (hashes) stored in the database. When the user submits the form, how do I make the Java EE Web Container invoke my sevlet/bean method do perform the actual authentication? I didn't notice any place to add a hook to my code in web.xml which would do the actual authentication.
By defining a security role in web.xml such as "admin" for example, and having my login form with all the necessary fields (i.e j_security_check as action, and fields j_username, j_password), how/where does the actual authentication occur?
In the servlet implementation, the servletcontainer. In Tomcat for example, it's done by the AuthenticatorBase class (source code here).
I plan to use a custom authentication using username/passwords (hashes) stored in the database. When the user submits the form, how do I make the Java EE Web Container invoke my sevlet/bean method do perform the actual authentication? I didn't notice any place to add a hook to my code in web.xml which would do the actual authentication.
If you'd like to keep using container managed authentication, but instead want to check the login against a database, then you need to configure the so-called "realm" accordingly. It's unclear which servletcontainer you're using, but in for example Tomcat, the documentation is available here: Tomcat 6.0 Realm HOW-TO.
If you really want to have your own homegrown authentication system invoked instead, then you need to drop the container managed security and homegrow it further. Which is not recommended.
The actual authentication is doing via either two ways:
Via a Server Proprietary way, e.g. the *LoginModules in JBoss, or the Tomcat one BalusC mentioned. These are different for each Server.
Via JASPIC, which was introduced in Java EE 6.
JASPIC pretty much has standardized the proprietary methods, but it's a fairly low-level API and unfortunately only available for full profile Java EE 6 and 7 implementations.
See Implementing container authentication in Java EE with JASPIC for more details.
For a new banking application we are currently discussing the details of a browser plugin installed on client PCs for accessing smartcard readers.
A question that came up was: Is there a way to restrict the usage of this plugin to a specified list of domains? It should prevent any third-party-site to use the plugin just by serving some <embed/object>-Tag.
The solution should be basically browser-independent.
It may include cryptography if neccessary, but should only result in moderate implementation overhead in the plugin code.
Ideas, anyone?
I know there exists a MS solution called SiteLock, but that's only IE.
You could hard code the list of authorized domains into the plugin itself.
Alternatively, you could expose a web service which will deliver a list of authorized domains. The plugin could make a call to your web service when instantiated to determine whether it can be started or not.
We came up with this idea: (described for one server)
The plugin carries a public key A. The plugin creator issues a certificate to the server's public key B. The server starts the plugin within a HTML-page and provides these parameters:
several allication sepcific parameters
the certificate
a digital signature
Then the plugin will start and first of all perform these checks:
verify the certificate with the public key delivered within the plugin
verify the signature with the public key from the certificate
if verification was OK then proceed, else terminate.
I need an applet to open a socket and communicate with a server listening on
the local host to which the applet downloaded (the end user machine).
contrary to what I have read about applet security, it seems that even signed applets
cannot open a socket to a different host from which they were downloaded (on the same machine it works perfectly)
I have certified the applet using -selfcert, signed it using jarsigner, and still, whenever
it tries to open a socket to a different host, I get:
Java.lang.Exception: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:9999 connect,resolve)
I even tried changing the Java policy file, although with signed applets it is not required to do so:
grant codeBase "http://applethost:8080/socket" {
permission java.security.AllPermission;
permission java.lang.RuntimePermission "usePolicy";
};
What is the deal with sigend applets, can they connet to a different host or not?
Yes, when you load your applet, if you choose to accept its certificate and trust it, it is granted AllPermission, which includes SocketPermission. I have written a signed applet before that connects to a host other than the one from which it was loaded. You could try temporarily changing your java policy file to just have
grant {
permission java.security.AllPermission;
};
Look in your policy file to see if it defines any other policy.url locations, perhaps they are interfering.
Check your browser settings for javascript maybe.
Make sure that you accepted the certificate for the applet and that it gets installed to your list of site certificates.
Make sure the grant codeBase line you have is the same as the codebase in your applet's manifest.
You could try printing out the list of permissions that your applet has before you try the connect.
You could try to programatically grant AllPermission from within the applet.