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
Related
I have a problem that I need to solve for my client. The situation is that they have a lot of users on one platform (platform_1). In order to use the platform a user must be signed in, therefore these users (credentials) are given out to clients for them to use the platform. The problem is that one user (one set of credentials) may be given out to a few clients, therefore we cannot know which of the clients did what (in this case - bought something) on the platform.
Figured I would just create a new system where the client can be created and a set of credentials would be attached to that account, then I would just display an iframe of that platform (platform_1) with the attached credentials on the newly build platform and then I would be able to track what the user is doing in the platform.
But turns out iframe cannot handle credentials and also it would not be safe to use this method..
Also thought about scraping the whole platfrom (platform_1), which would work, but then I believe it would be extremely hard to do live auctions, for example scrape the live auction and display it on my system and let the user click on some buttons and the script would do the same on the platform_1, but the delays and overall usage could make it very hard.
I would like to kindly ask you to share your thoughts on ways this problem could be solved or whether it aint possible.
When using WebAuthN (https://w3c.github.io/webauthn/) to authenticate, is it possible to hide certain authentication options?
For example, when testing on webauthn.io, my android device shows available authentication types like hardware keys, Bluetooth, and fingerprint. Is it possible for me to configure it somehow to not accept hardware keys and bluetooth.
Also, when selecting and using my fingerprint to login, if I force it to fail by using the wrong finger, it defaults to then asking for my unlock pattern and if I enter my unlock pattern, I still get a success. In my opinion an unlock pattern is not secure as a dirty screen leaves the pattern on the screen with a smudge mark. Also parents give the pin to children. Can I stop this behaviour and if the fingerprint fails error instead?
Not an expert but this is what I discovered when I recently implemented WebAuthn/FIDO2 support in our identity provider:
authenticatorSelection.authenticatorAttachment - When you create the request for navigator.credentials.create() you can specify whether it should use platform (i.e. built-in biometric/PIN) or cross-platform (e,g, an external USB/BT/NFC device). Note this just gives the user agent a hint about what you're after.
authenticatorSelection.userVerification - set this to required and it will require the user of an additional factor beyond mere verification of presence - i.e. a PIN or biometric challenge
Attestation - A FIDO2 compliant device can provide attestation information that can be verified via the Metadata Service. This will expose the capabilies of the device and you can base policy on that. E.g. you could insist that it must use tamperproof hardware to protect the private key.
Authentication result - can provide information about how the user was verified so you could build a policy around that. The spec for this extension is here: https://www.w3.org/TR/webauthn/#sctn-uvm-extension
The recommenation is not to specifically black/white-list devices yourself but the MDS does support revocation of certification and that should be respected by relying parties.
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I'm developing a POS Client using Chrome (packaged) Apps. It will run locally on the installed computers and interact with the server via web service. This app should only run on specific computers at the stores.
I know I can go to each store and install the .crx file in which case I don't have to publish the app to Chrome Web Store. However, I want it to be published to Chrome Web Store so that I can take advantage of its auto-updating feature.
What should I do to make sure that the app can only run at the stores' computers? (I can go the the stores and setup anything needed at the first installation).
Options I have thought of:
Create some secret key and enter it to the app at the first time of running.
Build a small tool (winforms application) to generate time-based tokens and install it on the computers. The staff will need to enter the token each time opening the app.
Any better idea how to accomplish this?
You said the app needs to talk to a web service to work. That's the key to a simple approach. (Assume you don't care whether the staff acquires a nonfunctional copy of the client app.)
At startup, app checks for existence of a validation of some kind stored in chrome.storage.local. If it exists, startup continues.
If the validation is missing, the app checks for existence of a GUID stored in chrome.storage.local.
If the GUID is missing, generate and store one using something like window.crypto.getRandomValues().
Ask the server for a validation by sending the GUID and getting a response.
If a validation comes back, save it in chrome.storage.local and go back to the start of this sequence.
Otherwise tell the user to get lost.
A full-strength version of this approach would have some additional features:
Use an HMAC(GUID, secret) for the validation. I'm assuming the staff aren't tech superstars, so something simple like a boolean would probably suffice.
Optionally add a per-launch step that sends up the GUID and validation and confirms it's still valid each time.
When the validation is requested, you might prompt for the secret key you mentioned in your question. In normal cases this would be needed only at provisioning time.
In case you haven't figured it out yet, the server is now acting like a simple licensing server, so it's up to you to decide how to decide whether the validation request succeeds. Maybe it allows only N validations to exist at once, or after you're done provisioning you hardcode future validations to fail. Maybe it limits validation requests to certain IP addresses. You get to choose.
That's the gist. It's a simple DRM system that is easier to manage than the enter-secret-at-installation method, but that won't withstand an attack of more than 30 minutes (since a smart attacker will just inject another machine's GUID and HMAC validation into the duplicate machine's chrome.storage.local).
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.