Most developers build J2EE applications using their own security mechanism. This causes problems when other applications are introduced, because more logons have to be remembered and users have to physically log on multiple times to use different Web applications. A single sign-on allows a user to logon once and have transparent access to all the applications within a domain.
In Part 1 we explain what a single sign-on is and how it works, enabling you to implement a single sign-on solution. In Part 2, we'll implement a single sign-on solution for standalone and Web-based applications.
Single sign-on (SSO) in client and Web applications share common behavior but also differ due to their content delivery mechanisms. In Web applications, single sign-on allows a user to log in once to a centralized server and transparently access multiple sites or Web applications without having to log in to each Web application. Single sign-on for a standalone application allows a single application to obtain services from multiple servers by reusing a set of credentials through the Java Authorization and Authentication Service (JAAS).
Single Sign-on for Web Applications
Single sign-on in Web applications uses secure cookies, redirection, encryption, life-cycle management servlets, member servers, and a login server.
Secure cookies are Web browser cookies that can't be copied, read, or sniffed. Normal cookies are usually written to a cookie file. This is inherently insecure because an attacker could copy this cookie information to another machine where he or she could masquerade as the victim. In-memory cookies are not persistently written to a cookies file but to the browser's memory space. As a result, in-memory cookies protect users from a cookie file attack.
Cookies that can't be read have their payload encrypted. Although a cookie payload is encrypted, an attacker could sniff a network segment to obtain the cookies with encrypted payloads and initiate a replay attack. A hacker uses a replay attack by sniffing for cookies set after a user logs in. Although the hacker can't read the information in the cookies, he or she can use the cookies to masquerade as the victim.
To protect against sniffing attacks use the HTTPS protocol when transferring login server cookies to and from the client. This ensures that any information sniffed will be useless. The login server uses secure cookies to keep track of whether or not a user is logged in.
Redirection is the process by which users are transparently sent from member servers to login servers and vice versa. Redirection can be accomplished with META tags or JavaScript.
Encryption is the process by which clear text is transferred into cipher (encrypted) text. Symmetric and asymmetric encryption are two forms of encryption. Symmetric encryption utilizes a single key to encrypt and decrypt information. Asymmetric encryption utilizes a key pair where anything encrypted by one key can only be decrypted by the other. It's possible to use either method with SSO; however, symmetric key encryption allows all member servers participating in the login domain to share secure information using a single key, which is easier to manage and requires less maintenance when replaced.
