01/04/2007

Web Application Security

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

General Security Issues

So let's talk about general security issues that we need to be aware first.

01/04/2007

General Security Issues

?

Authentication for identity verification

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

Authorization (Access control)

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

Web-tier Security Requirements & Schemes

Now let's talk about web-tier security requirements and how those requirements can be met by various web-tier security schemes.

01/04/2007

Security Requirements at Web-Tier

?

Preventing unauthorized users from accessing access controlled web resource

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

Data can be protected via SSL

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

Web-Tier Security Scheme Should Address Authentication

1.Collecting user identity information from an end user

typically through browser interface user identity information usually means username and password this is called logging in

2.Transporting collected user identity information to the web server

unsecurely (HTTP) or securely (HTTP over SSL)

7

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-Tier Security Scheme Should Address Authentication (Cont.)

3.Performing identity checking with backend security database (Realms)

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

Web-Tier Security Scheme Should Address Authentication (Cont.)

4.Web container keep track of previously authenticated users for further HTTP operations

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-Tier Security Scheme Should Address Access control

?

Web application developer and/or deployer specifies access control to web resources

Declarative and/or Programmatic access control

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

Web-Tier Security Scheme Should Address Data confidentiality

?

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

Web-tier Authentication Schemes

?

HTTP basic authentication based

with or without SSL with or without SSL Has to use SSL Does not need to use SSL
12

Form-based authentication based

Client-certificate authentication based

Digest authentication based

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

HTTP Basic Authentication-based Web tier Security

OK, let's talk about HTTP basic authentication-based web tier security. As mentioned before, in this scheme, we are going to talk about not only authentication aspect but also access control and data confidentiality. The reason we talk about all these in a singe scenario here is that Webtier security scheme in fact addresses all these three security services in a very well-integrated and transparent fashion. And that is the reason why I titled this sub-segment of the presentation as HTTP Basic Authentication-based Web-tier security instead of just HTTP Basic authentication.

01/04/2007

HTTP Basic Authentication

?

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

Encoding scheme is Base64 Someone can easily decode it Not encrypted

14

Would need SSL for encrypting password

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

Steps for Basic Authenticationbased Web-tier Security

1.Set up username, passwords, and roles (realms) 2.Tell web container that you are using Basic authentication 3.Specify which URLs (web resources) should be access-controlled (password-protected) 4.Specify which URLs should be available only with SSL (data integrity and confidentiality protected)
15

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

Step 1: Set up username, passwords, and roles (Realms)

?

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)

Tomcat 4.0 can work with the following realms

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

Example: Tomcat's default

? ?

<install-dir>/config/tomcat-users.xml Unencrypted: not secure but easy to set up and maintain

<?xml version='1.0'?> <tomcat-users> <role rolename="manager"/> <role rolename="employee"/> <role rolename="admin"/> <user username="sang" password="sangPassword" roles="manager,employee"/> </tomcat-users> 17

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
?

In web.xml file of your web application

<web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app>

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

Step 3: Specify which URLs should be access-controlled

<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>BASIC</auth-method> <realm-name></realm-name> </login-config> ... </web-app>

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

Step 4: Specify which URLs should be available only with SSL

<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>BASIC</auth-method> <realm-name></realm-name> </login-config> ... </web-app>

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

Form-based Authentication based Web-tier Security

Now let's talk about Form-based authentication. The way form-based authentication works is pretty much the same as basic authentication but with just a little bit of more customization.

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

Encoding scheme is Base64 Someone can easily decode it Not encrypted

22

Would need SSL for encrypting password

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

Form-Based Auth. Control Flow

Request Response Page 1 7 2 Protected Resource 3 Login Form 4 5
Error Page

9
Error.html

Login.jsp j_security_check 6 8

6. Authentication Login succeeded,

redirected to resource 3. Unauthenticated client redirected 4. Login form returned to client 5. Client submits login form
7. Authorization Permission tested,

result returned

8. Login failed, redirect to error page 9. Error page returned to client

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

Steps for Form-based Authentication based Web-tier Security

1.Set up username, passwords, and roles (realms) 2.Tell web container that you are using Form-based authentication 3.Create custom Login page 4.Create custom Login failure error page 5.Specify which URLs (web resources) should be access-controlled (password-protected) 6.Specify which URLs should be available only with SSL (data integrity and confidentiality protected)
24

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

