Security and Authorization

issues
 4 levels or senses of the security
issue to look at
• Authentication
• Authorization
• Integrity
• Confidentiality
 Security
• Client wants to be sure she is talking to a
legitimate server (authentication) and also
wants to make sure information passes is
confidential. The server wants to make
sure the client is who she claims to be,
and that information remains confidential.
Both sides want to be sure the information
passes arrives without tampering.
 2.2 security
• Web servers are not required to implement
all servlet 2.2 API security mechanisms to
be 2.2 compliant.
• Some implement just parts of it and some
implement none at all.
• A server must implement all to be J2EE
compliant.
 Role-based authentication
• Tags in web.xml and other xml files can
specify roles and restrict resource access
to those in certain roles.
• The deployment descriptor (web.xml)
specifies the type of access granted to
each role but doesn’t map roles to users.
Server-specific tools used during
application deployment assign roles, which
may come from text, db tables, OS, server
files (like tomcat users) and so on.
 Salary servlet example
• We wish to restrict access to a servlet that gives out salary information to
managers:

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class SalaryServer extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/plain");
PrintWriter out = res.getWriter();
out.println("Top-secret information:");
out.println("Everyone else gets paid more than you!");
}
}
 Tomcat roles
• On tomcat, roles are assigned in a tomcat-
users file in the conf directory of tomcat.
(This was true at the time the text was
written and seems still to be the case).
• On another server (container), another
sort of mechanism might define these
roles.
 tomcat-users.xml file in conf
directory
• This is already defined and has some entries in it
presumably for jsp or servlet examples that come with
Tomcat.
• You should have added yourself to it as admin, or looked
at it already to get an admin pw, to run the manager utility
we looked at earlier.
• I added the tomcat-users from the text chapter 8 example
file to my users.
• The web.xml file security constraint tag then specifies
which security roles may access a resource. In the DTD,
tags are ordered: <security-constraint>, <login-
config>, then <security-role>
• The text acknowledges that the web.xml does get a bit
complicated and that for handling security issues a
graphical manipulation tool (like your proj 2) might be
best.
 Security constraint
• The deployment descriptor (next slide) protects the
resource (in this example, a servlet named secret) GET
and POST methods from anyone who hasn’t logged in
as manager using BASIC authentication. The rest of the
site is not restricted.
• The security constraint tag protects a web resource
collection so access is only granted for roles specified in
<auth-constraint>
• Each <web-resource-collection> contains a name, any
number of urls to protect and any number of http
methods for which access is restricted. url patterns may
use wildcard characters.
 web.xml file additions for this example
<security-constraint>
<web-resource-collection>
<web-resource-name>
SecretProtection
</web-resource-name>
<url-pattern>
/servlet/SalaryServer
</url-pattern>
<url-pattern>
/servlet/secret
</url-pattern>
<http-method>
GET
</http-method>
<http-method>
POST
</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>
manager
</role-name>
</auth-constraint>
</security-constraint>
 web.xml file additions
<login-config>
<auth-method>
BASIC <!– coices are: BASIC, DIGEST, FORM, CLIENT-
CERT -->
</auth-method>
<realm-name>
Default <!-- optional, only useful for BASIC -->
</realm-name>
</login-config>
<security-role>
<role-name>
manager
</role-name>
</security-role>
 conf/tomcat-users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
<user name="Dilbert" password="dnrc" roles="engineer" />
<user name="Wally" password="iluvalice"
roles="engineer,slacker" />
<user name="MrPointyHair" password="MrPointyHair"
roles="manager,slacker" />

</tomcat-users>
Server prompts for user info
SalaryServer gives info
 Once logged in
