1. Trouble lurks in every corner of the network2. Impersonators : Im XXX,Eavesdroppers : I got his credit card info3. Big 4 in Securitya. Authentication : he is who he says hei is.Passowrdsb. Authorization : user has access to infoc. Confidentiality : encrypt the datad. Data Intergration : the data was not modified,send confirmation code4. Below is the skimmed out story of what the container does5.

6. When designing servlets separate browsing capabilities with updating capabilities7. 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 browsers9. A user cant be authorized until hes authenticated10. 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 rolesMost 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 constraintsSpecify declaratively that a given resource/method combination is accessible only by users in certain roles.

16. : one or more: (optional,zero or more): if no method specified all are constrained.: mandatory element:applies to all elements in the 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 element : union of both

20. Why would anyone put 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. Why the isUserInRole() above?j. 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 roleAnd j:

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 securityb. DIGEST Authentication : transmits login information in a more secure way , but containers must support the necrytion mechanismc. CLIENT-CERT : transmits information in a very secure way but client must have a certificate before they can login.Used in B2B scenariod. 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 rescueWhen 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 SSL25. How to implement data confidentiality and integrity sparingly and declaratively

26. Protecting the request dataThe 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.