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.
Basic Scheme Authentication
when your Applet or JWS 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 does not have a method to tell you which schemes Authenticator
supports or what the official scheme names are. It may support others besides basic,
digest, ntlm and spnego
(Kerberos).
It does not work with cookies or forms.
Under the Hood
You might wonder how after the login is complete that the server can tell if
messages coming in from the Internet are from people who are already logged in.
There are a number of ways of doing it. Some you might think would work don’t.
- By IP. You might think the server could just check if an IP in a message header
was from someone logged in. This does not work because IPs are shared. Everyone
in your home on the LAN, when the access the Internet comes from the same IP,
the IP of your router.
- By TCP/IP session. You might think the server would just check that the message
came in on the same TCP/IP session as the user logged in on. This won’t
work since you often connect with multiple sessions, and you would not want to
have to relogin just because a session tanked.
- Basic. The server sends you id/password with every request that is restricted.
This method is not secure since the id/password pair is in plain text for any
snoop to see.
- NTLM. This is a Microsoft proprietary protocol than will only work with
Microsoft servers and clients. I don’t know how it works. Java supports it.
- By Cookie. The server sends a cookie at login time, and the user includes this
cookie with each message to the server. This method is not secure since anyone
snooping can spoof the user by just copying the invariant cookie. Further, the
client’s browser must be configured to accept cookies, a practice which
invites all manner of malicious spying.
- 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.
- By HTTP auth digest. RFC 2617 Here each incoming message is digitally
signed in an unforgeable way. The disadvantage of this approach is it takes a
bit more CPU time to compute the digests and requires the more transmission
overhead. The advantage is it is the most secure method without resorting to a
fully encrypted data stream.
Learning More
Sun’s Javadoc on
Authenticator class : available:
Sun’s Javadoc on
PasswordAuthentication class : available:
Sun’s JDK Technote Guide on
Authentication : available:
Please email your feedback for publication, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to
Roedy Green :
