Module org.bzdev.ejws
Package org.bzdev.ejws

Class EjwsSecureBasicAuth

java.lang.Object
com.sun.net.httpserver.Authenticator
com.sun.net.httpserver.BasicAuthenticator
org.bzdev.ejws.EjwsAuthenticator<EjwsSecureBasicAuth>
org.bzdev.ejws.EjwsSecureBasicAuth
public class EjwsSecureBasicAuth extends EjwsAuthenticator<EjwsSecureBasicAuth>
Implementation of BasicAuthenticator supporting secure basic authentication.

As a protocol, secure basic authentication is identical to basic authentication as described in RFC 7617. The differences are in how passwords are created and compared, and in how realms are named. Generally, a secure-basic-authentication password is a URL-safe, base 64 encoding of a sequence of bytes. The first four bytes is a time stamp of a 32 bit two's complement integer, stored in little-endian byte order, providing the time at which the password was created as the number of seconds since 1970-01-01T00:00:00Z. The next four bytes is a 32-bit CRC of the first 4 bytes of the sequence followed by the password as an array of bytes using the UTF-8 character encoding. The remainder of the sequence is either

  1. a SHA-256 message digest of (1) the first eight bytes of the sequence and (2) a password using the UTF-8 character encoding.
  2. a digital signature of (1) the first eight bytes of the sequence and (2) a password using the UTF-8 character encoding.
  3. a digital signature of (1) the first eight bytes of the sequence, (2) the DER encoding of the public key provided in an SSL certificate, and (3) a password using the UTF-8 character encoding.
In all cases, both sides of the connection must use the same password. When a digital signature is used, the server must store a user's public key and the name of the algorithm used to create the signature. To distinguish these cases, the realm (described in RFC 7616) is prefaced with the following:
  1. [D]. This corresponds to Case 1 above.
  2. [S]. This corresponds to Case 2 above.
  3. [SC]. This corresponds to Case 3 above.
Case 3 is the most secure. When an SSL or TLS connection is established, a server will provide a client with the server's certificate and the SSL or TLS protocol will ensure that the server that provided the certificate has that certificate's private key. This can stop a variety of man-in-the-middle and spoofing attempts, at least to the point of inadvertently disclosing login credentials: in either case the certificate will be different, which means that the password that is generated will not be useful. A CRC is used because this provides a cheap way of rejecting authentication attempts that have the wrong password.

NOTE: For compatibility with openssl, one should use the keytool program, or SecureBasicUtilities.createPEMPair(File,String,String,String,String,char[]), to generate a key pair as a PKCS #12 file will then be created. The openssl equivalent to 


 keytool -genkey -keyalg EC -groupname secp256r1 \
         -sigalg SHA256withECDSA -dname CN=nobody@nowhere.com \
         -alias key -keypass password -storepass password \
         -keystore ecstore.pfx
is 

  openssl ecparam -name prime256v1 -genkey -noout -out eckey.pem
  openssl req -new -x509 -key eckey.pem -out eccert.pem -days 360
  openssl pkcs12 -export -inkey eckey.pem -in eccert.pem \
          -name key -out ecstore.pfx
although the choice of a signature algorithm (used to self sign) may be different. To add to the confusion, for the elliptic curve used in this example, keytool prefers the name secp256r1 whereas openssl prefers prime256v1. When openssl is given the name secp256r1, it will indicate that is is using prime256v1, whereas when keytool is given the name prime256v1, it generates an error message. Also keytool must use the same password for the file as for each entry it stores if the file is to be compatible with openssl.
See Also: