Authentication and Authorization
An important aspect of computer security is the ability of a program to enforce ownership of resources and access rules on actions involving these resources. This is accomplished by making sure that a program is used or invoked only after a human or program user has supplied its identity and has proved the ownership of this identity. This process of authentication is central for computer security. Although there are many different ways to perform authentication, in a majority of cases it is accomplished with the help of a username and password. A password is the shared secret between the user and the program.
A wide variety of solutions are in use for username and password validation—ranging from custom user databases to the use of the underlying OS authentication to the deployment of specialized SSO (Single Sign On) solutions from security vendors like Netegrity and Oblix. Java programs interact with these systems using the JAAS API, through specialized LoginModule implementations.
A secure username and password-based authentication system should not store passwords in clear-text. The consequences of this data getting into the wrong hands are devastating, for one who knows the password can impersonate the real user quite easily. A better approach is to store the one-way hash or digest value of the password. The validation step involves the validating program to compute the digest value of the supplied password and compare it with the stored digest values. This is an elegant example of a simple cryptographic operation supporting an overall system security.
Even digest values of the passwords are prone to brute-force attacks, for the passwords are usually a small and often a predictable sequence of letters. Someone who gets the list of usernames and corresponding digest values could simply try words in a dictionary or any other random combinations of letters, compute the digest value, and match it with the known password digest. In practice, such attacks have been found to be extremely effective. This is the reason that the recent version of UNIX makes it difficult to access the password file, the file with usernames and password digest values.
Authenticating users over an insecure network poses another kind of security threat. Passwords sent in clear-text provides no safety from unauthorized snoopers who can record everything sent over the network and run automated programs to capture login names and passwords. Even computing the digest is not safe, for someone could capture the digest value and resend the request at a later point in time. A special sequence of message exchange incorporating timestamps and values that are used only once, known as nonce values, can provide protection against this attack. HTTP-Digest authentication uses this mechanism.
In practice, though, HTTP-Digest authentication is rarely used and is not even a mandatory feature of the J2EE platform. The normal practice for high security applications is to transmit username and password over a secure connection. SSL and SSH are two protocols that make it possible to establish secure connections.
An alternative to username and password-based authentication is PKI-based authentication using certificate and private key. SSL uses this mechanism to authenticate the server to the client and, optionally, to authenticate the client to the server. Within SSL, the private key is stored on the local machine and is never transmitted over the network. Additionally, the private key on the local machine can be protected by a password. Recall the use of a password in retrieving a key entry from a keystore.
However, in practice, PKI has not found wide adoption for user authentication over the Internet, being seen as a complex solution with a number of potential loopholes. Carl Ellison and Bruce Schneier have written a paper titled Ten Risks of PKI, highlighting certain weak aspects in PKI-based trust and security solutions. Most of the arguments against PKI revolve around unrealistic trust on the CA (Certification Authority), the security of the programs handling the private key themselves, and the fallibility of humans involved in the overall scheme of things. This paper is available online at http://www.counterpane.com/pki-risks.pdf and is worth reading. This, of course, doesn't mean that PKI is worthless. We have seen many practical applications of PKI in this book—signing code, maintaining tamper-evident license files and so on.
Username and password-based authentication is widely used to access Internet accounts. This has resulted in a proliferation of accounts for the same person, forcing users to maintain multiple accounts and remember account identifiers and the corresponding passwords. In fact, it is not uncommon for a typical user to have tens, if not hundreds, of online accounts. This proliferation gives rise to another kind of problem. People tend to pick the same passwords for all their accounts. This means that the compromise of one account could easily compromise all of their accounts. Also, management of a large number of accounts is problematic for users.
There are at least two industry initiatives to address this problem: Microsoft's .Net Passport and Sun-led Project Liberty's federated authentication. Both of these initiatives are aimed at providing a solution where the user identity is managed by an identity provider and the service providers collaborate with the identity provider for user authentication. Both the solutions use cryptography to protect the interactions over the Internet.
Let us turn our attention to another part of the security puzzle—authorizing authenticated users for specific actions on specific resources. As we have seen, Java provides an elaborate mechanism to specify authorizations through policy files as per JAAS, for J2SE programs and through deployment descriptors for Web applications and EJBs. Declarations in Web application deployment descriptor file web.xml can be used to restrict access to URLs based on user roles. Similarly, the EJB deployment descriptor file ejb-jar.xml can restrict access to specific EJBs or EJB operations based on user roles. In the future, it will be possible to use JAAS mechanisms for authorization in Web applications and EJB based-applications as well.
Recently, XACML (XML Access Control Markup Language) has been endorsed as an OASIS standard. XACML defines the markup elements for expressing access control rules. This could emerge as a portable way of specifying access control for programs, and may even replace Java Policy files in certain situations. It is important to realize, however, that authorization mechanisms are local to a program and not very significant for interoperable solutions.