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
Basic Scheme Authentication
when your Applet or
JWS (Java Web Start) 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 version 1.2 or later, 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
Authenticator.setDefault( new MyAuthenticator() );
You then do your GETs ignoring logons! Your Authenticator magically kicks in when needed and logs you into the
server. See the File I/O
amanuensis or the CMP HTTP
package for how. The technique reputedly works for HTTP (Hypertext Transfer Protocol)
and proxies. It may work for HTTPS (Hypertext Transfer Protocol over SSL (Secure Socket Layer)). It even works for digest passwords. I
don’t see how it could work for certificate style authentication, however, but
Java version 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
Oracle 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 (Internet Protocol). 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
are shared. Everyone in your home on the LAN (Local Area Network),
when the access the Internet comes from the same IP,
the IP of your router.
- By TCP/IP (Transmission Control Protocol/Internet Protocol) 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
- 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
- NTLM (New Technology LAN Manager protocol). 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 (Uniform Resource Locator) rewriting. The server sends unique
URLs (Uniform Resource Locators)
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 (Central Processing Unit)
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.
Oracle’s Javadoc on Authenticator
class : available:
Oracle’s Javadoc on PasswordAuthentication
class : available:
Oracle’s Technote Guide on Authentication