WebApplicationSecurity102

7/29/2019 WebApplicationSecurity102

1/102

Web Application SecurityWeb Application Security

01/04/2007


2/102

2

Agenda

? General security issues

? Web-tier security requirements and schemes

? HTTP basic authentication based web-tiersecurity scheme

? Form-based authentication based web-tiersecurity scheme

? Declarative authorization

? Programmatic authorization

? Programmatic authentication

So what are going to talk about in this session? First, we will talk aboutgeneral web-tier security issues that need to be thought about whendeveloping 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 thoserequirements.

And we will look into two most important security schemes used at web-tier:HTTP basic authentication based web-tier security scheme and Form-based authentication based web-tier security scheme. People call thesesimply Basic authentication and Form-based authentication but theycover more than just authentication, in fact, they address not onlyauthentication but also access control and data confidentiality, hence thereason why I call them as web-tier security schemes.

We will then talk about two authorization schemes at web-tier: declarativeand programmatic authorization.

And finally I will talk about how you can perform programmaticauthentication as well even though this is rarely used in practice.

01/04/2007


3/102

General SecurityGeneral Security

IssuesIssues

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

01/04/2007


4/102

4

General Security Issues

? Authentication for identity verification Making sure a user is who he claims he is

? Authorization (Access control) Making sure resources are accessible only to

users who have access privilege

The user has to be authenticated first

? Confidentiality (Privacy)

Protecting the sensitive data from prying eyeswhile it is on the wire

These are general security issues which we talked about during thesecurity basics session. So let's just quickly review them here again.

First, in a networking environment, a user (or program entity) has toprove his/her (its) identity. And we call it authentication. So by usingappropriate authentication scheme, we can be assured that a user (orprogram 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 onlyby a user who has access privilege. And of course, it is assumed thatthe user has been authenticated already.

Confidentiality is sometimes called privacy and it means that the datashould be accessible only to the party the data is intended. It meansnobody can access the data while the data is on the wire.

01/04/2007


5/102

Web-tier SecurityWeb-tier SecurityRequirements &Requirements &

SchemesSchemes

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

01/04/2007


6/102

6

Security Requirements at Web-Tier

? Preventing unauthorized users fromaccessing access controlled web resource

If an unauthenticated user tries to access

access controlled web resource, web containerwill automatically ask the user to authenticatehimself first

Once the user authenticated, web container(and/or web components) then enforces access

control

?

Preventing attackers from changing orreading 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 aboutat web-tier?

First we have to be concerned about how to prevent unauthorized usersfrom accessing protected or access controlled web resources. By

the way, as we will see later, these access controlled web resourcesare represented by URL's at web-tier. So at web-tier, when anunauthenticated 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 accesscontrol 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 changingor 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, thedata should be encrypted using SSL.

01/04/2007


7/102

7

Web-Tier Security Scheme Should

Address Authentication1.Collecting user identity information from

an end user typically through browser interface

user identity information usually meansusername and password

this is called logging in

2.Transporting collected user identity

information to the web server unsecurely (HTTP) or securely (HTTP over SSL)

So as we talked about, web-tier security scheme has to provideauthentication scheme so that the web server knows that the user is whohe 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 anend user needs to be addressed. In other words, a logging-inmechanism needs to be provided. The most popular form of user identityinformation for Web application is username and password pair.

Then the collected user identity information needs to be transported fromthe browser to the web server. Now we have to be concerned aboutconfidentiality of the password here. And as we will see later on, youcan use SSL if you want to pass the password securely, meaning withconfidentiality.

01/04/2007


8/102

8


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

Now once the web server receives the collected user identity information,it then has to perform the identity checking. That is, it checks if thecollected user identity matches one of the identities maintained in thebackend security database. By the way, these backend securitydatabase 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 rolesinformation. And realms can be maintained in many different forms. Forexample, username, password, and roles information can be maintainedin LDAP server, relational database, or even in a flat file as we will seean example of it in Tomcat's users-xml file.

01/04/2007


9/102

9


Address Authentication (Cont.)4.Web container keep track of previously

authenticated users for further HTTPoperations Using internally maintained session state, web

container knows if the caller of subsequent HTTPrequests has been authenticated

Web container also creates HttpServletRequestobject for subsequent HTTP requests

?

HttpServletRequest object contains securitycontext information

Principal, Role, Username

Now one more thing that a web container does rather behind the scenefor you is to keep track of previously authenticated users for furtherHTTP operations. In other words, once a user is authenticated, the factthat he has been authenticated is maintained as a internal session stateby 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 comingin, the container will create HttpRequestServlet object for you and youcan find out some security context information from thatHttpRequestServlet object. For example, you can find out Principalinformation of the user, or you can find out if the user belongs to aparticular role, or you can find out the username of the user.

01/04/2007


10/102

10


Address Access control? Web application developer and/or

deployer specifies access control to webresources Declarative and/or Programmatic access control

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 willsee later on, web-tier security schemes allows both declarative andprogrammatic access control.

01/04/2007


11/102

11


Address Data confidentiality? Providing confidentiality of the sensitive

data that is being transported over thewire

Between browser and web server

Example: Credit card number

Using SSL

Finally web-tier security scheme should address data confidentiality.That is, it should provide a scheme in which the confidentiality of thesensitive data such as credit card number should be protected from theprying eyes while they are being transported between a browser and webserver. Again, SSL is the technology that will be used here to providethat protection.

01/04/2007


12/102

12

Web-tier Authentication Schemes

? HTTP basic authentication based with or without SSL

? Form-based authentication based with or without SSL

? Client-certificate authentication based Has to use SSL

? Digest authentication based Does not need to use SSL

There are four authentication schemes at web-tier: HTTP basicauthentication, Form-based authentication, certificate-basedauthentication, and digest authentication.

These authentication schemes are basically categorized in terms of how

a browser collects user identification information and supply them to theweb container, that is, how to perform the logging-in process. Forexample, in basic authentication scheme, browser displays a defaultdialog box prompting a user to enter user name and password while incertificate-based authentication, the browser has to provide clientcertificate to the web container.

Now basic and form-based authentication can be done either with SSL orwithout SSL. Here, note that the SSL is used for confidentiality ofpassword not for client authentication.

Client certificate based authentication method should use SSL forsending client certificate to the web server while digest authenticationdoes not need SSL since the password will be in the form of messagedigest anyway, thus already secure.

01/04/2007


13/102

HTTP BasicHTTP BasicAuthentication-basedAuthentication-based

Web tier SecurityWeb 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 notonly authentication aspect but also access control and dataconfidentiality.

The reason we talk about all these in a singe scenario here is that Web-tier security scheme in fact addresses all these three security servicesin a very well-integrated and transparent fashion. And that is the reasonwhy I titled this sub-segment of the presentation as HTTP BasicAuthentication-based Web-tier security instead of just HTTP Basicauthentication.

01/04/2007


14/102

14

HTTP Basic Authentication

? Web server collects user identification(user name and password) through abrowser provided dialog box

? Not secure since user name andpassword are in easily decode'able formover the wire

Encoding scheme is Base64

Someone can easily decode it

Not encrypted

? Would need SSL for encrypting password

Now let's talk about HTTP basic authentication a bit. As I mentionedalready, in HTTP basic authentication, when a user tries to accessaccess controlled web resource and the user has not beenauthenticated yet, the web server will instruct the browser to displaydefault dialog box prompting user name and password from the user.

In fact, the web server will keep instructing the browser to display thedialog box until valid username and password get provided, that is, untilauthentication succeeds.

Once user name and password are entered by the user, they aretransported 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 calledsnooping) 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 besecurely 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


