Security and Single Sign-On

We suggest that you consider thisexample as you encounter the security technologies available to you when build-ing a portlet.Portlet Security Generally, a portlet passively receives use

CHAPTER 8 Security and Single

Sign-On

SECURITY AND SINGLESign-On (SSO) are not unique to portlets, but when ering their implementation you must take into account some special advantages,disadvantages, and responsibilities

consid-A portlet has some security advantages over a conventional application You

do not have to concern yourself with obtaining a login from the user, for example—

this is the responsibility of the container

You do still have some responsibilities; your portlet must manage access toits resources For example, a corporate address book should probably be accessibleonly to employees of the company, whereas a private address book should in gen-eral be accessible by only one person

A portlet may obtain information from external resources, so you also need

to be aware of the options for passing security information around—possiblyover the network

While the developer’s natural inclination is to “Keep It Simple, Stupid” (KISS),

it is no longer a safe assumption (if it ever was) that the network is secure bydefault Avoiding security vulnerabilities adds a regrettable but necessary level

of complexity to the design of any portlet acting as the gateway to sensitiveinformation

This chapter discusses the standards, protocols, and APIs that are required toimplement secure portlets The security mechanisms specified in the portlet APIare the most basic level of portlet security We discuss SSO strategies for portals,including authentication with Java Authentication and Authorization Services(JAAS) We also demonstrate how to use the Java Generic Security ServicesApplication Program Interface (GSS-API) with Kerberos

Before we embark on our analysis, let’s briefly consider a situation where all

of these tools might be required for a truly integrated solution In the exampleshown in Figure 8-1, we have users connecting to (and authenticating with) a por-tal using their normal browser security This contains a portlet e-mail application,which uses the user’s credentials to log into and present a web mail application This

in turn must access a legacy e-mail database, presenting the user’s credentials to

do so

E-mail is a very familiar environment for almost all users, and the need forthe protection of private messages is obvious We suggest that you consider thisexample as you encounter the security technologies available to you when build-ing a portlet.

Portlet Security

Generally, a portlet passively receives user authentication and authorization mation from the container It is often not necessary for your portlet to directlyestablish the identity of the user As a result, when designing a simple securedportlet to be entirely portable, you need only concern yourself with the way thatyour portlet interacts with its security environment

infor-This holds true only when a portal has its own access control for portlets, either

on a per-user or per-group basis Some portals allow a user to add any installedportlet to the user’s portal page Most portal deployments require some kind ofsecurity or access control for administrative portlets This can be accomplished byallowing only certain users or sets of users to show a portlet on their page, or byhaving the portlet code check the user’s information to determine what they areallowed to view

Browser

Portlet

Web Mail Application

Authentication Server

Legacy E-mail Database

Portal (Portlet Container)

Figure 8-1 Portlet security interactions

Similarities to Servlet Security

Since a portlet is generally contained within a servlet, it should come as no greatsurprise to discover that a portlet behaves quite like a servlet in its provision ofsecurity mechanisms

The HttpServletRequestobject provided with requests to a servlet is required

to offer the following four methods:

public String getAuthType() public String getRemoteUser() public boolean isUserInRole(String role) public Principal getUserPrincipal()

The information provided by these four methods is in turn made availabledirectly to a portlet via the PortletRequestobject The same four methods are avail-able from the request object during the action handling and during render handling

Authentication Types

Portlets generally permit four types of authentication Which of these has beenused can be determined by calling getAuthType() This method allows a portlet todetermine the quality of the secure relationship and as a result to restrict the set

of information that it will permit the user to access

In Basic authentication, the username and password are obtained from theweb client (browser), which manages the mechanism of obtaining them from theuser and submitting them to the server The web browser sends the details asplaintext, so they are vulnerable to “man-in-the-middle” attacks

NOTE Man-in-the-middle attacks are a form of security attack where one sets up a proxy server between an unknowing client and an unknowing server The proxy server listens to requests from the user and records them The requests are passed to the server, and the server returns a response to the proxy server The proxy server also logs the response, and then passes the response back to the client The “man in the middle” now has all of the user’s requests and responses If the browser has sent any sensitive information as unen- crypted text, it is now compromised The attacker may also alter the user’s requests and responses.

