1.

Trouble lurks in every corner of the network

2. Impersonators : Im XXX,Eavesdroppers : I got his credit card info
3. Big 4 in Security
a. Authentication : he is who he says hei is.Passowrds
b. Authorization : user has access to info
c. Confidentiality : encrypt the data
d. Data Intergration : the data was not modified,send confirmation code
4. Below is the skimmed out story of what the container does
5.

6. When designing servlets separate browsing capabilities with updating

capabilities
7. When Sun designs J2EE specs (EJBs,Servlets ,JSP), they think in terms of
create and administer these components,IT-related roles.When developers
tackle security for we-apps they think about the types of users that might
exist.user roles- guest,member admin.These roles are defined,mapped and
fretted over in the DD.
8. Cross site hacking : free text is rendered by unsuspecting browsers
9. A user cant be authorized until hes authenticated
10.All container vendors provide a way to hook into your company specific
authentication data,often stored in relational database or LDAP system.
11.Realm : Security realm is an overloaded term.As far as servlet spec is
conserned a realm is where authentication information is stored.
12.Every AS vendor gives a vendor specific users file to define the roles. It can
also contain username and password, however that is not recommended, coz

tomcat reads this file only once during app start up in memory. Its commonly
known as memory realm

13.How to get the container to ask for username and password : Putting the
below in DD

14.Authorization Step 1 : Defining roles

Most common form of authorization in servlets is for the container to
determine whether the specific servlet and the invoking HTTP request
method can be called by a user who has been assigned a certain security
role.
So the first step is to map the roles in the vendor specific users file to roles
established in the DD.

15.Authorization step 2: Defining resource/method constraints

Specify declaratively that a given resource/method combination is accessible
only by users in certain roles.

16.<url-pattern> : one or more

<http-method>: (optional,zero or more): if no method specified all are
constrained.
<web-resource-name>: mandatory element
<auth-constraint>:applies to all <web-resource-collection> elements in the
<security-constraint>
17.Constraints are not at resource level. Constraints are at HTTP request level.
18.All HTTP methods that you do not specify are UN-constrained : That means
anybody regardless of security role(or even regardless of whether the client is
authenticated ), can invoke those HTTP methods

19.Dueling <auth-constraint> element : union of both

20.Why would anyone put <auth-constraint/>

It means resource cant be accessed from outside the web-app, client cant
access the constrained resource but other parts of web-app can.You might
want to use a request dispatcher to forward to other parts of web-app, but
you dont want clients to access
that resource.
21.Programmatic Security

i.
j.

Why the isUserInRole() above?

What if role Manager used above is not part of your organization or if its
is, but it might mean different than what the programmer intended.
Ans i: allow access to parts of method instead of authorizing at the http
method level. Thus gives you a way of how a method behaves based on
users role.
a. Container returns false if user is not authenticated for isUSerInRole().
b. Else returns true if user is mapped to this role
And j: <security-role-ref>

22.Four types of authentication container can provide, difference between them

is how securely is name and password info transmitted.
a. BASIC Authentication : transmits the login information in an encoded
(not encrypted) form.Bus since Base64 is widely known this provides
weak security
b. DIGEST Authentication : transmits login information in a more secure
way , but containers must support the necrytion mechanism
c. CLIENT-CERT : transmits information in a very secure way but client
must have a certificate before they can login.Used in B2B scenario
d. FORM : The three types above all use the browsers standard pop-up
form for submitting the name and password. But FORM is different.

By default is least secure way, no encryption but can be configured to

use J2EE containers data integrity and confidentiality features

23.Form based Authtication :

24.Securing data in transit :HTTPS to the rescue

When you tell a J2EE container that you want to implement confidentiality or
integrity, the J2EE spec guarantees that data to be transmitted will travel
over a protected transport layer connection.Thus the container will use
HTTPS over SSL
25.How to implement data confidentiality and integrity sparingly and
declaratively

26.Protecting the request data

The <security-constarint> comes into picture once a request is made
How to make sure that the request data is protected ??
The container does not respond with the login pop up if connection the
request has a transport

27.To make sure clients login info is submitted to the server securely put a
transport guarantee on every constrained resource that could trigger a login
process.