15/102

15

Steps for Basic Authentication-

based Web-tier Security1.Set up username, passwords, and roles

(realms)

2.Tell web container that you are using Basicauthentication

3.Specify which URLs (web resources) shouldbe access-controlled (password-protected)

4.Specify which URLs should be available only

with SSL (data integrity and confidentialityprotected)

Now let's go over the steps you have to take as a web -tier componentdeveloper and deployer to provide basic authentication. Form-basedauthentication follows pretty much the same steps except you have tocreate custom login page and custom login failure page as well.

First it is assumed that a system administrator set up backend databaseof username, password and roles. And, as was mentioned before, theseset of username, password, and roles for a particular domain is called arealm.

Second, you as a developer of web application has to tell web server thatyou are using basic authentication.

Third, you as a developer of web application has to tell the web serverwhich web resources need to be access controlled (or protected).

Fourth, you as a developer of web application has to tell the webcontainer which web pages should be available only with SSL. That is, ifyour web application need to get credit card information from thebrowser, you want to make sure any data that is being transportedbetween the browser and container is sent as SSL encrypted data, thusproviding confidentiality.

So let's go over each of these steps one by one.

01/04/2007


16/102

16

Step 1: Set up username,

passwords, and roles (Realms)? Schemes, APIs, and tools for setting up

usernames, passwords, and roles (realms) areweb container and operational environmentspecific

Flat-file based, Database, LDAP server

Passwords could be in either encrypted or unencryptedform

? Tomcat 4.0 can work with the following realms

default: file, unencrypted form Relational database (via JDBCRealm)

LDAP server (via LDAPRealm)

So step 1 is setting up username, password and roles. And I am callingthese username, password, and role information collectively as useridentification information. (Sometimes these are called user credential as

well.) The concept of roles are important. Each user belongs to a set ofroles. And the web container will perform access control based on roles.

Now the scheme of setting up these user identification information, thatis, setting up a realm, is container and operational environment specific.For example, different organizations will maintain the user identificationinformation in different places, for example, in a flat file, or in relationaldatabase, or in a LDAP server. And how these user identificationinformation is managed is container specific as well. And later on I willdemonstrate how Sun ONE App server 7 does that.

Also password information might be either in encrypted form or not. Forexample, as a default, Tomcat maintains user identification information in

a file in which password is not in encrypted form. However, Tomcat canwork other schemes such as relational database or LDAP server.

01/04/2007


17/102

17

Example: Tomcat's default? /config/tomcat-users.xml

? Unencrypted: not secure but easy to setup and maintain

So for Tomcat, the default is using a file called tomcat-users.xml underconfig directory. And this is a very simple example. Here three roles aredefined, manager, employee, and admin. And only one user has beendefined for username sang and his password is sangPassword. AndSang belongs to two roles, manager role and employee role.

01/04/2007


18/102

18

Step 2: Tell web container that you

are using Basic authentication

? Inweb.xml file of your web application

......

BASICrealm name

...

Now the next step is you, as a developer of web application, tells theweb container which login scheme you want to use. Here the Basicauthentication scheme has been chosen as a login scheme under login-config element of web.xml deployment descriptor.

01/04/2007


19/102

19

Step 3: Specify which URLs

should be access-controlled...

WRCollection

/loadpricelist

GET

admin

CONFIDENTIAL

BASIC

...

Once you define logging-in scheme, then you want to specify in web.xmldeployment descriptor which web resources, that is which URL's, are tobe 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 overweb resource whose name is WRCollection and whose URL happened tobe /localpricelist.