some-Client Certificate authentication requires the server and, optionally, theclient to authenticate each another with public key certificates The exchange is

carried out over Secure Sockets Layer (SSL) to guarantee that it cannot be read if

it is intercepted Client Certificate authentication is managed by the web client.Digest authentication is about halfway between Basic and Client Certificateauthentication The username and password are not sent in plaintext; instead theyare sent as a message digest, which prevents the password from being retrieved.However, as with basic authentication, the identity of the server is not verifiedand the exchange is carried out over an unsecured connection so there is still somedegree of vulnerability

NOTE A message digest is an arbitrarily short representation of a message.

A “hash function” is applied to the original message to produce this short resentation A trivial example of a hash would be one that counted the number of words in the message.

rep-A more typical example is the MD5 algorithm, which will reduce a message of any length to 16 representative bytes The chances of any two messages pro- ducing the same digest are astronomically small, and it is effectively impossible to reverse-engineer the original message from its MD5 hash.

This makes the MD5 hash perfect for confirming a password over a network The remote server will send the client a random “salt” text This is added by the client to the password, and the digest is computed The client sends the digest to the server, which will compute the digest independently and com- pare it with the client’s digest If they match, both machines must know the password, but an eavesdropper cannot reproduce the digest independently (without knowing the password).

The use of a salt prevents a third party from simply retransmitting the digest, since it will be different for every salt value.

Form-based authentication is one of the most commonly used forms of tication, largely because it can be made secure and offers cosmetic advantagesover web client–managed mechanisms The username and password are sub-mitted as plaintext in a form request If the POST mechanism is used and theconnection is over HTTPS (SSL) rather than HTTP, this cannot easily be inter-cepted The PortletRequestclass provides the constants that are used to identifyeach authentication type

authen-It is also possible that no authentication will have been carried out, in whichcase getAuthType()will return null

Identifying the User

The getRemoteUser()method provides the username of the current user of theportal The username is generally not considered to be a sensitive piece of infor-

mation; on the contrary, it is normal to use the username extensively as an identifier

of objects and in tables However, you should bear in mind that the usernamemay not be a simple direct representation of the user’s name It may, for example,include the details of the authentication domain that this user is associated with

While you can reasonably expect the username in this form to be unique, sion can arise Consider for example:

confu-dave@example.com dave@paperstack.com

In these two cases, what one colloquially thinks of as the username is “dave”,but in fact two distinct users are identified—one associated with the example.comdomain; the other with paperstack.com

We will not belabor the point, but it is wise to retain the full string returned

by getRemoteUser()to avoid ambiguities

Obtaining a Principal

The principal represents a user (or service, or server) whose identity has beenconfirmed by the portal It is distinct from a username, because there is no prin-cipal for an unauthenticated user Note that in practice getRemoteUser()is likely

to return null for unauthenticated users anyway, because the authentication process

is often the mechanism by which the user is established

The getUserPrincipal()method therefore returns the Principalobject ciated with the current logged-in user, or null if the user has not been logged in

asso-You may not immediately see the need for a separate object to represent this—

surely one could use a combination of the username and an isAuthenticated()

method? However, the principal serves an important purpose when you wish toindicate to another service that our service is entitled to act on behalf of the user

in question

NOTE This sort of situation arises often with portals, because they can gate quite distinct systems into a common interface Take as an example an investment bank’s systems There may be distinct systems for bond and equi- ties trading, and these systems in turn talk to a set of back-end databases.

aggre-When using a portal to unify the systems, users must first present their dentials to the portal, which in turn establishes a Principal, which is passed

cre-to the bond system and the equities system These in turn use it cre-to gain access

to the back-end databases By using the end user’s credentials all the way through the system, a secure audit trail can be maintained, albeit with a per- formance penalty.

The principal is an instance of the java.security.Principalinterface You cancall the getName()method on it, and in general this will return the same stringthat you would retrieve from a call to getRemoteUser(), although it is not required.

