Security and Authorization issues 4 levels or

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 J 2 EE 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. http. *; public class Salary. Server extends Http. Servlet { public void do. Get(Http. Servlet. Request req, Http. Servlet. Response res) throws Servlet. Exception, IOException { res. set. Content. Type("text/plain"); Print. Writer out = res. get. Writer(); out. println("Top-secret information: "); out. println("Everyone else gets paid more than you!"); } }

Tomcat roles • On tomcat, roles are assigned in a tomcatusers 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: , , then • 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 • Each 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 Secret. Protection /servlet/Salary. Server /servlet/secret GET POST manager

web. xml file additions BASIC Default manager

conf/tomcat-users. xml

Server prompts for user info

Salary. Server 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 get. Remote. User() and get. Auth. Type() from chapter 4 for getting user information. • API 2. 2 introduces a new method (on Http. Servlet. Request) get. User. Principal(). A principal is the entity being authenticated, a group, a login, a corporation. • get. Remote. User is basically available for CGI compatibility and we looked at this briefly in chapter 7. get. User. Principal() is the preferred way to authenticate a user. • is. Userin. Role() 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. …mgrmanager

Getting client info public void do. Get(Http. Servlet. Request req, Http. Servlet. Response res) throws Servlet. Exception, IOException { res. set. Content. Type("text/html"); Print. Writer out = res. get. Writer(); out. println(" "); out. println("This is a password protected resource"); out. println("

"); out. println("User Name: " + req. get. Remote. User()); String name = (req. get. User. Principal() == null) ? null : req. get. User. Principal(). get. Name(); out. println("Principal Name: " + name); out. println("Authentication Type: " + req. get. Auth. Type()); out. println("Is a Manager: " + req. is. User. In. Role("manager")); out. println("

This servlet running in tomcat. (Obviously, we need to combine this example with a Basic or Formbased authentication)

Pasting code from Authentication. Snoop into Salary. Server

Pasting code from Authentication. Snoop into Salary. Server

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 FORM /loginform. html /errorpage. html

Html form • Must use POST to server with action j_security_check and values j_username and j_password

Html form

In IE

Error page Sorry, your login was denied. Please hit the Back button to try again.

Error page

I get null pointer exceptions trying to run the last example… I have to revisit this example

Custom. Authorization • 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");

Custom. Auth

Custom. Auth

An invalid login yields an error

Custom Authorization with html forms

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.

Protected. Resource import java. io. *; import java. util. *; import javax. servlet. http. *; public class Protected. Resource extends Http. Servlet { public void do. Get(Http. Servlet. Request req, Http. Servlet. Response res) throws Servlet. Exception, IOException { res. set. Content. Type("text/plain"); Print. Writer out = res. get. Writer(); // Get the session Http. Session session = req. get. Session(); // Does the session indicate this user already logged in? Object done = session. get. Attribute("logon. is. Done"); // marker object if (done == null) { // No logon. is. Done means she hasn't logged in. // Save the request URL as the true target and redirect to the login page. session. set. Attribute("login. target", Http. Utils. get. Request. URL(req). to. String()); res. send. Redirect("/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 Protected. Resource is entered as URL:

Login. Handler servlet returns true public void do. Post(Http. Servlet. Request req, Http. Servlet. Response res) throws Servlet. Exception, IOException { res. set. Content. Type("text/html"); Print. Writer out = res. get. Writer(); // Get the user's account number, password, and pin String account = req. get. Parameter("account"); String password = req. get. Parameter("password"); String pin = req. get. Parameter("pin"); // Check the name and password for validity if (!allow. User(account, password, pin)) {////see below …a dummy method that doesn’t really check out. println(""); out. println("Your login and password are invalid.
"); out. println("You may want to try again"); out. println(""); } else { // Valid login. Make a note in the session object. Http. Session session = req. get. Session(); session. set. Attribute("logon. is. Done", 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. get. Attribute("login. target"); if (target != null) { res. send. Redirect(target); return; } } catch (Exception ignored) { } // Couldn't redirect to the target. Redirect to the site's home page. res. send. Redirect("/"); } } protected boolean allow. User(String account, String password, String pin) { return true; // trust everyone }}

After being cleared by Login. Handler

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 3 rd 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 (Veri. Sign) 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 V 2 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.

SSL 3 • SSL V 3 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 V 3.

web. xml … manager CONFIDENTIAL

SSL 3 • 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.

SSL 3 • 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. CLIENT-CERT • 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.

SSL 3 • SSL details are handled by the server. A servlet may retrieve SSL information if it likes. • Servlet. Request. is. Secure() 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. X 509 Certificate will return a java. security. cert. X 509 Certificate object.

Authorization request from X 509 Snoop using roles in Tomcat-users

X 509 Snoop looks at a client certificate

X 509 Snoop looks at a client certificate public void do. Get(Http. Servlet. Request req, Http. Servlet. Response res) throws Servlet. Exception, IOException { res. set. Content. Type("text/plain"); Print. Writer out = res. get. Writer(); X 509 Certificate[] certs = (X 509 Certificate[]) req. get. Attribute("javax. servlet. request. X 509 Certificate"); if (certs != null) { for (int i = 0; i < certs. length; i++) { out. println("Client Certificate [" + i + "] = " + certs[i]. to. String()); } } else { if ("https". equals(req. get. Scheme())) { 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 X 509 Snoop 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.

Salary. Server with Client-cert