01/04/2007


20/102

20

Step 4: Specify which URLs should

be available only with SSL...

WRCollection

/loadpricelist

GET

admin

CONFIDENTIAL

BASIC

...

The next step is to specify again in web.xml deployment descriptor whichweb resources should be available only with SSL. That is, whenever auser access the web resource and has to send some data, the data onthe wire will be protected with SSL.

This is the web.xml deployment descriptor for the same web resource wesaw 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 withSSL by saying element is confidential

So in summary, you as a web component developer and deployer cantake two security measures, one is to specify who can access whatresource, the other is to specify which web resource can be accessedonly with SSL. And these two security measures can be takenindependently from each other or can be used together.

01/04/2007


21/102

Form-basedForm-basedAuthentication basedAuthentication based

Web-tier SecurityWeb-tier Security

Now let's talk about Form-based authentication. The way form-basedauthentication works is pretty much the same as basic authentication

but with just a little bit of more customization.

01/04/2007


22/102

22

Form-based Authentication

? Web application collects user identification(user name, password, and otherinformation) through a custom login page

? Not secure since user name andpassword are in easily decode'able formover the wire

Encoding scheme is Base64

Someone can easily decode it

Not encrypted

? Would need SSL for encrypting password

In form-based authentication scheme, web application collects useridentification information, again typically username, password, and otherinformation maybe date of birth, through custom login page as opposedto browser provided default dialog box as in the case of basicauthentication.

As in basic authentication, as a default, the username and password isbeing transported in easily decode'able form. That is, someone can sniffthe network traffic and retrieve the password and easily decode it.

So in order to provide password confidentiality, you need to use SSL sothat the password is transported in encrypted form.

01/04/2007


23/102

Form-Based Auth. Control Flow

3. Unauthenticated client

redirected

4. Login form returned to client

5. Client submits login form

6.Authentication Login succeeded,redirected to resource

7. Authorization Permission tested,result returned

8. Login failed, redirect to error page

9. Error page returned to client

1

2 ProtectedResource

Login.jsp j_security_check Error.html

Request ResponsePageLoginForm

Error Page

36 8

7 4 5 9

This picture shows the security control flow where form-basedauthentication is used as log-in scheme. The key point in this picture isthat all these control flow is taken care of by web container itselftransparently. So let's go over the scenario.

When a user tries to access access controlled web resource by sendingHTTP request, that is step 1, web container checks if the user has beenalready authenticated or not. And that is step 2.If the user has not been authenticated, in step 3, the web containerautomatically redirect the request to the login page. That is step 4.Again the key point here is that the web container does thisautomatically.

When the user enters username and password information and submitthrough a custom login page, in step 5, web container will perform theauthentication. That is step 6.

Once the user has been authenticated, the web container then checks ifthe user has proper access right to the web resource. If he does, theresult 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 whilethe dark blue boxes represent things that the container has to provide.

01/04/2007


24/102

24

Steps for Form-based Authentication

based Web-tier Security1.Set up username, passwords, and roles (realms)

2.Tell web container that you are using Form-basedauthentication

3.Create custom Login page

4.Create custom Login failure error page

5.Specify which URLs (web resources) should beaccess-controlled (password-protected)

6.Specify which URLs should be available only withSSL (data integrity and confidentiality protected)

So the steps for implementing and deploying form-based authenticationfor your web application is not that much different from the ones youfollow 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


25/102

25

Step 1: Set up username,

passwords, and roles (Realms)

? Same as in Basic-authentication

So step 1 is setting up username, password and roles. And this is thesame for basic authentication.

01/04/2007


26/102

26

Step 2: Tell web container that you

are using Form-based authentication


......

FORMrealm name

...

Now the next step is you as a developer of web application tells the webcontainer which login scheme you want to use. Here the FORMauthentication scheme has been chosen as a login scheme under login-config element of web.xml deployment descriptor.

01/04/2007


27/102

27

Step 3: Create custom Login Page

? Can be HTML or JSP page

? Contains HTML form like following

Some point, you have to provide a login page. The login page collectsuser identification information, that is, username and password through aHTML Form element here. And the action attribute has to have a valueof j_security_check and the names of username and passwordattributes of input element have to be j_username and j_password

respectively.

01/04/2007


28/102

28

Step 4: Create Login Failure page

? Can be HTML or JSP page

? No specific content is mandated

You also have to provide login failure page. This page can be staticHTML page or JSP page. And there is no requirement for specificcontent.

01/04/2007


29/102

29

Step 5: Specify which URLs should beaccess-controlled (Same as Basic Auth)

...

WRCollection

/loadpricelist

GET

admin

executive

CONFIDENTIAL

FORM

Once you define logging-in scheme, then you want to specify in web.xmldeployment descriptor which web resources, that is which URL's, are tobe 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 overweb resource whose name is WRCollection and whose URL happened tobe /localpricelist.

01/04/2007


30/102

30

Step 6: Specify which URLs should beavailable only with SSL (Same as Basic Auth)

...

WRCollection

/loadpricelistGET

admin

CONFIDENTIAL

FORM

...

The next step is to specify again in web.xml deployment descriptor whichweb resources should be available only with SSL. That is, whenever auser access the web resource, the data on the wire will be protected withSSL.

This is the web.xml deployment descriptor for the same web resource wesaw 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 withSSL by specifying element is confidential

So in summary, you as a web component developer and deployer cantake two security measures, one is to specify who can access whatresource, the other is to specify which web resource can be accessedonly with SSL. And these two security measures can be takenindependently from each other or can be used at the same time.