In the example given in the previous section, the string returned might be

“dave@example.com” or just “dave”

Using Roles

Portlet roles work in exactly the same way as servlet roles Roles are represented

by strings, and any given user can be assigned to a specific role, or a group ofroles

The idea is that a role name should represent the rights and duties of a userrather than being the privileges assigned So for instance, Manager is a good namefor a role, whereas ListSalaries is not

To determine if a user falls within a given role, call the isUserInRole()methodand pass in the name of the role The method will return trueor falseappropri-ately If the current user is null (i.e., not logged in), this method will always returnfalse

Since the mappings of the native security system may not correspond naturally

to those of the portlet application (or indeed to those of a servlet application),

a facility is provided to allow a security role to be mapped to an additional name,

in effect allowing the developer or deployer to assign aliases to roles

As is normal with servlets, an entry can be placed in the portlet application’sweb.xml deployment descriptor file to specify a<security-role-ref>element for

an existing role name The format is

be tested for the appropriate principal’s role memberships

Single Sign-On Strategies

SSO is essentially a technical solution to a usability problem Users are not good

at remembering several different passwords, and they dislike being made to enter

a password numerous times

For example, the authors have worked for various companies where this is

a problem Dave used to work for a company where there was a separate login tothe workstation, to the e-mail system, to the timekeeping system, to the database,and to each of the six different systems that he was developing interfaces for

The situation is common on the Internet Your bank, auction site, web mailaccount, and so on are likely to have distinct usernames and passwords Someservices have sprung up to try to unify logins between sites Microsoft Passportand the Liberty Alliance are competing standards in this domain; they are SSOsolutions at the interorganizational level

When building an SSO solution for services accessed via portlets, you haveslightly different considerations, and indeed, SSO does not refer to a singletechnology, or even a single strategy for solving the problem There are distinctapproaches, which we will now discuss in the context of portlets

Using True SSO

True SSO is the term we will adopt for the “perfect” solution In this scenario, youruser enters a username and password only once—when logging in to the portal

Problems with this approach arise when legacy systems are involved Most

of our examples will discuss using Kerberos to manage authentication betweenthe portals and external services, but this is a relatively new protocol Older sys-tems can be difficult or expensive to update to accommodate Kerberos oranother standard SSO technology

CAUTION Our examples use the Kerberos v5 software from MIT, as this is the reference implementation of the standard The example code would require changes to work with Microsoft Active Directory.

Using Proxy SSO

Proxy SSO, as the name suggests, uses a proxy system to carry out sign-ons for us

Users log into the portal with their username and password, and this in turnunlocks a store of usernames and passwords for external systems

The advantage of this system is that, as presented, it offers the same userexperience as True SSO However, it is something of a compromise and this cancause administrative problems

The approach necessitates management of the passwords for the systems.Different legacy systems may require password changes at different times Userswill still have to remember (or, dangerously, write down) the individual passwords

so that they can change them when they expire, or alternatively the passwords willneed to be set not to expire at all, which is in itself a security risk For seamlessintegration, the proxy SSO server would need to manage the life cycle for eachusername and password pair If the proxy SSO server had rules for each legacysystem that dictated the password expiration, the range of valid password values,and the ability to change passwords, this could all be managed for the user Theintegration development costs for a project like this would be very high

Because the passwords must be retrieved in order to present them to thelegacy systems, they must be stored by the proxy SSO solution in an encryptedform that decrypts to plaintext This is generally considered undesirable Moredesirable would be a solution that stores a message digest or hash of the password,

so the original password cannot be reconstructed

Using a Common Registry

The common registry approach is something of a compromise between thetrue and proxy SSO solutions While it does not require full implementation of

a GSS-API–compliant system, it does require some changes to any legacy systemsinvolved

The idea is that a central system is used to carry out all authentication, butthat users are prompted for usernames and passwords each time they access

a different system However, subsequent access to the same systems within thelogin session does not require reauthentication

