Don't do it with JavaScript. JavaScript cryptography has a number of problems, and I don't think many browsers will let you access the PKCS#11 directly from JavaScript (running from within the page) easily.
A number of browsers support PKCS#11 for HTTPS authentication, that is, using PKCS#11 for client-certificate authentication as part of the SSL/TLS connection (as part of HTTPS).
Assuming you already have a PKCS#11 library available (let's say OpenSC in /usr/lib/opensc.so
), you can configure Firefox to use it:
- Preferences -> Advanced -> Encryption, go in "Security Devices"
- Click on 'Load'
- Choose a module name (for your own reference in the list) and point to the
/usr/lib/opensc.so
file (or whatever the appropriate PKCS#11 module is in your case).
Then, when you connect to a website that requests a client certificate, the browser should offer you to choose a certificate from the PKCS#11-enabled device.
The PKCS#11 configuration mechanism will vary from one browser to another, but it's usually a matter of setting the path of the PKCS#11 module.
As far as I know, Internet Explorer doesn't use PKCS#11 (at least not without extra support), but should rely on MS CryptoAPI and InfoCards instead.
On the server side, you will need to configure the requirement for client-certificate authentication. Nothing specific to PKCS#11 there.
Following your edit, you should read about Certification Authorities (CAs) and Public Key Infrastructures (PKIs). You could deploy your own internal PKI, but it sounds like your requirements are to integrate with an existing PKI. This is an administrative problem mainly, so check with those making this requirement to see on which CA they want to rely (probably theirs).
When using client-certificate authentication, the client will present its certificate (which contains the user's public key and other attributes, including an identifier: the Subject Distinguished Name) and the SSL/TLS handshake will ensure that the client has the private key for this public key certificate. Then, the server verifies this certificate against CAs it trusts (that's also an SSL setting on the server side).
Once you've configured which CAs you want to trust, the mapping is usually done using the certificate's Subject DN to an internal user name if needed. There is no hard rule for this, since it depends on your internal user naming scheme. This being said, it's often sensible to use the full Subject DN as the user name.