01/04/2007


31/102

Form-based

Basic vs. Form-based Authentication

Uses browserprovided dialog boxto get username and

password

Only username and

password can becollected

Might result in

different look and feel HTTP Authentication

header is used toconvey username andpassword

No good way to enter

Uses web applicationprovided login page toget username and

password

Custom data can be

collected

Can enforce consistentlook and feel

Form data is used toconvey username and

password

Can enter a new username via login page

Basic

Now since basic and form-based authentication schemes are the most commonlogging-in schemes, let's compare the two.

In Basic authentication scheme, the user name and password pair is collectedthrough 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 forexample 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 overbasic authentication is to provide same look and feel with the rest of webapplication.

Because the username/password pair is collected by the browser, in Basicauthentication, it is being transported as part of Http header structure while inForm-based authentication, it is transported as part of form data.

Now common thing between the two schemes is that the user identificationinformation is being transported as Base64 encoded scheme and thus neither issecure. Now you can use SSL to protect the password information on the wireon both schemes.

01/04/2007


32/102

Realm ManagementRealm Management

Now we touched upon realm management already. Now I would like totalk about it one more time so that you get some idea how things aredone in real life.

01/04/2007


33/102

33

Realm Management

? Management of user identityinformation username, password, roles, etc.

encrypted or unencrypted

? Container and operationalenvironment dependent Tomcat

? flat file based, RDBMS, LDAP

Sun ONE App server

So as was mentioned, realm is a set of user identification informationsuch as username, password, and roles. These user identificationinformation can be maintained in encrypted or unencrypted form.Obviously in production environment, you want to make sure thepasswords are maintained in encrypted form.

Now how the realms are maintained and managed are container specificand operational environment specific. For example, Tomcat containercan manage several realms, the default of which is flat-file based. But itcan also support relational database or LDAP. And same can be said forthe Sun ONE App server. Sun ONE App server, in addition to LDAP andrelational database, it can also support Solaris authentication modules.

01/04/2007


34/102

34

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 operatingsystem

At application deployment time, these abstract

security roles need to be mapped usernames,passwords, groups of operating system

? In production environment, an externalsecurity realm (LDAP) can be used both byweb application and OS

Now let's talk a bit on security roles. Since we already touched uponhow security roles are used in basic and form-based authenticationschemes, 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, ishow these usernames, passwords, especially roles are related to the

username/password/group maintained by the operating system, and thatis a valid question.

Since your web applications (for that matter web container) will bedeployed over many different OS'es, obviously your applications cannotmake any assumptions on the usernames, passwords, groups of theoperating system. Instead they use so-called abstract security rolesand these have to be mapped to the ones maintained by the OS somepoint. Obviously this could be a chore in production environment. So

what is done typically in production environment is to use externalsecurity realm database such as LDAP where both web environment and

OS share the same security realm.

01/04/2007


35/102

35

Example: Tomcat's default? /config/tomcat-users.xml

? Unencrypted: not secure but easy to setup and maintain

So for Tomcat, the default is using a file called tomcat-users.xml underconfig directory. And this is a very simple example. Here three roles aredefined, manager, employee, and admin. And only one user has beendefined for username sang and his password is sangPassword. AndSang belongs to two roles, manager role and employee role.

01/04/2007


36/102

36

Tomcat's default? Flat file based realm is maintained in

/config/tomcat-users.xml

? You can change it in one of two ways manually

admintool

So you can add,remove, modify realm information using Container specifictools. For flat-file based realm, you can add, remove, modify usernames,

passwords, and roles either manually changing the tomcat-users.xml file ujnderconfig directory or you can use admintool.

01/04/2007


37/102

37

Tomcat's admintool

So this is the Tomcat's admin tool. You can go to Tomcat's admin tool throughyour 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/102

38

Sun App Server Admin Console

This is an admin concole of Sun ONE App server. Throughthis admin console, you can select a default realm and thenfor that realm, you can add, remove, modify usernames,passwords, and roles.

01/04/2007


39/102

39

How to Create Custom Realms?

? For Tomcat jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-

howto.html

? For Sun Java System App Server Security document that comes with Sun Java System App

Server

Tomcat has a document you can refer to when you want to create custom realmsand the webpage location of the document is as specified in the slide.

01/04/2007


40/102

How to SecureHow to SecurePasswords on the wirePasswords on the wire

for Basic and Form-for Basic and Form-based Authenticationsbased Authentications

01/04/2007


41/102

41

Confidentiality of Passwords

? For Basic and Form-based authentication,unless explicitly specified, the password getstransported in unencrypted form (Base64)

? Same confidentiality declaration as regulardata If you select CONFIDENTIAL or INTEGRAL on a

security constraint, that type of security constraint

applies to all requests that match the URLpatterns in the Web resource collection, not just

to the login dialog

Uses SSL underneath

OK, we talked about using Basic and Form-based authenticationschemes as ways to collect username and password. And as mentionedbefore, the default is that the password information gets transported ineasily decode'able Base64 encoding scheme. Now if you want toprevent someone who has bad intention from reading the password while

it is one the wire, you have to send the password in encrypted form usingSSL.

Now how do you do this for password encryption? Well you actually usethe same deployment descriptor element for encrypting sensitive data forencrypting password. So in a sense, you regard password as a kind ofsensitive data between a browser and web server. And you useCONFIDENTIAL as a value for element under element as we will see in the following slide.

01/04/2007


42/102

42

SSL-enabled Confidentiality applies to

All traffic Including Password...

WRCollection

/loadpricelist

GET

admin