Perhaps the term “Single” Sign-On is a misnomer here, since of course theuser is making multiple login efforts, but because a single username and pass-word combination is required, far less is required of the user In practice this isoften a satisfactory solution, and it has the advantage that it is compatible with

a migration to the True SSO solution as the legacy systems are retired

In a portlet environment, the attraction of this approach is less obvious, since

it is possible that users would be initially presented with a great number of portlets

on their home page, each and every one of which could initially demand a name and password before they can be used!

user-Authenticating with JAAS

We have encountered a small part of the Java Authentication and AuthorizationServices ( JAAS) in our coverage of the Principalobject returned by thegetUserPrincipal()method of the PortletRequestobject

The portlet generally obtains a principal in this manner, so you can get bywithout knowing how to do this manually However, it is enlightening to see themechanism used in practice, and in some SSO scenarios—especially the proxyscenario—it can be necessary.

At the point that you conduct a login, some details of the login mechanism must

be known You cannot generally log in to a Unix system using NTLM (Microsoft)authentication, and most authentication systems provide no discovery mechanism

to determine the protocol in use

JAAS is therefore based on an API called Pluggable Authentication Modules(PAM), which allows you to try a login on a system or systems using a variety ofdifferent protocols As a result, you can conduct a JAAS login, at the end of whichone or more systems may have vouched for your credentials

The protocols to be used are generally specified using a configuration file

This can contain individual or multiple entries

// Kerberos.config ClientAuthentication {

com.sun.security.auth.module.Krb5LoginModule required;

};

ServerAuthentication {

com.sun.security.auth.module.Krb5LoginModule required storeKey=true;

};

Here we have specified two distinct configurations One is for our client, andthe other for a server that we will be demonstrating later in the chapter For theclient authentication, aLoginModulehas been specified, and we have indicatedthat a login using this module is required in order to consider the authenticationsuccessful Additional parameters may be provided (as shown in the server exam-ple, where the storeKeyparameter is specified), but are not necessary for ourlogin example

Login modules are objects that know how to talk the appropriate protocol toestablish a login to a particular type of authentication server—in this case a Kerberosv5 server

NOTE Kerberos v5 is a well-respected enterprise-grade security system from MIT Using brief exchanges of information, Kerberos can determine the iden- tity of users without ever needing to see their password Kerberos can also supply participants with security keys, allowing them to set up a secure chan- nel of communication between participants with a minimal overhead.

Kerberos forms the core of the authentication system in Microsoft Active Directory, and implementations exist for most platforms.

A small set of modules are provided with the Java 2 SDK, and others are able either for free or commercially For example at http://free.tagish.net/jaas/index.jspa set is available that will permit you to authenticate against Windows NTservers using the NTLM protocol, to authenticate using credentials stored in

avail-a text file, or to avail-authenticavail-ate avail-agavail-ainst credentiavail-als stored in avail-a davail-atavail-abavail-ase tavail-able.The login modules in the Java 2 Standard Edition 1.4.2 SDK are contained in thecom.sun.security.auth.modulepackage These modules include the Kerberos loginmodule we are using, an NT login module, a Unix login module, and a Java Namingand Directory Interface (JNDI) login module

The example application to conduct a JAAS login in Kerberos follows:

this.password = password;

} public void handle(Callback[] callbacks) { for (int i = 0; i < callbacks.length; i++) { Callback callback = callbacks[i];

if (callback instanceof NameCallback) { ((NameCallback) callback).setName(principal);

} else if (callback instanceof PasswordCallback) { ((PasswordCallback) callback).setPassword(

password.toCharArray());

} } } private String principal;

