Ensuring that someone seeking to use some computer service is actually who
they claim to be, or that the provider of the service is actually who it claims
to be. Such schemes work with a shared secret such as a password or a private
key. In some schemes, the actual secret need not be exchanged, just proof that
other end knows the secret, e.g. by encrypting a random message with the private
key. You can do web authentication with basic authentication where the browser
brings up a dialog box for user name and password, form-based where the user
fills in a form with username and password and perhaps other information,
certificate based where the browser presents an X.509 certificate to the server
to request access, and digest authorisation where the password is digested
before being sent to the server to avoid it being snooped on.
Once you are logged on, how does the server recogise you to know that you are
already logged on when a message arrives? It can use four clues:
- a cookie. This is the most common technique.
- URL rewriting. The server sends unique URLs to different users. When they come
back the server knows they could only have come from the client they were sent
to.
- the IP
- The socket. If a message comes in on the same socket as previously, it knows it
must have come from the same client. Sockets don’t persist all that long, but
are not necessarily destroyed after every transaction.
Basic Scheme Authentication
when your Applet or JAWS application tries to access something restricted on the
server it gets a message back from the server telling it the realm (domain or
subdomain) and the name of the password scheme the server wants to use, e.g.
basic or digest. Your Applet then retries the request embedding the userid and
password information in the requested way.
In Java 1.2+, in your client code, you can use the java.net.Authenticator
class to handle the details. You extend the class overriding the getPasswordAuthentication
method like this:
Then you then register your custom Authenticator
with
import java.net.Authenticator;
Authenticator.setDefault( new MyAuthenticator() );
You then do your GETs ignoring logons! Your Authenticator
magically kicks in when needed and logs you in to the server. See the
File I/O amanuensis or the CMP HTTP package
for how. The technique reputedly works for HTTP and proxies. It may work for
HTTPS. It even works for digest passwords. I don’t see how it could work
for certificate style authentication, however, but who knows…
JDK 1.1-
If you are using an older Java, you will have to do it the Smith-Barney way (obscure
reference to the late John Houseman):
Digest Scheme Authentication
For the more secure digest-style authentication, the protocol is more complex.
It requires nine subfields. It is described in RFC 2617.
Java Authenticator uses this method when the server
specifies scheme= "digest".
It works by sending an MD5 digest
with each transaction, and changing the digest periodically. Your Applet
does not need to get involved with the details of how it works. Authenticator
handles it all transparently. You can fine tune how it works with networking
properties:
http.auth.digest.validateServer=false
http.auth.digest.validateProxy=false
http.auth.digest.cnonceRepeat=5
Sun does not document which schemes Authenticator
supports. It may support others besides basic, digest
and ntlm.
Learning More
Sun’s Javadoc on the
Authenticator class : available:
Sun’s Javadoc on the
PasswordAuthentication class : available:
2008-01-09 by Roedy Green ©1996-2008 Canadian Mind Products
Please email your feedback for publication, errors, omissions, broken/redirected link reports