CONFIDENTIAL

FORM

...

So this is the fragment of web.xml file that specifies that password thathas been collected through custom login page needs to be transported inSSL-encrypted form. As you can tell, you specify a single element with CONFIDENTIAL value for instructing the webcontainer to transport the password and client entered data in SSL-

encrypted form.

01/04/2007


43/102

Web-tier SecurityWeb-tier SecurityImplementationImplementation

GuidelinesGuidelines

I have a section for implementation and deployment guidelines for web-tier security.

01/04/2007


44/102

44

Switching between SSL and non-

SSL protected Web resources? Once you switch to SSL, do not accept

any further requests for that session thatare 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

Someone asked me a question two weeks ago when we were talkingabout URL rewriting. The question was what would be the securityimplication of using URL rewriting? Given that the session ID is in clear-text form, wouldn't it expose it security risk? That is a valid question. Infact, this is the reason I am talking about this SSL implementation

guideline here.

01/04/2007


45/102

45

SSL is Expensive

? Use SSL only for web resources that need securityprotection

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 Webapplication over SSL, and it is customary for a developer to decide which pagesrequire a secure connection and which do not. Pages that might require a secure

connection include login pages, personal information pages, shopping cartcheckouts, or any pages where credit card information could possibly betransmitted.

Any page within an application can be requested over a secure socket by simplyprefixing the address with https: instead of http:. Any pages which absolutelyrequire 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


46/102

46

Ant Operations

? Some of you have experienced thefollowing ant build works OK

ant install or ant deploy failure with HTTP 401

error condition

? Why? because ant install and ant deploy is accessing

password-protected resource and you were not

providing correct userid/password pair? maybe due to non-existence of build.properties

file

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

T

01/04/2007


47/102

47

Marty Hall's Sample code Demo? Download the sample binary and source code

from

http://www.moreservlets.com (select Source

code archive)

? Unzip into

? Copy *.war files under /Security-Code into /webapps directory

? Add new usernames, roles (the ones used bythe code) appropriately to your Tomcat

environment (tomcat-users.xml)? Restart Tomcat

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 allthe *.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 thatMarty's program uses. You can do it either manually or Tomcat's admintool. Once you've done that, you restart Tomcat. Now you can playaround the code.

01/04/2007


48/102

48

Basic Authentication Demo? Marty Hall's Sample code (hotdotcom-

internal.war, http://www.coreservlets.com/)

Financial plan page: available to all employees

Business plan page: available only toexecutives

Employee compensation plan: available to all

employees

? Try to access access controlled page

? Enter bogus username & password

? Enter valid username & password but whodoes not have access right (does not belong toa proper role)

This is Basic authentication demo that we are going to go over the source codeas well. You can get the complete source and binary code from Marty'swebsite, whose address is http://www.coreservlets.com/ and select Sourcecode archive.

01/04/2007


49/102

49

Basic Authentication Demo

So when you go to the http://localhost:8080/hotdotcom-internal/ from yourbrowser, this is the screen you will see. This page is not protected, whichmeans 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 authenticateyourself first. That is what you will see in the next slide.

01/04/2007


50/102

50

Access access controlled page

with bogus username

So here you click Financial planning page, and you receive a dialog box inwhich you can enter username and password.

01/04/2007


51/102

51

Access access controlled page

with valid username

If you entered a valid username and password but if the user does not haveaccess right to access this page, this is what you will get.

Now, you will keep getting this error page continuously no matter what youdo. 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, thereis not a good way to enter different username and password. This is one of theproblem of using Basic authentication. Form-based authentication does nothave this problem.

01/04/2007


52/102

Demo:Demo:

Form-basedForm-basedAuthenticationAuthentication

01/04/2007


53/102

53

Form-based Authentication

Now this is the form-based authentication demo. Go to http://localhost:8080/hotdotcom/ in your browser.

01/04/2007


54/102

54

Custom login page

In formed based authentication, when you access access controlled(protected) web page, you get a custom login dialog box. And this is anexample.

01/04/2007


55/102

55

Custom error page

Same thing with login failure error page. Instead of default behavior of basicauthentication (keep displaying login dialog box), you get a customized loginfailure page.

01/04/2007


56/102

Client Certificate-basedClient Certificate-based

AuthenticationAuthentication

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

01/04/2007


57/102

57

Why Certificate-based

Authentication?? Username/password authentication

cannot be used between program toprogram authentication Certificates may identify end-users, business

organizations, servers, software entities

? Username/password pair might notprovide enough credentials

Certificate can contain much more thanusername and password

As I mentioned, Basic authentication and Form-based authentications themost popular web-tier security schemes of today. Now both of theseschemes assume that client is an end-user who enters userid/passwordinformation through either browser-provided login dialog box (basicauthentication) or custom login page (form-based authentication).

Now there are times the client is not an end-user. For example, the clientcould be a program entity. In this case, basic-authentication and form-basedauthentication cannot be used. And because a certificate can be used toidentity end-users, business organizations, software entities, and servers,certificate based authentication can be used when the client is, for example, asoftware entity. That is, it is the software entity that sends HTTP request tothe Web application.

Another reason you might want to use certificate-based authenticationscheme is when more than username and password pair needs to be

conveyed to the Web application as identity information. Again, certificatebased authentication would be a better choice here since certificate cancontain more than user name and password.

01/04/2007


58/102

58

Certificate-based Authentication

? Client authentication server verifies client's identity

? Server authentication client verifies server's identity

occurs transparently in SSL-based browser andweb server communication

? Mutual authentication

both server and client verify each other's identity

