Professional Documents
Culture Documents
Web Application Security 102
Web Application Security 102
01/04/2007
Agenda
? ? ?
? ? ?
General security issues Web-tier security requirements and schemes HTTP basic authentication based web-tier security scheme Form-based authentication based web-tier security scheme Declarative authorization Programmatic authorization Programmatic authentication
2
So what are going to talk about in this session? First, we will talk about general web-tier security issues that need to be thought about when developing and deploying web applications. Then we will talk about in a bit concretely what the web-tier security requirements are and what schemes are available to meet those requirements. And we will look into two most important security schemes used at web-tier: HTTP basic authentication based web-tier security scheme and Formbased authentication based web-tier security scheme. People call these simply Basic authentication and Form-based authentication but they cover more than just authentication, in fact, they address not only authentication but also access control and data confidentiality, hence the reason why I call them as web-tier security schemes. We will then talk about two authorization schemes at web-tier: declarative and programmatic authorization. And finally I will talk about how you can perform programmatic authentication as well even though this is rarely used in practice.
01/04/2007
01/04/2007
Making sure a user is who he claims he is Making sure resources are accessible only to users who have access privilege The user has to be authenticated first Protecting the sensitive data from prying eyes while it is on the wire
4
Confidentiality (Privacy)
These are general security issues which we talked about during the security basics session. So let's just quickly review them here again. First, in a networking environment, a user (or program entity) has to prove his/her (its) identity. And we call it authentication. So by using appropriate authentication scheme, we can be assured that a user (or program entity) is in fact who he/she (it) claims he/she (it) is. Next, authorization. Authorization is the same thing as access control. Authorization is a process of making sure a resource gets accessed only by a user who has access privilege. And of course, it is assumed that the user has been authenticated already. Confidentiality is sometimes called privacy and it means that the data should be accessible only to the party the data is intended. It means nobody can access the data while the data is on the wire.
01/04/2007
01/04/2007
If an unauthenticated user tries to access access controlled web resource, web container will automatically ask the user to authenticate himself first Once the user authenticated, web container (and/or web components) then enforces access control
Preventing attackers from changing or reading sensitive data while it is on the wire
Now what are the security requirements we have to be concerned about at web-tier? First we have to be concerned about how to prevent unauthorized users from accessing protected or access controlled web resources. By the way, as we will see later, these access controlled web resources are represented by URL's at web-tier. So at web-tier, when an unauthenticated user tries to access access controlled web resource, web container automatically asks the user to authenticate himself first. Once the user is authenticated, the container then performs the access control checking to see if the user in fact belongs to a group called a role who has a privilege to access the resource. We also have to be concerned about preventing attackers from changing or reading data while the data is on the wire. For example, you certainly want to makes sure nobody can read the credit card number while it is being transported from your browser to the web server. In this case, the data should be encrypted using SSL.
01/04/2007
typically through browser interface user identity information usually means username and password this is called logging in
So as we talked about, web-tier security scheme has to provide authentication scheme so that the web server knows that the user is who he claims he is. In order to provide authentication scheme at web-tier, a few things need to be addressed. First, how to collect user identity information from an end user needs to be addressed. In other words, a logging-in mechanism needs to be provided. The most popular form of user identity information for Web application is username and password pair. Then the collected user identity information needs to be transported from the browser to the web server. Now we have to be concerned about confidentiality of the password here. And as we will see later on, you can use SSL if you want to pass the password securely, meaning with confidentiality.
01/04/2007
Web container checks if collected user identity matches with the one in the backend security database These backend security database are called Realms Realms maintain ? Username, password, roles, etc. How these realms are organized and managed are product and operational environment dependent ? LDAP, RDBMS, Flat-file, Solaris PAM, Windows AD 8
Now once the web server receives the collected user identity information, it then has to perform the identity checking. That is, it checks if the collected user identity matches one of the identities maintained in the backend security database. By the way, these backend security database is called a realm. In fact, there could be multiple realms per each operational environment. So what is a realm? A realm maintains username, password, and roles information. And realms can be maintained in many different forms. For example, username, password, and roles information can be maintained in LDAP server, relational database, or even in a flat file as we will see an example of it in Tomcat's users-xml file.
01/04/2007
Using internally maintained session state, web container knows if the caller of subsequent HTTP requests has been authenticated Web container also creates HttpServletRequest object for subsequent HTTP requests ? HttpServletRequest object contains security context information Principal, Role, Username 9
Now one more thing that a web container does rather behind the scene for you is to keep track of previously authenticated users for further HTTP operations. In other words, once a user is authenticated, the fact that he has been authenticated is maintained as a internal session state by the container. So the user does not have to re-login every time he sends subsequent HTTP requests. In fact, the container does even more. For each HTTP request coming in, the container will create HttpRequestServlet object for you and you can find out some security context information from that HttpRequestServlet object. For example, you can find out Principal information of the user, or you can find out if the user belongs to a particular role, or you can find out the username of the user.
01/04/2007
Web application developer and/or deployer specifies access control to web resources
10
Web-tier security scheme should also address access control. That is, it should allow deployer or developer of the web application to specify what type of user (roles) can access what resource. In fact, as we will see later on, web-tier security schemes allows both declarative and programmatic access control.
01/04/2007
Providing confidentiality of the sensitive data that is being transported over the wire
Between browser and web server Example: Credit card number Using SSL
11
Finally web-tier security scheme should address data confidentiality. That is, it should provide a scheme in which the confidentiality of the sensitive data such as credit card number should be protected from the prying eyes while they are being transported between a browser and web server. Again, SSL is the technology that will be used here to provide that protection.
01/04/2007
with or without SSL with or without SSL Has to use SSL Does not need to use SSL
12
There are four authentication schemes at web-tier: HTTP basic authentication, Form-based authentication, certificate-based authentication, and digest authentication. These authentication schemes are basically categorized in terms of how a browser collects user identification information and supply them to the web container, that is, how to perform the logging-in process. For example, in basic authentication scheme, browser displays a default dialog box prompting a user to enter user name and password while in certificate-based authentication, the browser has to provide client certificate to the web container. Now basic and form-based authentication can be done either with SSL or without SSL. Here, note that the SSL is used for confidentiality of password not for client authentication. Client certificate based authentication method should use SSL for sending client certificate to the web server while digest authentication does not need SSL since the password will be in the form of message digest anyway, thus already secure.
01/04/2007
01/04/2007
Web server collects user identification (user name and password) through a browser provided dialog box Not secure since user name and password are in easily decode'able form over the wire
Now let's talk about HTTP basic authentication a bit. As I mentioned already, in HTTP basic authentication, when a user tries to access access controlled web resource and the user has not been authenticated yet, the web server will instruct the browser to display default dialog box prompting user name and password from the user. In fact, the web server will keep instructing the browser to display the dialog box until valid username and password get provided, that is, until authentication succeeds. Once user name and password are entered by the user, they are transported to the web server in what is called Base64 encoded form. Because Base64 encoding scheme is a very simple and well-known, anybody can capture the traffic while it is on the wire (this is called snooping) and can easily decode it in order to get the user's password. That is, it is not secure. Now in order to make the password to be securely protected while it is on the wire, you need to encrypt it and SSL is the most popular method of doing it.
01/04/2007
Now let's go over the steps you have to take as a web -tier component developer and deployer to provide basic authentication. Form-based authentication follows pretty much the same steps except you have to create custom login page and custom login failure page as well. First it is assumed that a system administrator set up backend database of username, password and roles. And, as was mentioned before, these set of username, password, and roles for a particular domain is called a realm. Second, you as a developer of web application has to tell web server that you are using basic authentication. Third, you as a developer of web application has to tell the web server which web resources need to be access controlled (or protected). Fourth, you as a developer of web application has to tell the web container which web pages should be available only with SSL. That is, if your web application need to get credit card information from the browser, you want to make sure any data that is being transported between the browser and container is sent as SSL encrypted data, thus providing confidentiality. So let's go over each of these steps one by one.
01/04/2007
Schemes, APIs, and tools for setting up usernames, passwords, and roles (realms) are web container and operational environment specific
Flat-file based, Database, LDAP server Passwords could be in either encrypted or unencrypted form default: file, unencrypted form Relational database (via JDBCRealm) LDAP server (via LDAPRealm)
16
So step 1 is setting up username, password and roles. And I am calling these username, password, and role information collectively as user identification information. (Sometimes these are called user credential as well.) The concept of roles are important. Each user belongs to a set of roles. And the web container will perform access control based on roles. Now the scheme of setting up these user identification information, that is, setting up a realm, is container and operational environment specific. For example, different organizations will maintain the user identification information in different places, for example, in a flat file, or in relational database, or in a LDAP server. And how these user identification information is managed is container specific as well. And later on I will demonstrate how Sun ONE App server 7 does that. Also password information might be either in encrypted form or not. For example, as a default, Tomcat maintains user identification information in a file in which password is not in encrypted form. However, Tomcat can work other schemes such as relational database or LDAP server.
01/04/2007
So for Tomcat, the default is using a file called tomcat-users.xml under config directory. And this is a very simple example. Here three roles are defined, manager, employee, and admin. And only one user has been defined for username sang and his password is sangPassword. And Sang belongs to two roles, manager role and employee role.
01/04/2007
Step 2: Tell web container that you are using Basic authentication
?
18
Now the next step is you, as a developer of web application, tells the web container which login scheme you want to use. Here the Basic authentication scheme has been chosen as a login scheme under loginconfig element of web.xml deployment descriptor.
01/04/2007
19
Once you define logging-in scheme, then you want to specify in web.xml deployment descriptor which web resources, that is which URL's, are to be access controlled. In this example, you are instructing the web container, that any user who belongs to a role of administrator can perform HTTP GET operation over web resource whose name is WRCollection and whose URL happened to be /localpricelist.
01/04/2007
20
The next step is to specify again in web.xml deployment descriptor which web resources should be available only with SSL. That is, whenever a user access the web resource and has to send some data, the data on the wire will be protected with SSL. This is the web.xml deployment descriptor for the same web resource we saw in the previous slide in which we specify which user can do what. Now we are also saying that this resource should be available only with SSL by saying <transport-guarantee> element is confidential So in summary, you as a web component developer and deployer can take two security measures, one is to specify who can access what resource, the other is to specify which web resource can be accessed only with SSL. And these two security measures can be taken independently from each other or can be used together.
01/04/2007
01/04/2007
Form-based Authentication
?
Web application collects user identification (user name, password, and other information) through a custom login page Not secure since user name and password are in easily decode'able form over the wire
In form-based authentication scheme, web application collects user identification information, again typically username, password, and other information maybe date of birth, through custom login page as opposed to browser provided default dialog box as in the case of basic authentication. As in basic authentication, as a default, the username and password is being transported in easily decode'able form. That is, someone can sniff the network traffic and retrieve the password and easily decode it. So in order to provide password confidentiality, you need to use SSL so that the password is transported in encrypted form.
01/04/2007
9
Error.html
Login.jsp j_security_check 6 8
redirected to resource 3. Unauthenticated client redirected 4. Login form returned to client 5. Client submits login form
7. Authorization Permission tested,
result returned
This picture shows the security control flow where form-based authentication is used as log-in scheme. The key point in this picture is that all these control flow is taken care of by web container itself transparently. So let's go over the scenario. When a user tries to access access controlled web resource by sending HTTP request, that is step 1, web container checks if the user has been already authenticated or not. And that is step 2. If the user has not been authenticated, in step 3, the web container automatically redirect the request to the login page. That is step 4. Again the key point here is that the web container does this automatically. When the user enters username and password information and submit through a custom login page, in step 5, web container will perform the authentication. That is step 6. Once the user has been authenticated, the web container then checks if the user has proper access right to the web resource. If he does, the result is sent back. That is step 7. If the authentication fails at step 6, then error page is displayed in step 8 and 9. In this picture, the green boxes are the ones the user get exposed while the dark blue boxes represent things that the container has to provide.
01/04/2007
So the steps for implementing and deploying form-based authentication for your web application is not that much different from the ones you follow in Basic authentication. The only extra steps you have to add over basic authentication is to create and deploy custom login and login failure error page.
01/04/2007
Same as in Basic-authentication
25
So step 1 is setting up username, password and roles. And this is the same for basic authentication.
01/04/2007
Step 2: Tell web container that you are using Form-based authentication
?
26
Now the next step is you as a developer of web application tells the web container which login scheme you want to use. Here the FORM authentication scheme has been chosen as a login scheme under loginconfig element of web.xml deployment descriptor.
01/04/2007
Some point, you have to provide a login page. The login page collects user identification information, that is, username and password through a HTML Form element here. And the action attribute has to have a value of j_security_check and the names of username and password attributes of input element have to be j_username and j_password respectively.
01/04/2007
28
You also have to provide login failure page. This page can be static HTML page or JSP page. And there is no requirement for specific content.
01/04/2007
29
Once you define logging-in scheme, then you want to specify in web.xml deployment descriptor which web resources, that is which URL's, are to be access controlled. In this example, you are instructing the web container, that any user who belongs to a role of administrator can perform HTTP GET operation over web resource whose name is WRCollection and whose URL happened to be /localpricelist.
01/04/2007
Step 6: Specify which URLs should be available only with SSL (Same as Basic Auth)
<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/loadpricelist</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name></realm-name> </login-config> ... </web-app>
30
The next step is to specify again in web.xml deployment descriptor which web resources should be available only with SSL. That is, whenever a user access the web resource, the data on the wire will be protected with SSL. This is the web.xml deployment descriptor for the same web resource we saw in the previous slide in which we specify which user can do what. Now we are also saying that this resource should be available only with SSL by specifying <transport-guarantee> element is confidential So in summary, you as a web component developer and deployer can take two security measures, one is to specify who can access what resource, the other is to specify which web resource can be accessed only with SSL. And these two security measures can be taken independently from each other or can be used at the same time.
01/04/2007
Form-based
Uses browser provided dialog box to get username and password Only username and password can be collected Might result in different look and feel HTTP Authentication header is used to convey username and password No good way to enter a new user name
Uses web application provided login page to get username and password Custom data can be collected Can enforce consistent look and feel Form data is used to convey username and password Can enter a new user name via login page
Now since basic and form-based authentication schemes are the most common logging-in schemes, let's compare the two. In Basic authentication scheme, the user name and password pair is collected through browser provided dialog box while in Form based authentication, the custom login page is used to collect username and password information. Because the default dialog box captures only user name and password fields, you cannot collect any other extra custom user identification information for example mother's maiden name in basic authentication scheme while that is possible in Form-based authentication. One another reason people might want to use Form-based authentication over basic authentication is to provide same look and feel with the rest of web application. Because the username/password pair is collected by the browser, in Basic authentication, it is being transported as part of Http header structure while in Form-based authentication, it is transported as part of form data. Now common thing between the two schemes is that the user identification information is being transported as Base64 encoded scheme and thus neither is secure. Now you can use SSL to protect the password information on the wire on both schemes.
01/04/2007
Realm Management
Now we touched upon realm management already. Now I would like to talk about it one more time so that you get some idea how things are done in real life.
01/04/2007
Realm Management
?
Tomcat flat file based, RDBMS, LDAP Sun ONE App server
?
33
So as was mentioned, realm is a set of user identification information such as username, password, and roles. These user identification information can be maintained in encrypted or unencrypted form. Obviously in production environment, you want to make sure the passwords are maintained in encrypted form. Now how the realms are maintained and managed are container specific and operational environment specific. For example, Tomcat container can manage several realms, the default of which is flat-file based. But it can also support relational database or LDAP. And same can be said for the Sun ONE App server. Sun ONE App server, in addition to LDAP and relational database, it can also support Solaris authentication modules.
01/04/2007
Security Roles
?
Web Application developer or assembler use security roles for access control (declarative & programmatic)
These are abstract roles that have nothing to do with usernames, passwords, groups of operating system At application deployment time, these abstract security roles need to be mapped usernames, passwords, groups of operating system
In production environment, an external security realm (LDAP) can be used both by web application and OS
34
Now let's talk a bit on security roles. Since we already touched upon how security roles are used in basic and form-based authentication schemes, you should have a decent idea on what it is. For those folks, who are new to this concept, the first question they have, however, is how these usernames, passwords, especially roles are related to the username/password/group maintained by the operating system, and that is a valid question. Since your web applications (for that matter web container) will be deployed over many different OS'es, obviously your applications cannot make any assumptions on the usernames, passwords, groups of the operating system. Instead they use so-called abstract security roles and these have to be mapped to the ones maintained by the OS some point. Obviously this could be a chore in production environment. So what is done typically in production environment is to use external security realm database such as LDAP where both web environment and OS share the same security realm.
01/04/2007
35
So for Tomcat, the default is using a file called tomcat-users.xml under config directory. And this is a very simple example. Here three roles are defined, manager, employee, and admin. And only one user has been defined for username sang and his password is sangPassword. And Sang belongs to two roles, manager role and employee role.
01/04/2007
Tomcat's default
?
36
So you can add,remove, modify realm information using Container specific tools. For flat-file based realm, you can add, remove, modify usernames, passwords, and roles either manually changing the tomcat-users.xml file ujnder config directory or you can use admintool.
01/04/2007
Tomcat's admintool
37
So this is the Tomcat's admin tool. You can go to Tomcat's admin tool through your browser by going to http://localhost:8080/admin. Using this admin tool, you can add, remove, modify usernames, passwords, and roles.
01/04/2007
38
This is an admin concole of Sun ONE App server. Through this admin console, you can select a default realm and then for that realm, you can add, remove, modify usernames, passwords, and roles.
01/04/2007
For Tomcat
jakarta.apache.org/tomcat/tomcat-4.0-doc/realmhowto.html
Security document that comes with Sun Java System App Server
39
Tomcat has a document you can refer to when you want to create custom realms and the webpage location of the document is as specified in the slide.
01/04/2007
How to Secure Passwords on the wire for Basic and Formbased Authentications
01/04/2007
Confidentiality of Passwords
?
For Basic and Form-based authentication, unless explicitly specified, the password gets transported in unencrypted form (Base64) Same confidentiality declaration as regular data
If you select CONFIDENTIAL or INTEGRAL on a security constraint, that type of security constraint applies to all requests that match the URL patterns in the Web resource collection, not just to the login dialog Uses SSL underneath
41
OK, we talked about using Basic and Form-based authentication schemes as ways to collect username and password. And as mentioned before, the default is that the password information gets transported in easily decode'able Base64 encoding scheme. Now if you want to prevent someone who has bad intention from reading the password while it is one the wire, you have to send the password in encrypted form using SSL. Now how do you do this for password encryption? Well you actually use the same deployment descriptor element for encrypting sensitive data for encrypting password. So in a sense, you regard password as a kind of sensitive data between a browser and web server. And you use CONFIDENTIAL as a value for <transport-guarantee> element under <user-data-constraint> element as we will see in the following slide.
01/04/2007
42
So this is the fragment of web.xml file that specifies that password that has been collected through custom login page needs to be transported in SSL-encrypted form. As you can tell, you specify a single <transportguarantee> element with CONFIDENTIAL value for instructing the web container to transport the password and client entered data in SSLencrypted form.
01/04/2007
01/04/2007
Once you switch to SSL, do not accept any further requests for that session that are non-SSL
Because session ID itself is not in encrypted form, impostor might perform a transaction that might involve sensitive data (i.e. credit card) Use Servlet filter to reject any non-SSL requests
44
Someone asked me a question two weeks ago when we were talking about URL rewriting. The question was what would be the security implication of using URL rewriting? Given that the session ID is in cleartext form, wouldn't it expose it security risk? That is a valid question. In fact, this is the reason I am talking about this SSL implementation guideline here.
01/04/2007
SSL is Expensive
?
Use SSL only for web resources that need security protection
45
The SSL protocol is designed to be as efficient as securely possible. However, encryption/decryption is a computationally expensive process from a performance standpoint. It is not strictly necessary to run an entire Web application over SSL, and it is customary for a developer to decide which pages require a secure connection and which do not. Pages that might require a secure connection include login pages, personal information pages, shopping cart checkouts, or any pages where credit card information could possibly be transmitted. Any page within an application can be requested over a secure socket by simply prefixing the address with https: instead of http:. Any pages which absolutely require a secure connection should check the protocol type associated with the page request and take the appropriate action if https: is not specified.
01/04/2007
Ant Operations
?
ant build works OK ant install or ant deploy failure with HTTP 401 error condition because ant install and ant deploy is accessing password-protected resource and you were not providing correct userid/password pair
?
Why?
T Now some of you when you were doing our 2nd homework building web application and then try to install.
01/04/2007
? ?
Unzip into <install-dir> Copy *.war files under <install-dir>/SecurityCode into <jwsdp-home>/webapps directory Add new usernames, roles (the ones used by the code) appropriately to your Tomcat environment (tomcat-users.xml) Restart Tomcat
47
The demo I am going to show is from Marty Hall's sample code. Basically what you have to do in order to run the code is as following: -download the sample code from the site mentioned above. -unzip the sample code. It should have Security-Code directory. Copy all the *.war files to the webapps directory of Java WSDP. You also want to change your tomcat-users.xml file to add new users, and roles that Marty's program uses. You can do it either manually or Tomcat's admin tool. Once you've done that, you restart Tomcat. Now you can play around the code.
01/04/2007
Financial plan page: available to all employees Business plan page: available only to executives Employee compensation plan: available to all employees
? ? ?
Try to access access controlled page Enter bogus username & password Enter valid username & password but who does not have access right (does not belong to a proper role) 48
This is Basic authentication demo that we are going to go over the source code as well. You can get the complete source and binary code from Marty's website, whose address is http://www.coreservlets.com/ and select Source code archive.
01/04/2007
49
So when you go to the http://localhost:8080/hotdotcom-internal/ from your browser, this is the screen you will see. This page is not protected, which means anybody can access the page. Now the three pages you can go from here - Financial plan, Business plan, and Employee compensation plan - are all protected web resources. That is, as soon as you try to access it, the container will automatically display a login dialog box so that you can authenticate yourself first. That is what you will see in the next slide.
01/04/2007
50
So here you click Financial planning page, and you receive a dialog box in which you can enter username and password.
01/04/2007
51
If you entered a valid username and password but if the user does not have access right to access this page, this is what you will get. Now, you will keep getting this error page continuously no matter what you do. The thing is that the containers maintains a session state in which your identity is maintained. So until you close the browser and start it again, there is not a good way to enter different username and password. This is one of the problem of using Basic authentication. Form-based authentication does not have this problem.
01/04/2007
01/04/2007
Form-based Authentication
53
Now this is the form-based authentication demo. Go to http://localhost :8080/hotdotcom/ in your browser.
01/04/2007
54
In formed based authentication, when you access access controlled (protected) web page, you get a custom login dialog box. And this is an example.
01/04/2007
55
Same thing with login failure error page. Instead of default behavior of basic authentication (keep displaying login dialog box), you get a customized login failure page.
01/04/2007
01/04/2007
As I mentioned, Basic authentication and Form-based authentications the most popular web-tier security schemes of today. Now both of these schemes assume that client is an end-user who enters userid/password information through either browser-provided login dialog box (basic authentication) or custom login page (form-based authentication). Now there are times the client is not an end-user. For example, the client could be a program entity. In this case, basic-authentication and form-based authentication cannot be used. And because a certificate can be used to identity end-users, business organizations, software entities, and servers, certificate based authentication can be used when the client is, for example, a software entity. That is, it is the software entity that sends HTTP request to the Web application. Another reason you might want to use certificate-based authentication scheme is when more than username and password pair needs to be conveyed to the Web application as identity information. Again, certificate based authentication would be a better choice here since certificate can contain more than user name and password.
01/04/2007
Certificate-based Authentication
?
Client authentication
server verifies client's identity client verifies server's identity occurs transparently in SSL-based browser and web server communication both server and client verify each other's identity
58
Server authentication
Mutual authentication
There are 3 different kinds of certificate authentication depending on who authenticate whom. Client authentication means it is the server who authenticates the client. That is, it is the server who verifies the client's identity. Server authentication is the opposite. It is the client who verifies the server's identity. Mutual authentication means both server and client verify each other's identity.
01/04/2007
Certificate Formats
? ?
Standard Certificate format is X.509 X.509 does specify the format of the certificate but does not specify how certificates are exchanged SSL specifies how certificates are exchanged
59
(to be added)
01/04/2007
When the server gets authenticated to the client as well, we call it mutual authentication
Client certificate has to be created beforehand for each browser based client
This slide is about client certificate-based authentication, which is the 3rd form of authentication at web-tier. In client certificate-based authentication, client gets authenticated by sending client certificate to the web server. That is, instead of sending user name and password pair to the server, client is sending client certificate as a proof of his identification. By the way, by client, I am talking about a browser here in this context. Now I mentioned before that SSL is used to protect the data while it is on the wire. That is, SSL is used to provide data confidentiality between the browser and the web server. As part of this, server does authenticate itself to the browser by sending its own certificate as a proof of its identification. So when people say mutual authentication, they are talking about a scenario in which client certificate based authentication also occurs in addition to server authentication. Now in this model, client has to possess his own certificate. That is, somebody has to create a valid certificate for the browser. What this means that every client has to have its own certificate. This could be an issue in terms of client management especially when the server does not know who its clients are. This is the reason why the client certificate based authentication is only rarely used compared to basic or form-based authentication. And of course, it is based on SSL over HTTP.
01/04/2007
61
This is the fragment of web.xml deployment descriptor indicating that you as a deployer of this web application wants to use Client certificate based authentication. Here you say CLIENT-CERT as value of <authmethod> element.
01/04/2007
Digest Authentication
OK, we talked about 3 web-tier authentication methods - basic, formbased, client-certificate based. Now let's talk about the last authentication method, digest authentication.
01/04/2007
Digest Authentication
?
User password is transformed into digested form before being sent to the server
You cannot get the original password from the digested password (property of message digesting) Even a single bit of change of original password results in different digested password value No cleartext (or uuencoded) user password on the wire even without on a non-SSL connection
Server compares the passed digested value with its own, if matched, then authentication succeeds
63
In digest authentication, user password is transformed into a hashed form before being sent to the server. This method is taking advantage of two mathematical properties of messaging digesting. The first one is that it is practically impossible to make a guess of the original value from the message digest. The second property is that even single bit of change to the original value will result in a different message digest. Now the digested password can be sent over the wire without using SSL without being concerned about confidentiality because it would be impossible for someone can take the value and make a guess of original password. Now when the server receives the digested password value, it will then compare it with its own version of digested value. And if they match, then authentication is successful.
01/04/2007
64
This is the fragment of web.xml deployment descriptor indicating that you as a deployer of this web application wants to use message digest authentication. Here you say DIGEST as value of <auth-method> element.
01/04/2007
01/04/2007
Declarative access control at Web-tier Programmatic access control at Web-tier Declarative access control at EJB-tier Programmatic access control at EJB-tier
66
Over J2EE architecture, 4 different types of access control can occur. And they can be categorized based on where access control occurs, for example, web-tier versus EJB-tier, or how the access control is done, declarative versus programmatic access control. So let's talk about these in a bit more detail.
01/04/2007
EJB-tier
(D) Access control to Web resources (D) Declared in web.xml (D) Enforced by web container (P) Coded in servlet or JSP
(D) Access control to bean methods (D) Declared in EJB deployment descriptor (D) Enforced by EJB container (P) Coded in EJB bean
First let's compare web-tier access control versus EJB-tier access control. At both tiers, there could be both declarative and programmatic access control. For example, at web-tier, access control is applied to web resources such as servlet or JSP pages while at EJB tier, the access control is applied to the bean methods. At web tier, the declarative access control is specified within web.xml deployment descriptor while at EJB tier, it is specified at EJB deployment descriptor. And at web tier, the access control is enforced by web container while at EJB tier it is enforced by EJB container. In terms of programmatic access control, at web-tier, the programmatic access control logic is coded in servlet or JSP pages while in EJB tier, it is coded within EJB beans.
01/04/2007
Programmatic
Access control is declared in deployment descriptor Container handles access control Does not handle fine-grained access control, it is all or nothing deal
Access control is coded in your program Your code handles access control Can handle finegrained access control, i.e. instancebased or business logic based access control
Now let's compare declarative access control against programmatic access control. In declarative access control, the access control logic is declaratively specified in deployment descriptor and then it is the container that handles the access control. In programmatic access control, on the other hand, the access control logic is coded in your program. By the way, declarative access control can be used together with programmatic access control. Now the reason you might want to implement programmatic access control is the declarative access control scheme does not provide fine-grained access control scheme. For example, you cannot specify access control logic that is based on a particular instance of your bean or based on business logic. For example, as we will see an example later on, if you want to say an employee can see only his or her own salary information, you have to use programmatic access control.
01/04/2007
01/04/2007
Now how do you implement declarative access control at webtier? One of the nice thing about using declarative access control is that the web application developer does not really have to do any work as far as coding is concerned. In other words, in declarative access control scheme, it is the deployer who specifies security requirement in the deployment descriptor and it is the responsibility for the container to enforce the access control. By the way, we dealt with this declarative access control when we talk about authentication in this session especially under the context of basic and form-based authentication. First, it is assumed that the deployer or system administrator have mapped user identities to security roles. Then, the deployer declares security roles. Then he declares URL permissions to the deployment descriptor for each security role. And we have seen the example of it before.
01/04/2007
01/04/2007
Declarative access control for role-based access control Programmatic access control for user instancebased and business logic based access control
? ? ? ?
User instance Time of the day Parameters of the request Internal state of the web component 72
Now before I talk about programmatic access control, let me tell you that declarative and programmatic access control schemes are typically used together. Declarative access control is used for role-based access control while programmatic access control is used for user instance-based and business logic based access control. For example, the web application can generate different contents depending on who the user is. The business logic can be based on anything under programmer's control, for example, object instance, time of the day, parameters of the request, and internal state of the web component.
01/04/2007
This is the list of steps for performing programmatic authorization at web-tier. First, just like in declarative environment, it is expected that system administrator has set up security realms meaning username, password and roles are set up. Then servlet programmers write programmatic authorization logic inside the code using security roles. Now when the web application gets deployed in a particular operational environment, deployer then maps these abstract security roles to actual roles in that particular operational environment.
01/04/2007
At Web-tier, there are 3 methods which quite similar to the ones at EJB-tier. For example, getting caller's Principal object and if the caller is in a particular role or not. And the programmatic access control logic at web-tier works pretty much the same way at web-tier, I will not spend any more time on this.
01/04/2007
75
So in this example, the access control logic says that manager role can read salary information of everyone while employee role can read only his or her salary information. So here you get the caller's principal object and get the caller id string from it and check if that matches the employee id that is passed as a parameter.
01/04/2007
76
So here in this example, abstract role called manager is mapped to actual role called managerofAcme.
01/04/2007
01/04/2007
78
So in programmatic authentication at web-tier, the web application takes responsibility in the code for making sure the user is who he claims he is. You get some more control by doing this but the benefit is rather marginal and in practice, it is rarely used.
01/04/2007
Check if there is authorization header Decode the Base64 encoded username and password Check username/password pair against security realm
If successful match, performs access control if access control succeeds, return page otherwise, display appropriate page Otherwise (authentication fails), send back ask for new username & password
? ?
79
So these are the steps you follow for performing programmatic authentication at web-tier. First, you check if the user sends proper username and password in the authorization header of the HTTP request. If not, you want to ask the user to enter proper username and password. Again, in declarative authentication, this is done automatically by the container. The username and password that are entered by the user then will be transported in Base64 encoded form. So your code has to decode them. Once you decoded the username and password, you can then check if there is a match between the ones that the user entered and the ones in the backend realm database. If matched, the authentication succeeds, then you perform access control. Otherwise, you ask for a new username and password.
01/04/2007
80
So this is the sample code from Marty Hall's sample code. Here you get the authorization block. If the block is null, that means, the user tries to access this servlet without proper username and password. So you display the login dialog box prompting username and password.
01/04/2007
81
If the user entered username and password, then your code have to decode them.
01/04/2007
If success, return page, Otherwise ask for a new username & password
if (authorization == null) { askForPassword(response); } else { ... // If authentication succeeds, return page. // Otherwise, ask for correct username & password if (areEqualReversed(user, password)) { showStock(request, response); } else { askForPassword(response); } }
82
Then your code compares if the username and password pair is matches one in the backend realm database. In this code, if match occurs, we send back the page. So we do not perform the access control here. Otherwise, you again send a page asking the user to enter valid username and password.
01/04/2007
83
So I am going to add the username and password pair to the file-based realm of the Sun ONE App server. Here as you can see on the left side of the screen, Sun ONE app server supports multiple realms, for example file based realm, ldap based realm, and certificate based realm. At this point, the file-based realm is set as a default realm. What it means is that the userid/password pair entered by the user will be checked against the user identification information maintained in the file. So what I am going to do here is to add the username/password pair to the file based realm by selecting Managing users.
01/04/2007
84
Now I can add or delete username and password. This screen shows add a user screen. So I am adding sang100 and sangpassword. Once the pair is added, the change has to be applied and Sun ONE app server has to be restarted. Now this restart would not required when using Ldap or JDBC or solaris-based realms are used.
01/04/2007
85
01/04/2007
01/04/2007
Sun ONE App server is j2EE 1.3 compliant so it supports both declarative and programmatic security. It also supports different schemes where realms can be maintained. As I mentioned before, a realm is a set of user identity information such as username, password, and roles for a particular domain. And a realm can be maintained in different schemes. For example, Sun ONE App server supports file-based, LDAP-based, certificate based, and Solaris based realms. It also supports pluggable authentication framework using JAAS framework. In fact, you can add your own custom realms. For example, you can add relational database based realm in which user identification information is maintained in a relational database. As Sun ONE App server 7 specific value-add features, it supports single sign on in which same authenticate state can be shared among multiple J2EE applications. It also supports programmatic login in which you can perform custom login scheme.
01/04/2007
OK, now it is demo time. The demo I am going to show is using Sun ONE app server admin console to add a username and password to file-based realm. By the way, as I mentioned earlier, the term realm is used to refer to a set of user identity information for a particular security domain. And realm can be maintained in several different schemes/ And if I have a time, I will show you how to add a custom security realm to Sun ONE app server.
01/04/2007
89
In the first demo, let's assume I already deployed an access controlled web resource whose URL is http://localhost:80/basic/index.jsp. So when you access this page, the web container instructs the browser to pop up a dialog box prompting you to enter userid and password. For a demo purpose, I will enter invalid userid and password pair. And the default behavior at this time is that the container will keep asking the browser to display the dialog box. Now I am going to use Sun ONE app server's admin console, I am going to add the userid/password pair to the file based realm which is being used as a default realm right now.
01/04/2007
90
So this is the dialog box you will receive when you access the access controlled page, http://localhost:80/basic/index.jsp. Now I am going to enter invalid userid/password pair. So I am entering sang100 and sangpassword. Now since the pair is invalid username and password, the container will keep asking the browser to display this dialog box.
01/04/2007
Authentication Failed
91
If you select cancel button, the browser then displays an error condition. Here it says the request requires authentication because it tried to access access-controlled page.
01/04/2007
92
So I am going to add the username and password pair to the file-based realm of the Sun ONE App server. Here as you can see on the left side of the screen, Sun ONE app server supports multiple realms, for example file based realm, ldap based realm, and certificate based realm. At this point, the file-based realm is set as a default realm. What it means is that the userid/password pair entered by the user will be checked against the user identification information maintained in the file. So what I am going to do here is to add the username/password pair to the file based realm by selecting Managing users.
01/04/2007
93
Now I can add or delete username and password. This screen shows add a user screen. So I am adding sang100 and sangpassword. Once the pair is added, the change has to be applied and Sun ONE app server has to be restarted. Now this restart would not required when using Ldap or JDBC or solaris-based realms are used.
01/04/2007
01/04/2007
01/04/2007
server Same authenticate state shared among Sun ONE App is j2EE 1.3 compliant so it supports both multiple J2EE applications declarative and programmatic security.
It also supports different schemes where realms can be maintained. As I mentioned before, a realm is a set of user identity information such as username, password, and roles for a particular domain. And a realm can be maintained in different schemes. For example, Sun ONE App server supports file-based, LDAP-based, certificate based, and Solaris based realms. It also supports pluggable authentication framework using JAAS framework. In fact, you can add your own custom realms. For example, you can add relational database based realm in which user identification information is maintained in a relational database. As Sun ONE App server 7 specific value-add features, it supports single sign on in which same authenticate state can be shared among multiple J2EE applications. It also supports programmatic login in which you can perform custom login scheme.
01/04/2007
OK, now it is demo time. The demo I am going to show is using Sun ONE app server admin console to add a username and password to file-based realm. By the way, as I mentioned earlier, the term realm is used to refer to a set of user identity information for a particular security domain. And realm can be maintained in several different schemes/ And if I have a time, I will show you how to add a custom security realm to Sun ONE app server.
01/04/2007
98
So I am going to add the username and password pair to the file-based realm of the Sun ONE App server. Here as you can see on the left side of the screen, Sun ONE app server supports multiple realms, for example file based realm, ldap based realm, and certificate based realm. At this point, the file-based realm is set as a default realm. What it means is that the userid/password pair entered by the user will be checked against the user identification information maintained in the file. So what I am going to do here is to add the username/password pair to the file based realm by selecting Managing users.
01/04/2007
Access the Protected Page Again and Enter the same userid/password pair
99
Now if I access the same page and enters the same userid and password, I can access the page successfully.
01/04/2007
Add JDBC custom realm Use pointbase or Oracle database as storage of userid/password information (instead of file realm)
100
The second demo is to add JDBC realm to the Sun ONE App server. You can use any JDBC compatible relational database such as pointbase or Oracle database.
01/04/2007
101
So by using Sun App Server's admin control, you can add a custom realm and then set the App server to use the custom realm as a default realm.
01/04/2007
Passion!