private String password;

} public static void setKerberosSystemProperties() { System.setProperty(

"java.security.auth.login.config",

"./Kerberos.config");

System.setProperty("java.security.krb5.realm", "JETSPEED");

System.setProperty("java.security.krb5.kdc", "jetspeed");

System.setProperty("sun.security.krb5.debug", "false");

} public static Subject jaasLogin(

String context, String principalName, String password) throws LoginException { System.out.println("Acquiring context");

LoginContext lc = new LoginContext(

context, new KerberosCallbackHandler(principalName, password));

System.out.println("Logging in ");

try { lc.login();

System.out.println("OK, Logged in.");

System.out.println(

"Retrieving and returning the Subject from the login context.");

return lc.getSubject();

} catch (Exception e) { throw new LoginException("Login failed: " + e);

} } public static void main(String[] argv) { String principalName = "dave";

String password = "MyPassword";

setKerberosSystemProperties();

System.out.println("Attempting jaasLogin");

try { Subject subject = jaasLogin("ClientAuthentication", principalName, password);

System.out.println("Logged in " + subject);

} catch (Exception e) { System.out.println("JaasLogin Failed: " + e);

e.printStackTrace();

}

System.out.println("OK, Done.");

} }

In the main method, we provide a principal name (username) and password

We then invokesetKerberosSystemProperties()to specify Kerberos configurationvalues These could equally well be provided on the command line or extractedfrom a properties file, but for the sake of clarity we’re setting them explicitly inthe code First, we specify the location of the configuration file to use:

System.setProperty("java.security.krb5.kdc", "jetspeed");

Kerberos Terminology

Kerberos distinguishes between the realm and the controller that a user logs

in to The controller is a physical machine, identified by a name—for example,the Internet name example.com would be a suitable identifier for a controller.Alternatively an IP address such as 192.168.0.1 could be used The proper namefor such a controller is a Key Distribution Center (KDC) You can have anynumber of KDCs on a network

The realm is the logical group that the users log in to For example, a smallcompany might easily use its domain name, so users would log in to the exam-ple.com domain This name does not have to have a DNS style name, however,

so “example” is an equally valid realm name

In a larger organization, realms are likely to be organized in a way that reflectsthe company’s hierarchy, so one set of users might log in to the ACCOUNTSrealm while another logs in to the HUMANRESOURCES realm A user “bob”who has an account in the HUMANRESOURCES realm is always represented asbob@HUMANRESOURCES even if the physical machine he uses to carry out

a login is hr.example.com

For each realm there will be a master KDC machine (which optionally may bethe master for several realms) Principals are managed on this master machine.

The master(s) can then distribute key information to any number of slaveKDCs to distribute the burden of authentication to a manageable degree

This specifies that additional debugging information should be switched off(the default) Setting this flag to trueis a recommended first step when debuggingproblems:

System.setProperty("sun.security.krb5.debug", "false");

We then invoke the jaasLogin()method to retrieve a subject The methodestablishes aLoginContextobject, which is populated with the name of the entryfrom our configuration file (ClientAuthentication) and aCallbackHandler.When the login method is invoked on the LoginContextobject, the LoginModulespecified in the configuration file is instantiated This then establishes a connection

to the appropriate server, and carries out the appropriate login conversation (inour case to a Kerberos 5 server) When additional information is required to com-plete the login, the handle(Callback[])method of our CallbackHandler

public void handle(Callback[] callbacks)

throws IOException, UnsupportedCallbackException

is invoked with the array populated with suitable Callbackobjects It is the client’sresponsibility to populate these Callbackobjects with appropriate data

In the case of a Kerberos 5 login, we require only a username and password

The following code carries out this task:

for (int i = 0; i < callbacks.length; i++) { Callback callback = callbacks[i];

if (callback instanceof NameCallback) { ((NameCallback) callback).setName(principal);

} else if (callback instanceof PasswordCallback) { ((PasswordCallback) callback).setPassword(

password.toCharArray());

} }

If the login were being carried out on a Swing application (for instance), thehandler could block the login process and prompt the user for a password andusername at runtime For a web application, however, the approach of promptingthe user for details first and then populating a callback handler prior to login

is preferable Disposing of such a handler as soon as it has served its purpose is

advisable, since otherwise the username and password will be retained in cleartext in memory indefinitely.

Once the LoginContextobject had completed its login method successfully(an exception is thrown if the login cannot be completed), aSubjectobject can

be obtained from the context and returned