There are 3 different kinds of certificate authentication depending onwho authenticate whom. Client authentication means it is the serverwho authenticates the client. That is, it is the server who verifies theclient's identity. Server authentication is the opposite. It is the client

who verifies the server's identity. Mutual authentication means bothserver and client verify each other's identity.

01/04/2007


59/102

59

Certificate Formats? Standard Certificate format is X.509

? X.509 does specify the format of thecertificate but does not specify howcertificates are exchanged

? SSL specifies how certificates areexchanged

(to be added)

01/04/2007


60/102

60

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 createdbeforehand for each browser based client Not as popular as Basic or Form-based

authentication because of this reason? Uses SSL over HTTP

This slide is about client certificate-based authentication, which is the 3rd formof authentication at web-tier.

In client certificate-based authentication, client gets authenticated by sendingclient certificate to the web server. That is, instead of sending user nameand 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 herein this context.

Now I mentioned before that SSL is used to protect the data while it is on thewire. That is, SSL is used to provide data confidentiality between the browserand the web server. As part of this, server does authenticate itself to thebrowser by sending its own certificate as a proof of its identification. So whenpeople say mutual authentication, they are talking about a scenario in whichclient certificate based authentication also occurs in addition to serverauthentication.

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 meansthat every client has to have its own certificate. This could be an issue interms of client management especially when the server does not know who itsclients are. This is the reason why the client certificate based authenticationis only rarely used compared to basic or form-based authentication.

And of course, it is based on SSL over HTTP.

01/04/2007


61/102

61

Tell web container that you are

using Client-Cert authentication


......

CLIENT-CERTrealm name

...

This is the fragment of web.xml deployment descriptor indicating that youas a deployer of this web application wants to use Client certificatebased authentication. Here you say CLIENT-CERT as value of element.

01/04/2007


62/102

DigestDigest

AuthenticationAuthentication

OK, we talked about 3 web-tier authentication methods - basic, form-based, client-certificate based. Now let's talk about the lastauthentication method, digest authentication.

01/04/2007


63/102

63

Digest Authentication? User password is transformed into digested

form before being sent to the server

You cannot get the original password from thedigested password (property of message digesting)

Even a single bit of change of original passwordresults in different digested password value

No cleartext (or uuencoded) user password on thewire even without on a non-SSL connection

? Server compares the passed digested value

with its own, if matched, then authenticationsucceeds

In digest authentication, user password is transformed into a hashed formbefore being sent to the server. This method is taking advantage of twomathematical properties of messaging digesting. The first one is that it is

practically impossible to make a guess of the original value from the messagedigest. 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 SSLwithout being concerned about confidentiality because it would be impossiblefor someone can take the value and make a guess of original password.

Now when the server receives the digested password value, it will then compareit with its own version of digested value. And if they match, thenauthentication is successful.

01/04/2007


64/102

64

Tell web container that you are

using Digest authentication? Inweb.xml file of your web application

......

DIGESTrealm name

...

This is the fragment of web.xml deployment descriptor indicating that youas a deployer of this web application wants to use message digestauthentication. Here you say DIGEST as value of element.

01/04/2007


65/102

AuthorizationAuthorization

(Access Control)(Access Control)

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

01/04/2007


66/102

66

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

Over J2EE architecture, 4 different types of access control canoccur. And they can be categorized based on where access controloccurs, for example, web-tier versus EJB-tier, or how the accesscontrol is done, declarative versus programmatic access control.So let's talk about these in a bit more detail.

01/04/2007


67/102

EJB-tier

Web-tier vs. EJB-tier

(D) Access controlto Web resources

(D) Declared inweb.xml

(D) Enforced byweb container

(P) Coded inservlet or JSP

(D) Access control tobean methods

(D) Declared in EJBdeploymentdescriptor

(D) Enforced by EJBcontainer

(P) Coded in EJBbean

Web-tier

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

First let's compare web-tier access control versus EJB-tier accesscontrol. At both tiers, there could be both declarative and programmaticaccess 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 tothe bean methods.

At web tier, the declarative access control is specified within web.xmldeployment descriptor while at EJB tier, it is specified at EJBdeployment 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 programmaticaccess control logic is coded in servlet or JSP pages while in EJB tier, it

is coded within EJB beans.

01/04/2007


68/102

Programmatic

Declarative vs. Programmatic

Access control isdeclared indeploymentdescriptor

Container handlesaccess control

Does not handle

fine-grainedaccess control, itis all or nothingdeal

Access control iscoded in yourprogram

Your code handlesaccess control

Can handle fine-grained access

control, i.e. instance-based or businesslogic based accesscontrol

Declarative

Now let's compare declarative access control againstprogrammatic access control.

In declarative access control, the access control logic isdeclaratively specified in deployment descriptor and then it is

the container that handles the access control. In programmaticaccess control, on the other hand, the access control logic iscoded in your program.

By the way, declarative access control can be used together withprogrammatic access control.

Now the reason you might want to implement programmaticaccess 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 particularinstance of your bean or based on business logic. For example,as we will see an example later on, if you want to say anemployee can see only his or her own salary information, youhave to use programmatic access control.

01/04/2007


69/102

DeclarativeDeclarative

AuthorizationAuthorizationat Web-tierat Web-tier

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

01/04/2007


70/102

70

Steps for Declarative

Authorization at Web-tier

1.Deployer maps actual user identities tosecurity roles using vendor specific tools

2.Deployer declares security roles in thedeployment descriptor

3.Deployer declares URL permissions in thedeployment descriptor for each security role

This is already covered above under Web-tiersecurity schemes segment!