• You may continue to access resources
here after login without having to reenter
pw.
• As mentioned in earlier ppts, the client
browser session hands the server the
name/pw each time a page is requested.
If Dilbert tries to login
Retrieving authorization information
• Servlet API supports two methods getRemoteUser() and
getAuthType() from chapter 4 for getting user
information.
• API 2.2 introduces a new method (on
HttpServletRequest) getUserPrincipal(). A principal is
the entity being authenticated, a group, a login, a
corporation.
• getRemoteUser is basically available for CGI
compatibility and we looked at this briefly in chapter 7.
getUserPrincipal() is the preferred way to authenticate a
user.
• isUserinRole() returns true only if the user is in a
particular role.
Retrieving authorization information
• These methods allow servlets to handle some of
the authentication process. Role aliases can be
used in the deployment descriptor.
• The following excerpt would enable the servlet to
use the alias mgr for the role manager. This
would be useful for integrating servlets from
different web applications. Aliases are
configured per servlet.
<servlet>…</servlet-class><security-role-
ref><role-name>mgr</role-name><role-
link>manager</role-link> </security-role-ref>
</servlet>
 Getting client info
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();

out.println("<HTML><HEAD><TITLE>AuthenticationSnoop</TITLE></HEAD><BODY
>");

out.println("<H1>This is a password protected resource</H1>");

out.println("<PRE>");
out.println("User Name: " + req.getRemoteUser());
String name = (req.getUserPrincipal() == null) ?
null : req.getUserPrincipal().getName();
out.println("Principal Name: " + name);
out.println("Authentication Type: " + req.getAuthType());
out.println("Is a Manager: " + req.isUserInRole("manager"));
out.println("</PRE>");
out.println("</BODY></HTML>");
}
This servlet running in tomcat. (Obviously, we
need to combine this example with a Basic or
Form-based authentication)
Pasting code from AuthenticationSnoop into
SalaryServer
Pasting code from AuthenticationSnoop into
SalaryServer
 Form-based authentication
• Servlets can rely on html forms to do
authentication as well. A friendly login
page greets site visitors. This is nicer than
the generic prompt the browser gives in
the server’s authentication scheme
previously described.
• Form-based authentication is built into the
servlet 2.2 API.
 Form-based authentication
• If the server receives a request for a
restricted resource, it looks to see if the
user has logged in. If it finds a Principal
(from last example) it compares with those
Principal values allowed to access the
recource. If no principal is located the
client is redirected to a login page.
 changes to login-config for web.xml
<login-config>
<auth-method>
FORM
</auth-method>
<form-login-page>
/loginform.html
</form-login-page>
<form-error-page>
/errorpage.html
</form-error-page>
</form-login-page>
</login-config>
 Html form
• Must use POST to server with action
j_security_check and values j_username
and j_password
<HTML>
Html form
<TITLE>Login</TITLE>
<BODY>
<FORM METHOD=POST ACTION=j_security_check>
<CENTER>
<TABLE BORDER=0>
<TR><TD COLSPAN=2>
<P ALIGN=center>
Welcome! Please enter your Name<br>
and Password to log in.
</TD></TR>
<TR><TD>
<P ALIGN=right><B>Name:</B>
</TD>
<TD>
<P><INPUT TYPE=TEXT NAME="j_username" VALUE="" SIZE=15>
</TD></TR>
<TR><TD>
<P ALIGN=RIGHT><B>Password:</B>
</TD>
<TD>
<P><INPUT TYPE=PASSWORD NAME="j_password" VALUE="" SIZE=15>
</TD></TR>
<TR><TD COLSPAN=2>
<CENTER>
<INPUT TYPE=submit VALUE=" OK ">
</CENTER>
</TD></TR>
</TABLE>
</FORM>
</BODY></HTML>
In IE
 Error page
<HTML>
<TITLE>Login Denied</TITLE>

<BODY>
Sorry, your login was denied.
Please hit the Back button to try again.
</BODY></HTML>
Error page
I get null pointer exceptions trying to run the
last example… I have to revisit this example
 CustomAuthorization
• A servlet can handle its own custom
authorization procedures, looking for
names/passwords in a database for
example. In a limited context, this servlet
might build a hashtable of priviledged
users:
users.put("Wallace:cheese", "allowed");
users.put("Gromit:sheepnapper", "allowed");
users.put("Penguin:evil", "allowed");
CustomAuth
CustomAuth
An invalid login yields an error
 Custom Authorization with html forms
