· 7 years ago · Jan 05, 2019, 03:36 PM
1//// http://ocejwcd.wikidot.com/
2
3//15043 a 15840
4//Capitulo 12 Security.
5
6 Main concepts
7 Authentication -> password and username
8 Authorization -> have a role?
9 Confidentiality ->
10 Data Integrity ->
11
12 *A slightly closer look at how the Container does authentication and authorization.
13 Container receive a request.
14 Finds the URL in the "security table"
15 If finds the URL in the security table, it checks to see wether the requested resource is constrained. If it is, it returns 401
16
17 When te container receives a request with a pass and username., it checks the URL in the security table.
18 If it finds the URL in the security table, and sees that its constrained, it checks user and pass to make sure they match
19 If match, the container checks if the user has been assigned the correct role to acces this resource.
20
21 *Authentication -> An user cant be authorized until hes been authenticated.
22 realm -> is a place where authentication information is istored. We can use tomcat-users.xml(located in tomcat cons/directory, not within webapps) when we are testing our application.
23 That one tomcat file applies to ALL applications deployed under web-apps. AKA memory realm.
24 tomcat-users.xml
25 <tomcat-users>
26 <role rolename="Guest"/>
27 <role rolaname="Member"/>
28 <role username="Bill" password="coder" roles="Member, Guest"/>
29 </tomcat-users>
30
31 Enabling authentication-> To get container to ask for a username/password, we need to stick something in the DD.
32 <login-config>
33 <auth-method>BASIC</auth-method>
34 </login-config>
35
36 *Authorization
37 Step1: Defining roles->
38 Vendor Specific:
39 The <role> element in tomcat-users.xml
40 <tomcat-users>
41 <role rolename="Guest"/>
42 <role rolaname="Member"/>
43 <role username="Bill" password="coder" roles="Member, Guest"/>
44 </tomcat-users>
45 Servlet-specification
46 The DD <security-role> in web.xml
47 <security-role><role-name>Admin</role-name></security-role>
48 <security-role><role-name>Member</role-name></security-role>
49 <security-role><role-name>Guest</role-name></security-role>
50 <login-config> // dont forget it, enables the container to ask userName/password
51 <auth-method>BASIC</auth-method>
52 </login-config>
53
54 Step2> Definning resource/method constraints
55 That given a resource/method combination is accessible only by users in certain roles.
56 web.xml
57 <web-app...>
58 <security-constraint>
59 <web-resource-collection>
60
61 <url-pattern>/Beer/AddRecipe/*</url-pattern> */ //THESE TWO RESOURCES ARE CONSTRAINED!
62 <url-pattern>/Beer/ReviewRecipe/*</url-pattern> */
63
64 <http-method>GET</http-method> //DESCRIBES WICH HTTP METHODS ARE CONSTRAINED
65 <http-method>POST</http-method>
66
67 </web-resource-collection>
68
69 <auth-constraint> //Optional, WHO IS ALLOWED TO DO A GET OR POST IN THE SPECIFIC URL!
70 <role-name>Admin</role-name>
71 <role-name>Member</role-name>
72 </auth-constraint>
73 </security-constraint>
74 </web-app>
75
76 The security-constraint rules for <web-resource-collection> elements
77 The purpose of the <web-resource-collection> sub-elements is to tell the container wich resources and HTTP method combinations should
78 be constrained in such a way that they can be accessed only by the roles in the corresponding <auth-constraint> tag.
79 //Bullets points 15319
80
81 *If no http-method is specified, all methods will be constrained.
82
83 The <web-resource-collection> sub-element of <security-constraint>
84
85 <web-resource-collection>
86 <web-resource-name>
87 UpdateRecipes
88 </web-resource-name>
89 ...
90
91 Constraints are not at the RESOURCE level, Constraints are at the HTTP REQUEST level.
92 Its a combination of Resource + HTTP Method that be constrained.
93 Bob is a member, so bob can access the AddRecipe -> WRONG WAY OF THINKING
94 Bob is a member, so Bob can make a GET or POST request on the AddRecipe -> RIGHT WAY OF THINKING!!!
95
96
97 <security-constraint> rules for <auth-constraint> sub-elements.
98 The sub-element speccifies wich roles are ALLOWED to acces the web resources specified by the <web-resource-collection>
99 <auth-constraint> sub-element of <security-constraint>
100 <auth-constraint> //Optional, WHO IS ALLOWED TO DO A GET OR POST ON THE SPECIFIC URL!
101 <role-name>Admin</role-name>
102 <role-name>Member</role-name>
103 </auth-constraint>
104
105 <role-name> rules
106 1) within <auth-constraint> the <role-name> element is optional.
107 2) if <role-name> elements exist, they tell the container wich roles are allowed.
108 3) if an <auth-constraint> element exist with NO <role-name> THEN NO USER ARE ALLOWED.
109 4) <role-name>*</role-name> ALL USER ARE ALLOWED.
110 5) ROLE NAMES ARE CASE SENSITIVE!
111 <auth-constraint> rules
112 1) within a <security-constraint> , the <auth-constraint> elemen is OPTIONAL.
113 2) IF EXISTS, the container must perfomr authentication for the associated URLS.
114 3) if an <auth-constraint> does not exist, the container must allow unauthenticated access for these urls.
115 4)we can add <description> inside <auth-constraint>
116
117 The way <auth-constraint> works
118 //imagem legal em 15383, ler/ver!
119 <auth-constraint>
120 <role-name>*</role-name>
121 </auth-constraint>
122 é igual a se nao tivessemos um <auth-constraint>
123 OS DOIS DEIXAM TODO MUNDO ACESSAR NOSSO CONTEUDO!
124 <security-constraint>
125 <auth-constraint/>
126 </security-constraint>
127 Aqui ninguem tem acesso.
128
129 How multiple constrains elements interact?
130 If X enables to DO a request and Y negate the same request, how it works? //15400
131 Contents of A Contents of B
132 <role-name>Guest</role-name> <role-name>Admin</role-name>
133 If these two roles point to the same Resource, then the resource are allowd by Admin and Guest.!
134
135 ***
136 <auth-constraint/> <auth-constraint> <role-name>Admin</role-name </auth-constraint>
137 IH THIS CASE NOBODY CAN ACCESS THE RESOURCE!
138
139 No <auth-constraint> <auth-constraint> <role-name>Admin</role-name </auth-constraint>
140 In this case everybody can access the resource!
141
142 1) When combinning individual role names, all of the role names listed will be allowed
143 2) A rola name of * combines with anything, allow everybody access to the resource
144 3) An empty <auth-constraint/> deny all access
145 4) If there no <auth-constraint> everybody can access.
146
147 <auth-constraint/> NO ONES FROM OUTSIDE the webapp can access.
148
149 //esse tipo de segurança que vimos é a declarative! Tem tambem a programaticaly.
150
151 Programaticaly
152 in our servlet
153 if ( request.isUserInRole("Manager")) {
154 ....
155 }
156 In HttpServletRequest we have three methods associated with programmatic security.
157 getUserPrincipal(); // MAINLY IN EJB, DOENST IN THE EXAM
158 getRemoteUser(); // Check authentication status, not commomnly used. DOOESNT IN THE EXAM
159
160 isUserInRole(); // Instead authorizing the HTTP POST/GET... we can authorize access to portions of a method.
161 //Thats gives a way to customize how a service method behaves based on the users role.
162
163 *How to matchup Roles in the DD with roles in a servlet?
164 Before isUserInRole() is called, the user needs to be authenticated. (if not authenticated, the container returns false)
165 The containter takes the isUserInRole() argument ("Manager"), and compares it to the roles defined for the user in this request.
166 If te user is mapperd to this role, the Container returns true.
167
168 Declarative side of programmatic security.
169 "making a fake name"
170 if (request.isUserInRole("Manager"))...
171
172 DD
173 <webapp...>
174 <servlet>
175 <security-role-ref>
176 <role-name>Manager</role-name>
177 <role-link>Admin</role-link>
178 </security-role-ref>
179 ...
180 </servlet>
181 ...
182
183 <security-role>
184 <role-name>Admin</role-name>
185 </security-role>
186 //In this case if the security-role-ref didn't exists, this would fail because there is no <security-role named "Manager"
187 //Fez o Link com o Manager que foi declarado programaticamente com o Admin que esta no DD
188 </webapp>
189
190 *The <security-role-ref> elements maps programmatic (hard-coded) role names to declarative <security-role> elements.
191 The container will usa <security-role-ref> mapping even IF the programmatic name matches a "real" <security-role> name.
192
193 *For J2EE container, authentication comes donw to this: ask for a username and password, then verify.
194 The firstime an un-authenticated user asks for a constrained resource, the Container will automatically start the authentication process.
195 There are four types of authentication and the main difference is "How securely is the name and password info transmited?"
196 1)Basic-> transmit the login informaticon in an encoded (not encrypted) form. Very weak, base64.
197 2)Digest-> More secure way, use encryption. J2EE Container arent required to support it
198 3)CLIENT-CERT-> Extremely secure form, using public key certificates. Our clients need to have a certificate Before they can login to our system.
199 //IN THE THREE TYPES ABOCE, all use the browsers standard pop-up form for inputting name/password.
200 4)FORM-> let us create our own custom login form out of anything thats legal HTML. Least secure, the login information is transmitted in the HTTP request with no encryption.
201
202 In our DD
203 <webapp...>
204 ...
205 <login-config>
206 <auth-method>BASIC</auth-method> //THE CONTAINER DO THE REST, AUTOMATICALLY REQUESTING A USERNAME AND PASSWORD WHEN CONSTRAINED RESOURCE IS REQUESTED
207 </login-config>
208
209 <login-config>
210 <auth-method>DIGEST</auth-method> //IF OUR CONTAINER SUPPORT DIGEST, IT WILL HANDLE ALL THE DETAILS
211 </login-config>
212
213 <login-config>
214 <auth-method>CLIENT-CERT</auth-method> //CLIENTS MUST HAVE CERTIFICATE, EXTRA-STRENGHT PROTECTION!!!!
215 </login-config>
216
217 <login-config>
218 <auth-method>FORM</auth-method>
219 <form-login-config>
220 <form-login-page>/loginPage.html</form-login-page>
221 <form-error-page>/loginError.html</form-error-page>
222 </form-login-config>
223 </login-config>
224 ...
225 </webapp>
226
227 *Form based authentication.
228 We need to create our custom login.html and our custom error.html
229 We need to turn on SSL or session tracking, or our Container might not recognize the login form when its returned.
230 Steps!
231 Declare <login-config> in the DD
232 Create our two html.
233 Three entries in the HTML login form are the key to communicating with the container:
234 j_security_check
235 j_username
236 j_password
237 <form method="POST" action="j_security_check">
238 <input type="text" name="j_username">
239 <input type="password" name="j_password">
240 <input type="submit" value="Enter">
241 </form>
242
243 //15575 tem um sumario das formas de autenticação.
244 Type SPEC Data Integrity Comments
245 Basic HTTP Base 64 - weak Http standar, all browsers support
246 Digest HTTP Stronger, but not SSL Optional for HTTP and J2EE containers
247 Form J2EE Very weak, no encryption Allows a custom login screen
248 Client-Cert J2EE Strong, public key Strong, but users must have certificates
249
250 Data integrity and Authentication-> when we are authenticating an user, shes sending you her username and password.
251 Data integrity and Confidentiality refers to the degree to wich an eavesdropper can steal or tamper with this information.
252 Data integrity means that the data that arrives is the same as the data that was sent. Mandei X chegou X
253 Confidentiality means that nobody else can see the data along the way.
254
255 J2EE protected transport layer connection (when we want to use FORM LOGIN with a better security.)
256 Securing data in transit: HTTPS to the rescue.
257 When we tell a J2EE container that we want to implement data Confidentiality and/or integrity, the j2EE guarantess that the data
258 to be transmitted will travel over a "protected transport layer connection", in other words HTTPS over SSL
259
260 *HttpRequest not secured
261 In the body of our post we can view our informations, like a credit card number and other things.
262 *Secured HTTPS over SSL request
263 If someone intercept the data, he cant read the information because a extra EXTRA-STRENGHT https over ssl.
264 VEM UM MONTE DE NUMERO LETRA JUNTO FOA-SE NIUNGUEM ENTENDE!
265
266 *How to implement data Confidentiality and integrity sparingly and declaratively
267 <web-app...>
268 ...
269 <security-constraint>
270
271 <web-resource-collection>
272 <web-resource-name>Recipes</web-resource-name>
273 <url-pattern>/Beer/UpdateRecipes/*</url-pattern> */
274 <http-method>POST</http-method>
275 </web-resource-collection>
276
277 <auth-constraint>
278 <role-name>Member</role-name>
279 </auth-constraint>
280
281 //The new declaration
282 <user-data-constraint>
283 <transport-guarantee>CONFIDENTIAL</transport-guarantee>
284 </user-data-constraint>
285
286 </security-constraint>
287 </web-app>
288 //ONLY MEMBERS CAN MAKE POST REQUEST TO RESOURCES FOUND IN UPDATERECIPES DIRECTORY
289 //AND MAKE SURE THE TRANSMISSION IS SECURE
290
291 NONE-> is the dafault value of <transport-guarantee>
292 INTEGRAL-> the data must not be changed along the way
293 CONFIDENTIAL-> the data must not be seen by anybody along the way
294
295 We can have only one <user-data-constraint> per <security-constraint>
296
297 Protecting the request data.
298 The <security-constraint> is about what happens after the request.
299 We want to protect the login data, what to do?
300 Steps of login
301 *Unauthorized client requests a constrained resource that has no transport guarantee. //15673
302 Client request /BuyStuff.jsp, wich as been configured in the DD with a <security-constraint> (Client must be authenticated)
303 Container send a 401 response, that tells the browser to get login information from the user.
304 The browser make the same request again, but this time with the users login information in the header.
305 THE CLIENT INFORMATION WAS NOT SENT SECURELY.
306 The container authenticates the client (check user and pass), then authorize the request.
307
308 *Unauthorized client request a constrained resource that has a Confidentiality transport guarantee.
309 Client request /BuyStuff.jsp, a constrained resource that implements a transport guarantee. The Container sees that
310 The request did not come in securely
311 Container send a 301 response to the client, that tells the browser to redirect the request using a secure transport.
312 The browser make the same resource request again, but this time, over a secure connection. Same resource over HTTPS
313 The container sees that the resource is constrained and that this user has not authenticated. So now the container starts the authentication process
314 by sending a 401
315 The browser makes the same request again (THIRD TIME), but this time the requests has the users login data in header and the request comes over
316 a secure connection.
317
318 *When a request comes in, the Container looks FIRST at the <transport-guarantee>, and if there IS one, the Container tries to deal with taht issue
319 first by asking, "Is this request over a secure connection?" If not, the Container doesnt even bother to look at authentication/authorization info.
320 Just tell the client "Come back wen youre secure, then we will talk"
321
322 To make sure the users login info is submitted to the server securely, put a transport guarantee on EVERY constrained resource that could trigger the login process.