Now how do you implement declarative access control at web-tier? One of the nice thing about using declarative accesscontrol is that the web application developer does not reallyhave 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 deploymentdescriptor and it is the responsibility for the container toenforce the access control.

By the way, we dealt with this declarative access control whenwe talk about authentication in this session especially underthe context of basic and form-based authentication.

First, it is assumed that the deployer or system administratorhave mapped user identities to security roles.

Then, the deployer declares security roles. Then he declaresURL permissions to the deployment descriptor for eachsecurity role. And we have seen the example of it before.

01/04/2007


71/102

ProgrammaticProgrammatic

AuthorizationAuthorizationat Web-tierat Web-tier

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

01/04/2007


72/102

72

Declarative and Programmatic

Authorization (Access Control)? They are usually used together

Declarative access control for role-based accesscontrol

Programmatic access control for user instance-based and business logic based access control

? User instance

? Time of the day

?

Parameters of the request? Internal state of the web component

Now before I talk about programmatic access control, let me tell you thatdeclarative and programmatic access control schemes are typically usedtogether. Declarative access control is used for role-based access control while

programmatic access control is used for user instance-based and business logicbased 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, forexample, object instance, time of the day, parameters of the request, andinternal state of the web component.

01/04/2007


73/102

73

Steps for Programmatic

Authorization at Web-tier

1.Set up username, passwords, and roles(realms)

2.Servlet programmer writes programmaticauthorization logic inside the Servlet codeusing abstract security roles

3.Deployer maps abstract security roles toactual roles (for a particular operational

environment) in the web.xml

This is the list of steps for performing programmaticauthorization at web-tier.

First, just like in declarative environment, it is expected thatsystem administrator has set up security realms meaning

username, password and roles are set up.

Then servlet programmers write programmatic authorizationlogic inside the code using security roles.

Now when the web application gets deployed in a particularoperational environment, deployer then maps these abstractsecurity roles to actual roles in that particular operationalenvironment.

01/04/2007


74/102

74

Step 2: Servlet Programmer writes

programmatic authorization logicpublic 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);

...

}

At Web-tier, there are 3 methods which quite similar to theones at EJB-tier. For example, getting caller's Principalobject 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 anymore time on this.

01/04/2007


75/102

75

Example: Employees can onlyaccess 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);

}

}

So in this example, the access control logic says thatmanager role can read salary information of everyone whileemployee role can read only his or her salary information. Sohere you get the caller's principal object and get the caller idstring from it and check if that matches the employee id that ispassed as a parameter.

01/04/2007


76/102

76

Step 3: Deployer maps abstract

security roles to actual roles

...

...

...

manager managerOfAcme

...

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

01/04/2007


77/102

ProgrammaticProgrammatic

AuthenticationAuthenticationat Web-tierat Web-tier

This is about programmatic authentication at web-tier. As I will talkabout in the following slide, this is presented here to give you a sensehow the web containers performs the authentication in the case you usedeclarative authentication such as basic authentication and form-based

authentication. In practice, this is rarely used.

01/04/2007


78/102

78

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

So in programmatic authentication at web-tier, the web application takesresponsibility in the code for making sure the user is who he claims he is. Youget some more control by doing this but the benefit is rather marginal and in

practice, it is rarely used.

01/04/2007


79/102

79

Steps for Programmatic

Authentication at Web-tier? Check if there is authorization header

? Decode the Base64 encoded username andpassword

? Check username/password pair againstsecurity 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

So these are the steps you follow for performing programmatic authentication atweb-tier.

First, you check if the user sends proper username and password in theauthorization header of the HTTP request. If not, you want to ask the user toenter proper username and password. Again, in declarative authentication, thisis done automatically by the container.

The username and password that are entered by the user then will betransported 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 amatch between the ones that the user entered and the ones in the backend realmdatabase. If matched, the authentication succeeds, then you perform accesscontrol. Otherwise, you ask for a new username and password.

01/04/2007


80/102

80

Check if there is authentication

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

...

So this is the sample code from Marty Hall's sample code. Here you get theauthorization block. If the block is null, that means, the user tries to accessthis servlet without proper username and password. So you display the logindialog box prompting username and password.

01/04/2007


81/102

81

Decode Username and Password

if (authorization == null) {askForPassword(response);

} else {String userInfo =

authorization.substring(6).trim();BASE64Decoder decoder = new BASE64Decoder();String nameAndPassword =

newString(decoder.decodeBuffer(userInfo));

int index = nameAndPassword.indexOf(":");String user =

nameAndPassword.substring(0, index);

String password =nameAndPassword.substring(index+1);...

If the user entered username and password, then your code have to decodethem.

01/04/2007


82/102

82

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 & passwordif (areEqualReversed(user, password)) {

showStock(request, response);} else {

askForPassword(response);}

}}

Then your code compares if the username and password pair is matches one inthe backend realm database.

In this code, if match occurs, we send back the page. So we do not perform theaccess control here. Otherwise, you again send a page asking the user to entervalid username and password.

01/04/2007


83/102

83

Open App Server Admin Console

So I am going to add the username and password pair to thefile-based realm of the Sun ONE App server. Here as you cansee on the left side of the screen, Sun ONE app serversupports multiple realms, for example file based realm, ldapbased realm, and certificate based realm. At this point, the

file-based realm is set as a default realm. What it means isthat the userid/password pair entered by the user will bechecked against the user identification information maintainedin the file.

So what I am going to do here is to add theusername/password pair to the file based realm by selectingManaging users.

01/04/2007


84/102

84

Add Userid/Password Pair to File Realm