Step 1: Set up username, passwords, and roles (Realms)

?

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
?

In web.xml file of your web application

<web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app>

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

Step 3: Create custom Login Page

? ?

Can be HTML or JSP page Contains HTML form like following

<FORM ACTION="j_security_check" METHOD="POST"> <INPUT TYPE="TEXT" NAME="j_username"> <INPUT TYPE="PASSWORD" NAME="j_password"> </FORM> 27

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

Step 4: Create Login Failure page

? ?

Can be HTML or JSP page No specific content is mandated

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

Step 5: Specify which URLs should be access-controlled (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> <role-name>executive</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> ...

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

Basic vs. Form-based Authentication

Basic

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
?

Management of user identity information

username, password, roles, etc. encrypted or unencrypted

Container and operational environment dependent

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

Example: Tomcat's default

? ?

<install-dir>/config/tomcat-users.xml Unencrypted: not secure but easy to set up and maintain

<?xml version='1.0'?> <tomcat-users> <role rolename="manager"/> <role rolename="employee"/> <role rolename="admin"/> <user username="sang" password="sangPassword" roles="manager,employee"/> </tomcat-users>

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
?

Flat file based realm is maintained in

<install-dir>/config/tomcat-users.xml manually admintool

You can change it in one of two ways

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

Sun App Server Admin Console

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

How to Create Custom Realms?

?

For Tomcat

jakarta.apache.org/tomcat/tomcat-4.0-doc/realmhowto.html

For Sun Java System App Server

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

SSL-enabled Confidentiality applies to All traffic Including Password

<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>

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

Web-tier Security Implementation Guidelines

I have a section for implementation and deployment guidelines for webtier security.

01/04/2007

Switching between SSL and nonSSL protected Web resources

?

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
?

Some of you have experienced the following

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?

maybe due to non-existence of build.properties file 46

T Now some of you when you were doing our 2nd homework building web application and then try to install.

01/04/2007

Marty Hall's Sample code Demo

?

Download the sample binary and source code from

http://www.moreservlets.com (select Source code archive)

? ?

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

Basic Authentication Demo

?

Marty Hall's Sample code (hotdotcominternal.war, http://www.coreservlets.com/)

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

Basic Authentication Demo

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

Access access controlled page with bogus username

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

Access access controlled page with valid username

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

Demo: Form-based Authentication

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

Custom login page

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

Custom error page

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

Client Certificate-based Authentication

Now let's talk about client certificate-based authentication.

01/04/2007

Why Certificate-based Authentication?

?

Username/password authentication cannot be used between program to program authentication

Certificates may identify end-users, business organizations, servers, software entities

Username/password pair might not provide enough credentials

Certificate can contain much more than username and password

57

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

Client Certificate-based Authentication

?

Client gets authenticated by sending Client certificate to Web server

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

Not as popular as Basic or Form-based authentication because of this reason

60

Uses SSL over HTTP

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

Tell web container that you are using Client-Cert authentication

?

In web.xml file of your web application

<web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app>

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

Tell web container that you are using Digest authentication

?

In web.xml file of your web application

<web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>DIGEST</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app>

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

Authorization (Access Control)

Ok, so far, we have talked about authentication. Now let's talk about authorization or access control.

01/04/2007

4 Types of Authorization (Access Control) over J2EE

Web-tier vs. EJB-tier

Can be used together

Declarative vs. Programmatic 4 possible types

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

Web-tier vs. EJB-tier

Web-tier

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

(D): Declarative (P): Programmatic access control

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

Declarative vs. Programmatic

Declarative

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

Declarative Authorization at Web-tier

OK. Let's talk about declarative authorization at web-tier first.

01/04/2007

Steps for Declarative Authorization at Web-tier

1.Deployer maps actual user identities to security roles using vendor specific tools 2.Deployer declares security roles in the deployment descriptor 3.Deployer declares URL permissions in the deployment descriptor for each security role This is already covered above under Web-tier security schemes segment!
70

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

Programmatic Authorization at Web-tier

OK. Now let's talk about programmatic authorization at web-tier.

01/04/2007

Declarative and Programmatic Authorization (Access Control)

?

They are usually used together

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

Steps for Programmatic Authorization at Web-tier

1.Set up username, passwords, and roles (realms) 2.Servlet programmer writes programmatic authorization logic inside the Servlet code using abstract security roles 3.Deployer maps abstract security roles to actual roles (for a particular operational environment) in the web.xml
73

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

Step 2: Servlet Programmer writes programmatic authorization logic

public interface javax.servlet.http.HTTPServletRequest{ ... // Find out who is accessing your web resource public java.security.Principal getUserPrincipal(); public String getRemoteUser(); // Is the caller in a particular role? public boolean isUserInRole(String role); ... } 74

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

Example: Employees can only access their own Salary Information

public double getSalary(String employeeId) { java.security.Principal userPrincipal = request.getUserPrincipal(); String callerId = userPrincipal.getName(); // manager role can read employee salary information // employee can read only his/her own salary information if ( (request.isUserInRole(manager)) || ((request.isUserInRole(employee)) && (callerId == employeeId)) ) { // return Salary information for the employee getSalaryInformationSomehow(employId); } else { throw new SecurityException(access denied); } }

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

Step 3: Deployer maps abstract security roles to actual roles

<web-app> ... <servlet> <servlet-name>...</servlet-name> <servlet-class>...</servlet-class> <!-- Servlet programmer declared abstract security roles --> <security-role-ref> <role-name>manager</role-name> <!-- preexisting --> <role-link>managerOfAcme</role-link> <!-- alias --> <security-role-ref> </servlet> ... </web-app>

76

So here in this example, abstract role called manager is mapped to actual role called managerofAcme.

01/04/2007

Programmatic Authentication at Web-tier

This is about programmatic authentication at web-tier. As I will talk about in the following slide, this is presented here to give you a sense how the web containers performs the authentication in the case you use declarative authentication such as basic authentication and form-based authentication. In practice, this is rarely used.

01/04/2007

Programmatic Authentication at Web-tier

?

Web application itself performs the authentication

More customized control is possible (but this is rather marginal benefit)

Rarely used in practice

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

Steps for Programmatic Authentication at Web-tier

? ?

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

Check if there is authentication Header

public void doGet() { // Check if authentication header is present in // HttpServletRequest. If not, ask for it. String authorization = request.getHeader("Authorization"); if (authorization == null) { askForPassword(response); } else { ...

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

Decode Username and Password

if (authorization == null) { askForPassword(response); } else { String userInfo = authorization.substring(6).trim(); BASE64Decoder decoder = new BASE64Decoder(); String nameAndPassword = new String(decoder.decodeBuffer(userInfo)); int index = nameAndPassword.indexOf(":"); String user = nameAndPassword.substring(0, index); String password = nameAndPassword.substring(index+1); ...

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

Open App Server Admin Console

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

Add Userid/Password Pair to File Realm

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

Restart App Server

85

So here I select apply changes, stop and start button in sequence.

01/04/2007

Sun Java System App Server 8 Security Features

OK. Let's talk a little bit on Sun ONE App server 7's security features.

01/04/2007

Sun Java System App Server J2EE Security Features

Declarative and programmatic security Realm administration

file, LDAP, certificate, Solaris-based realms

You can add custom realm

Pluggable authentication via JAAS

Single sign-on (value-add)

Same authenticate state shared among multiple J2EE applications

87

Programmatic login (value-add)

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

Demo (Sun Java System App Server Security)

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

Demo1: Basic Authentication

1. Deploy basic-auth web application (from Sun App Server samples) 2. From a browser, access a protected web resource http://localhost:80/basic/index.jsp 3. Web container asks browser to display a default login dialog box 4. Enter an invalid userid/password pair Container keep asking browser to display dialog box 5. Using Sun App Server Admin console, add the userid/password pair to the userid/password file-based realm 6. Restart Sun App Server 7. Access the protected web resource again

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

Enter invalid userid/password

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

Open App Server Admin Console

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

Add Userid/Password Pair to File Realm

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

Restart App Server

94 So here I select apply changes, stop and start button in sequence.

01/04/2007

Sun Java System App Server 8 Security Features

OK. Let's talk a little bit on Sun ONE App server 7's security features.

01/04/2007

Sun Java System App Server J2EE Security Features

Declarative and programmatic security Realm administration

file, LDAP, certificate, Solaris-based realms

You can add custom realm

Pluggable authentication via JAAS

Single sign-on (value-add) Programmatic login (value-add)

96

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

Demo (Sun Java System App Server Security)

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

Open App Server Admin Console

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

Demo2: Add Custom Realm

? ?

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

Use JDBC Realm as Default Realm

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!