<HTML>
<TITLE>Login</TITLE>
<BODY>
<FORM ACTION=/servlet/LoginHandler METHOD=POST>
<CENTER>
<TABLE BORDER=0>
<TR><TD COLSPAN=2>
<P ALIGN=CENTER>
Welcome!<br>
Please enter your Account Number,<br>
Password, and PIN to log in.
</TD></TR>
<TR><TD>
<P ALIGN=RIGHT><B>Account:</B>
</TD>
<TD>
<P><INPUT TYPE=TEXT NAME="account" VALUE="" SIZE=15>
</TD></TR>
<TR><TD>
<P ALIGN=RIGHT><B>Password:</B>
</TD>
<TD>
<P><INPUT TYPE=PASSWORD NAME="password" VALUE="" SIZE=15>
</TD></TR>
<TR><TD>
<P ALIGN=RIGHT><B>PIN:</B>
</TD>
<TD>
<P><INPUT TYPE=PASSWORD NAME="pin" VALUE="" SIZE=15>
</TD></TR>
<TR><TD COLSPAN=2>
<CENTER>
<INPUT TYPE=SUBMIT VALUE=" OK ">
</CENTER>
</TD></TR>
</TABLE>
</FORM>
</BODY></HTML>
Custom Authorization with html forms
 Custom Authorization with html forms

• A client who tries to get to the resource

