I need to create digital signature of some XML data with a client certificate(smart card) using web browser. Usually I used to do it with a java applet executing on the client side. The benefit being multiplatform in terms of OS and browsers.
However this option is getting increasingly harder and harder to implement and support in the long term. Virtually all browsers require some sort of action in order to execute such applet, code signing with a trusted certificate is almost mandatory nowadays, new manifest attributes and so on. Well there is nothing wrong with some extra layer of security and I am ok with that.
However Google Chrome as of April 2015 has stopped support for Java applets (and other plugins as well) - there is a configuration switch but it won't be available for much longer as stated here.
Mozilla Firefox does not have end of support date for NPAPI but they call it "legacy technology".
As for IE - it does not support plugins in Modern UI.
So with Java applets no longer really a universal option what are my choices?
What I have investigated so far:
ActiveX - IE only
Silverlight - no access to certificates at all and as a plugin faces the same limitations as Java
Browser specific extensions; For example Firefox up until version 33 used to have window.crypto.signText but not anymore
local applications installed on the client - not easy to install, support, develop and update for several OS and their different versions.
Web Cryptography - "only basic cryptographic functions", no certificates support
I ran out of ideas. All suggestions are welcome and appreciated.
I did same research few weeks ago, and the first option for me is migrate to firefox (at least for now).
An alternative, could be migrate applets to JNLP java client application (maybe with some websocket/restful synchronization between java client/server/web page).
I think the options that you mentioned have less support among browsers than java applet.
Proprietary API available
I want to revive an answer previously deleted for lack of information. My answer does not provide complete info but since I had the same problem and stumbled upon this question, I'd like to share my findings.
I also have an additional requirement so that the browser signature works on "older" (IE9) browsers.
There is a web API at https://www.4identity.eu/ distributed by Italian smart card manufacturer Bit4id.
The 4identity API, however, is not really a full "web API" that relies on plain Javascript, as it still requires to download a Windows-only client (sic!). The client, as far as I could understand, responds on a custom keychain URL protocol (I had a past Oauth-2 related question on how to handle desktop applications....) which is not standard according to my findings. The client has access to the key store so it can upload the signed file to the remote web service who is being polled by the Ajax page.
I need to do some paperwork to get full API access, and I have no information about pricing. Still, I deem worth to give a detailed look.
Part 2 of the question
Supporting a real digital signature from browser requires browser vendors and W3C, who oversees web standards, to do a lot of effort, maybe just the same effort they did for standardizing DRM solutions in HTML5 for sake of multimedia companies (criticism mode on). Currently there is WebCrypto standard but according to research it is not available in "mainstream browsers"
Digital signing a remote file with a smart card requires access to the key store and the implementation of cryptography libraries. An open source implementation of PaDES/CaDES is expectable by the community, but without a final implementation of a standard way to access the key store the smart card cannot be accessed.
See also this answer.
This additional part of the answer does not apply to my case as I require this to work on older browsers.
Disclaimer: I am not affiliated with Bit4id but I know them since I had the opportunity to integrate their work in my apps. One of our customers is a Bit4id partner
Related
We have a custom Java applet that performs certain tasks, like loading a PDF from local filesystem, signing it with certificates from system KeyStore/smart card etc. Such actions are not possible in regular HTML/JavaScript. Now that Java is being deprecated across browsers, we are looking for possibilities to replace the applet functionality.
There is this Web Cryptography API, but unfortunately the spec does not cover using system keystore. There is another spec for this, WebCrypto Key Discovery, but I don't think it is currently supported by any browser.
Mozilla had an API that might be exactly what we need, but unfortunately it is deprecated now.
So it looks like our only options are:
Write a custom desktop GUI app
Write a custom browser plugin
Or is there some better solution? What do you suggest? I don't care if the solution would be only for Internet Explorer since most of our users use.
Due to Java restrictions on browsers is not possible in general to use the OS native Key Store. You still can use Java in old versions of IE and Firefox, but Oracle has announced that will discontinue JRE plugin for browser, and Firefox decided to drop java support in 2017, so it is not recommended
Write a browser plugin is not possible because browsers do not allow access to several OS functions. In particular Chrome plugin API only allow access to user certificates in Chrome OS, not in Windows or Linux. For Edge, I think the plugin interface is not available yet.
There are some alternatives
Use WebCryptographyApi to load a software certificate. See How to load a PKCS#12 Digital Certificate with Javascript WebCrypto API
Use chrome messaging api (Estonian solution). See https://stackoverflow.com/a/29806091/6371459
Use a local application connected through javascript (Spanish solution) See https://stackoverflow.com/a/38658414/6371459
I personally have tested the first and the last options. For Estonian solution, I suggest to contact with the team. I think the currently support only some smartcards
I am a relatively newbie to Lotus/Domino world and have been tasked with the following Domino task.
Access user's Domino mailbox (from a middleware server) and delete certain malicious emails from the same.
Additional Background: There is a external security tool/process that analyzes all incoming email and can flag the email as malicious. In the event it is flagged as malicious then I want to delete this email from the respective user's inbox.
My solution would be deployed on its own middleware server (Linux based) and will receive incoming notifications as to what emails need to be deleted.
The Domino server deployed in my environment is Lotus/Domino 9.
I want to preferably implement this functionality using Java.
I researched and found the potential options for me for accessing the user's inbox on Domino server.
1) I saw that there is a IBM C/C++ API toolkit for Domino. The C API looks quite complicated to me on first glance. Also I would need to install the Notes client (on my middleware server) so that I could invoke the C API remotely?
2) Is there a Java API that I could use to connect/access Domino? I found:
IBM Knowledge Center - IBM Domino Designer 9.0.1 - API Documentation and
IBM Notes and Domino Application Development wiki.
These seem to indicate there is some Java/REST API interface however I am not sure if I can use this to access inbox/mailbox data. It seems to indicate "Calendar" data but nothing about email/mailbox data as such.
3) I came across the OpenNTF Domino API project while researching and that seems to have a Java API. Should I be using this?
What is the best way to access Domino from an external server standpoint? Am I stuck with the C/C++ API or is there a relatively (easier to understand and use) REST/Java API that I could leverage? Also will I have to have the Notes client installed on my middleware server so that I can invoke the API (C/C++ or Java)?
You should avoid the Notes C and C++ APIs unless:
You know Lotus Notes and Domino really, really well (or are willing to learn a lot very quickly) and
You determine that the only way to solve your problem would be to write a Domino server task or extension. These APIs work with Lotus Notes/Domino data a very low level.
Yes, there is a Java API. It's been around for years. There is also a REST API that can be accessed from Java (or from any other language that can make HTTP connections) but that's only been around for a few years.
The Java API is richer and can get to a lower level than the REST API.
The REST API might be adequate for what you need, but there's a very good chance that the server will have to be set up specifically to enable it to access the mailboxes. That will not necessarily be the case if you use the Java API.
Using Java API will depend on whether you can run your Java code on a machine that has the core Lotus Notes/Domino code installed. Also you'll have to investigate the technical and licensing questions on that.
A good way to get educated on the Java API is to read Bob Balaban's book. It is old and out of date, but it does cover most of what you need to know for the purpose you've described. One caveat is that it was written so early that it did not cover the need for making recycle() calls. But he's posted the chapters here for free download. Now that you know about recycle() I'm sure you can find information about why and when you need it.
The OpenNTF Domino API is an open source replacement for the offical Java API. It has been built to solve a lot of really nagging problems (like recycle()!) and the limitations usage of the official API runs into.
Re: installing the Notes client which I alluded to that when I mentioned the core Lotus Notes/Domino code under point 2. You have two options for the official Java API:
Local:
This uses the core Notes/Domino code to make Notes RPC calls to the server, so you will have to install a licensed version of the Notes client or Domino server code to get the core code.
Note that if you are tied to a 64-bit JVM, you need 64-bit code and that means you need to install the Domino server instead of the Notes client since there is no 64 bit Notes client.
Remote:
You don't need to install any Notes or Domino code but this uses CORBA/IIOP instead of Notes RPC to talk to the server. This requires enabling IIOP on the Domino server.
The last time I checked, the OpenNTF API only supports the "Local" model.
I do have to mention though: this is close to being off topic for this reason:
Questions asking us to recommend or find a book, tool, software
library, tutorial or other off-site resource are off-topic for Stack
Overflow as they tend to attract opinionated answers and spam.
Instead, describe the problem and what has been done so far to solve
it.
Whilst the existence of a Java API can be easily confirmed by searching here on StackOverflow, I have to admit that finding basic references for Domino is quite a bit more challenging. There is literally 25 years worth of information about it that's out there, but is often in fragments and is obsolete. It is really difficult to find information about tools, APIs and libraries that are available and current today. The options are really pretty limited.
As such I think this question deserves an answer since it does not really come down to opinion. I'm not going to make a recommendation though, because that really would be opinion.
My society was hit in the face with the NPAPI deprecation in the google browser.
We were using Silverlight for a long time and we are curently looking for any replacement solution.
What was good about applets and silverlight was the easiness for the applications to access the file system and get the rights to automatically save anything into the computer.
Beside it was compatible with the major OS and almost all Browsers, which was a great thing for our customers.
But chrome decided that NPAPI causes too much security problem, and they will remove it by september.
I'm looking for a simple way to provide access, at least to the file system of the customer.
asp.NET gives us anything we need, on the server side, but it can't do a thing on the client side. With silverlight we were able to use the clipboard,save multiples files on specific directory, send mails from the client etc.
I thought about making our own plugin on several OS, but that would be a lot of work. So i was wondering if there were a simple compatible solution that already exists.
You could build a FireBreath2 plugin to provide this functionality -- FireBreath2 will work on chrome w/ native messaging, and the functionality you describe shouldn't be too hard to do cross-platform. Keep in mind that you've got some serious security risks to protect against, though.
FireBreath2 as of this writing isn't quite production ready, but it's pretty close. ActiveX support isn't complete yet, but it shouldn't take that much work to finish it. It would require a good understanding of C++ and a willingness to help with the project since it's not 100% ready for prime time yet.
I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
What is the Microsoft version of an embedded Java web applet? Is there a good example of one on the web?
Also, why is the dynamic web dominated by ajax and not embedded applications?
Silverlight is probably the closest thing now.
As far as why the web is dominated by JS driven websites rather than embedded proprietary applications I'd venture to guess it's the openness of the resulting web pages. Almost every web browser out today ships with a JS engine, and most users run JS; this is important because it means the user doesn't have to have any other applications (beyond the browser) installed on their computer.
JavaScript driven sites are also more portable than embedded applications -- the developer only needs to worry about a browser being installed (though perhaps a particular browser), not what operating system the end user is running. In terms of being on the web, only having to worry about browsers is better than having to worry about browsers and operating systems.
Furthermore, the pages that result from JS execution are selectable, the text can be copied and pasted -- in general, JS-driven websites are often more accessible (though often not as accessible as plain-old-text websites).
Perhaps something that helped JS/Ajax rise to the top was that it could so easily access to the DOM, so it plays nice with HTML (and the existing web infrastructure).
An ActiveX control?
Also, to your second question, well these "embedded applications" as you call them aren't really web applications. They are components that require browsers to support some sort of way of hosting them that are outside of the realm of traditional Web standards and specifications. As for why these applications don't "dominate" the markert, they tend to break out of the way the web works and many kinds of platforms and devices don't support them such as mobile phones.
The Microsoft equivalent of an "applet" is roughly an activeX control, although they are only vaugely similar - the similarity is that they are both embeddable into the browser. The most notable difference other than windows vs cross platform is in the region of security. With ActiveX, it is all or nothing - you either don't run it, or you trust it with everything - the activeX control runs as a regular windows "program" and has the same level of access as other programs running under your account. With an applet, security is more finely controlled, with the default being a controlled environment - the "sandbox".
As to why AJAX is more popular might be considered a subjective question, but from the technical perspective, some objective points in favor are:
it is implemented on top of a browser model that aims to provide a safe/secure execution environment
is cross platform (in as much as the browsers adhering to the various standards involved.)
has a suite of development tools and libraries for getting results quick
it can manipulate the components in the browser rather than working inside an isolated embedded box
it provides a better end user experience - seamless integration with the webpage with no security warnings, certificates, popups etc.
You could consider ActiveX or Silverlight both as alternatives to Java Applets.
Ajax is built on open standards, is natively supported by most modern browsers without requiring a plugin download, and when done correctly is often the best option from a performance standpoint.