Now I can add or delete username and password. Thisscreen shows add a user screen. So I am adding sang100and sangpassword. Once the pair is added, the change hasto 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/102

85

Restart App Server

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

01/04/2007


86/102

Sun Java SystemSun Java SystemApp Server 8App Server 8

Security FeaturesSecurity Features

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

01/04/2007


87/102

87

Sun Java System App ServerJ2EE Security Features

Declarative and programmatic security

Realm administration file, LDAP, certificate, Solaris-based realms

Pluggable authentication via JAAS You can add custom realm

Single sign-on (value-add) Same authenticate state shared among

multiple J2EE applications

Programmatic login (value-add)

Sun ONE App server is j2EE 1.3 compliant so it supports bothdeclarative and programmatic security.

It also supports different schemes where realms can be

maintained. As I mentioned before, a realm is a set of useridentity information such as username, password, and roles for aparticular domain. And a realm can be maintained in differentschemes. For example, Sun ONE App server supports file-based,LDAP-based, certificate based, and Solaris based realms.

It also supports pluggable authentication framework using JAASframework. In fact, you can add your own custom realms. Forexample, you can add relational database based realm in whichuser identification information is maintained in a relationaldatabase.

As Sun ONE App server 7 specific value-add features, it supportssingle sign on in which same authenticate state can be sharedamong multiple J2EE applications.

It also supports programmatic login in which you can performcustom login scheme.

01/04/2007


88/102

DemoDemo(Sun Java System(Sun Java System

App Server Security)App Server Security)

OK, now it is demo time. The demo I am going to show is usingSun ONE app server admin console to add a username and passwordto file-based realm. By the way, as I mentioned earlier, the termrealm 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 securityrealm to Sun ONE app server.

01/04/2007


89/102

89

Demo1: Basic Authentication1. 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 logindialog box

4. Enter an invalid userid/password pair

Container keep asking browser to display dialog box

5. Using Sun App Server Admin console, add theuserid/password pair to the userid/password file-basedrealm

6. Restart Sun App Server

7. Access the protected web resource again

In the first demo, let's assume I already deployed an accesscontrolled web resource whose URL ishttp://localhost:80/basic/index.jsp. So when you access thispage, the web container instructs the browser to pop up adialog box prompting you to enter userid and password.

For a demo purpose, I will enter invalid userid and passwordpair. 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, Iam going to add the userid/password pair to the file basedrealm which is being used as a default realm right now.

01/04/2007


90/102

90

Enter invaliduserid/password

So this is the dialog box you will receive when you access theaccess controlled page, http://localhost:80/basic/index.jsp.Now I am going to enter invalid userid/password pair. So I amentering sang100 and sangpassword. Now since the pair isinvalid username and password, the container will keep asking

the browser to display this dialog box.

01/04/2007


91/102

91

Authentication Failed

If you select cancel button, the browser then displays an errorcondition. Here it says the request requires authenticationbecause it tried to access access-controlled page.

01/04/2007


92/102

92





01/04/2007


93/102

93

Add Userid/Password Pair to File Realm

Now I can add or delete username and password. Thisscreen shows add a user screen. So I am adding sang100and sangpassword. Once the pair is added, the change hasto 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


94/102

94

Restart App Server

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

01/04/2007


95/102

Sun Java SystemSun Java SystemApp Server 8App Server 8

Security FeaturesSecurity Features

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

01/04/2007


96/102

96

Sun Java System App Server J2EESecurity Features

Declarative and programmatic security

Realm administration file, LDAP, certificate, Solaris-based realms

Pluggable authentication via JAAS You can add custom realm

Single sign-on (value-add)

Same authenticate state shared amongmultiple J2EE applications

Programmatic login (value-add)

Sun ONE App server is j2EE 1.3 compliant so it supports bothdeclarative and programmatic security.

It also supports different schemes where realms can bemaintained. As I mentioned before, a realm is a set of useridentity information such as username, password, and roles for aparticular domain. And a realm can be maintained in differentschemes. For example, Sun ONE App server supports file-based,LDAP-based, certificate based, and Solaris based realms.

It also supports pluggable authentication framework using JAASframework. In fact, you can add your own custom realms. Forexample, you can add relational database based realm in whichuser identification information is maintained in a relationaldatabase.

As Sun ONE App server 7 specific value-add features, it supportssingle sign on in which same authenticate state can be sharedamong multiple J2EE applications.

It also supports programmatic login in which you can performcustom login scheme.

01/04/2007


97/102

DemoDemo(Sun Java System(Sun Java System

App Server Security)App Server Security)

OK, now it is demo time. The demo I am going to show is usingSun ONE app server admin console to add a username and passwordto file-based realm. By the way, as I mentioned earlier, the termrealm 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 securityrealm to Sun ONE app server.

01/04/2007


98/102

98





01/04/2007


99/102

99

Access the Protected Page Again andEnter the same userid/password pair

Now if I access the same page and enters the same useridand password, I can access the page successfully.

01/04/2007


100/102

100

Demo2: Add Custom Realm

? Add JDBC custom realm

? Use pointbase or Oracle database asstorage of userid/password information(instead of file realm)

The second demo is to add JDBC realm to the Sun ONE Appserver. You can use any JDBC compatible relationaldatabase such as pointbase or Oracle database.

01/04/2007


101/102

101

Use JDBC Realm as Default Realm

So by using Sun App Server's admin control, you can add acustom realm and then set the App server to use the customrealm as a default realm.

01/04/2007


102/102

Passion!Passion!

01/04/2007

Documents

WebApplicationSecurity102