without logging in is redirected to this page
and then directed back to the protected
resource.
• Secret data is revealed in the protected
resource only if session information
indicates that the client has already logged
in.
 ProtectedResource
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ProtectedResource extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/plain");
PrintWriter out = res.getWriter();
// Get the session
HttpSession session = req.getSession();
// Does the session indicate this user already logged in?
Object done = session.getAttribute("logon.isDone"); // marker object
if (done == null) {
// No logon.isDone means she hasn't logged in.
// Save the request URL as the true target and redirect to the login page.
session.setAttribute("login.target",
HttpUtils.getRequestURL(req).toString());
res.sendRedirect("/login.html");
return; }
// If we get here, the user has logged in and can see the goods
out.println("Unpublished O'Reilly book manuscripts await you!"); }}
When ProtectedResource is
entered as URL:
 LoginHandler servlet returns true
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
// Get the user's account number, password, and pin
String account = req.getParameter("account");
String password = req.getParameter("password");
String pin = req.getParameter("pin");
// Check the name and password for validity
if (!allowUser(account, password, pin)) {////see below …a dummy method that doesn’t really check
out.println("<HTML><HEAD><TITLE>Access Denied</TITLE></HEAD>");
out.println("<BODY>Your login and password are invalid.<BR>");
out.println("You may want to <A HREF=\"/login.html\">try again</A>");
out.println("</BODY></HTML>"); }
else {
// Valid login. Make a note in the session object.
HttpSession session = req.getSession();
session.setAttribute("logon.isDone", account); // just a marker object… sets login complete as session value

// Try redirecting the client to the page he first tried to access

try {
String target = (String) session.getAttribute("login.target");
if (target != null) {
res.sendRedirect(target);
return; } }
catch (Exception ignored) { }

// Couldn't redirect to the target. Redirect to the site's home page.

res.sendRedirect("/");
} }
protected boolean allowUser(String account, String password, String pin) {
return true; // trust everyone }}
After being cleared by
LoginHandler
 Digital certificates
• Digital certificates provide a higher level of
authentication, confidentiality and integrity than BASIC or
FORM-based authentication.
• Public key cryptography is the mechanism by which data
is transmitted. In such a system, both sides have two
keys, a public key and a private key, used to encrypt and
decrypt information. The public key is freely distributed.
The keys are related but one can’t be derived from the
other.
• Large prime numbers are used to generate pairs of
asymmetric keys: each can decode a message encoded
with the other. Keys may be 1024 or 2048 bits in length.
 Digital certificates
• Keys are too big to type in manually, and
are stored on disks as “digital certificates”.
• Private keys are stored encrypted on disk
protected by a passphrase.
• Digital certificates can be issued by 3rd
party vendors or generated by software.
• Secure-aware applications like browsers
and servers can load the certificates.
 Digital certificates
• How is authentication provided? The keys are
asymmetric… a message encoded/decoded with a
private key can also be encoded/decoded with the
corresponding public key to guarantee authorship.
• It does take more work to do this, so often after identities
have been established with asymmetric keys, symmetric
keys are exchanged for passing information.
• Messages sent using large (>=128 bits) keys are very
secure.
• Third party certificate authorities often “vouch for” parties
exchanging public keys. There are companies
(VeriSign) which provide levels of increased guarantee
or trust at increasing price.
 Secure Sockets Layer
• The SSL sits between application-level (HTTP)
and lower level transport protocol (TCP/IP).
• It uses public key cryptography to encrypt all
client/server communication. This is the de-
facto security standard for online
communication.
• This forms the basis for TLS (Transport Layer
Security) currently under development by the
IETF.
 Secure Sockets Layer
• SSL V2 provides authentication of the server, confidentiality and
integrity.
• A user connects to a secure site using HTTPS (= HTTP+SSL)
protocol.
• The server signs its public key with its private key and returns it to
the browser.
• The browser uses the server’s public key to verify that the person
who signed the key owns it.
• The browser checks to see if a certificate authority signed the key.
If not, the browser asks the user if the key can be trusted and
proceeds.
• The client generates an asymmetric DES key for the session which
is encrypted with the server’s public key and sent to the server. This
new key is used to encrypt subsequent transactions.
• Once you have obtained and installed an appropriate server
certificate, and appropriately configured the server, all the SSL
details are handled seamlessly and beloiw the layer of servlets.
 SSL3
• SSL V3 provides client authentication providing support
for client certificates.
• Clients are supplied certificates like servers. After the
client has authenticated the server, the server requests
the client’s certificate. The server performs the same
authorization process the client just completed. Browsers
often require a client pw before sending a certificate.
• This does provide an additional seamless layer of
security, but now clients must obtain and install
certificates and servers must (often) maintain a database
of public keys, as well as implementing SSL V3.
 web.xml
<securtiy-constraint>
<web-resource-collection>
…</web-resource-collection>
<auth-constraint>
<role-name>
manager
</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>
CONFIDENTIAL
</transport-guarantee>
</user-data-constraint>
</security-constraint>
 SSL3
• The deployment descriptor indicates that the
application requires HTTPS.
• The transport guarantee is INTEGRAL or
CONFIDENTIAL. The later entails the former.
Integral means no change has taken place to
the message in transit and the latter means no
unauthorized third party has seen the
transmission.
• The server may implement the security levels.
Generally, 56-bit DES encryption is considered
sufficient for integral but not for confidential.
 SSL3
• May be secure enough to support legally binding
contracts and online voting.
• A change to the login-config tag enables authentication
based on client certificates.
<login-config>
<auth-method>
CLIENT-CERT
</auth-method>
</login-config>
• The client will not see a login page but the browser will
prompt for a pw to unlock their certificate before it is sent
to the server.
 SSL3
• SSL details are handled by the server. A servlet may
retrieve SSL information if it likes.
• ServletRequest.isSecure() returns a boolean indicating if
the connection to the client is secure.
• There is no standard way to request the encryption
algorithm or bit length of the symmetric key. Expected in
Servlet 2.3 will be methods to retrieve this information.
• The principal name discussed earlier can be gleaned
from the client certificate.
• Anytime a client certificate is sent to a server a servlet
can retrieve the client’s certificate as a request attribute.
• servlet.request.X509Certificate will return a
java.security.cert. X509Certificate object.
Authorization request from X509Snoop
using roles in Tomcat-users
X509Snoop looks at a client
certificate
 X509Snoop looks at a client certificate
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/plain");
PrintWriter out = res.getWriter();

X509Certificate[] certs = (X509Certificate[])

req.getAttribute("javax.servlet.request.X509Certificate");
if (certs != null) {
for (int i = 0; i < certs.length; i++) {
out.println("Client Certificate [" + i + "] = "
+ certs[i].toString());
}
}
else {
if ("https".equals(req.getScheme())) {
out.println("This was an HTTPS request, " +
"but no client certificate is available");
}
else {
out.println("This was not an HTTPS request, " +
"so no client certificate is available"); } } }
 remarks
• Although the X509Snoop compiles and
runs I couldn’t figure out how to get the
client to send a certificate, ie. To establish
an https instead of http.
SalaryServer with Client-cert