A subject is used to represent a single entity In our example, the entity is theuser of the system, but it can be a service, or a server on a system Whereas a prin-cipal represents an entity authenticated against a single system, the subject canrepresent an entity authenticated simultaneously against a variety of differentsystems

The subject can therefore contain a number ofPrincipalobjects, and whenthe subject is printed via itstoString()method, you should see something likethis:

Attempting jaasLogin Acquiring context Logging in

OK, Logged in.

Retrieving and returning the Subject from the login context.

Logged in Subject:

Principal: dave@JETSPEED Private Credential: Ticket (hex) = 0000: 61 81 E5 30 81 E2 A0 03 02 01 05 A1 0A 1B 08 4A a 0 J 0010: 45 54 53 50 45 45 44 A2 1D 30 1B A0 03 02 01 00 ETSPEED 0 0020: A1 14 30 12 1B 06 6B 72 62 74 67 74 1B 08 4A 45 0 krbtgt JE 0030: 54 53 50 45 45 44 A3 81 AF 30 81 AC A0 03 02 01 TSPEED 0 0040: 10 A1 03 02 01 01 A2 81 9F 04 81 9C C6 44 4B B7 .DK 0050: 9B AA 75 AA 9E B8 51 0F 10 95 AA AD 9C 58 3A 6F u Q X:o 0060: 42 A7 FF 09 D6 9F 17 81 CF B9 3F 02 84 47 90 B0 B ? G 0070: 92 DD FF F5 9B 29 09 97 F6 90 94 A2 E6 98 3E 0B .) > 0080: 17 B0 D9 25 FE 08 98 17 6F 9F 36 A1 75 00 18 4B .% o.6.u K 0090: DA D0 90 E5 29 F3 4A B0 99 95 B8 97 37 E7 30 34 ).J 7.04 00A0: 22 16 EC 3E 51 12 F4 59 55 E3 6F 21 31 3B E2 3B " >Q YU.o!1;.; 00B0: 1B 97 2D 79 71 0F 3B 8E 3A AA C7 F2 71 A9 E9 F3 -yq.;.: q 00C0: F7 05 8D 74 3F 7F BB 63 0D AE 5A 31 6E 35 A5 EE .t? c Z1n5 00D0: 81 D0 C2 32 FE EB 93 61 45 6B A4 8F 41 C9 4E 64 .2 aEk A.Nd 00E0: 8D 81 61 B7 AD B6 FA F9

Client Principal = dave@JETSPEED Server Principal = krbtgt/JETSPEED@JETSPEED Session Key = EncryptionKey: keyType=1 keyBytes (hex dump)=

0000: D0 F1 15 A7 A7 49 52 16 Forwardable Ticket false Forwarded Ticket false

Proxiable Ticket false Proxy Ticket false Postdated Ticket false Renewable Ticket false Initial Ticket false Auth Time = Sat Apr 17 16:02:17 BST 2004 Start Time = Sat Apr 17 16:02:17 BST 2004 End Time = Sun Apr 18 02:02:17 BST 2004 Renew Till = Null

Client Addresses Null

OK, Done.

You might be surprised by just how much information the subject contains

There are principals here to represent the user (as expected) dave@JETSPEED,and to represent the client (who happens to be the same person) And there is

a principal to represent the server from which we obtained authentication These

in turn contain “ticket” information, which independently allows us to confirmthe identity of a principal

A large part of the complexity in JAAS is due to the need to support otherwiseincompatible standards The protocol for logging into a Windows NT domain dif-fers in almost every respect to those required to log into a Unix system Even so,the fundamental steps (prepare appropriate module, configure, log in) are simpleonce you understand the context in which they operate

The aim of Kerberos is to avoid the need for users ever to send their password

in a retrievable form over the network In order to authenticate, the client followsthese steps:

1 The client asks the server for a ticket-granting ticket (TGT) The request

is unencrypted, and specifies the username of the client It does notspecify the password

2 The server issues a TGT to the client A TGT contains an encrypted “sessionkey.” This can be decrypted using the client’s password only Therefore,only our client can obtain the session key even if someone else has beenlistening to the exchange