Remember that in the DD, the <security-constraint> is about what happens after the request. In other words, the client has already made the request when the Container starts looking at the <security-constraint> elements to decide how to respond. The request data has already been sent over the wire. How can you possibly remind the browser that, “Oh, by the way... if the user happens to request this resource, switch to secure sockets (SSL) before sending the request.”
What can you do?
You already know how to force the client to get a login screen—by defining a constrained resource in the DD, the Container will automatically trigger the authentication process when an unauthenticated user makes the request.
So now we have to figure out how to protect the data coming in from a request... even (and sometimes especially) when the client has not yet logged in.
We might want to protect their login data!
Turn the page to see how it all works...
Unauthorized client requests a constrained resource that has NO transport guarantee
Client requests /BuyStuff.jsp, which has been configured in the DD with a <security-constraint>.
The Container checks the <security-constraint> and finds that /BuyStuff is a constrained resource... which means the user MUST be authenticated.The Container finds that there is NO transport-guarantee for this request.
The Container sends a 401 response to the client, that tells the browser to get login information from the user.
The browser makes the same request again, but this time with the user’s login information in the header.
The Container authenticates the client (checks that username and password match the user data configured in the server). Then the Container authorizes the request to make sure that this user is in a role that’s allowed to get the constrained resource. Everything checks out, so the response is sent.
Unauthorized client requests a constrained resource that has a CONFIDENTIALITY transport guarantee
Client requests /BuyStuff.jsp, a constrained resource that also has a transport guarantee.
The Container sees that this constrained resource has a transport guarantee. The Container sees that the request did NOT come in securely...
The Container sends a 301 response to the client, that tells the browser to redirect the request using a secure transport.
The browser makes the same resource request again, but this time, over a secure connection. In other words, the resource stays the same, but the protocol is now HTTPS.
Now the Container sees that the resource is constrained, and that this user has not authenticated. So now the Container starts the authentication process by sending a “401” to the browser...
The browser makes the same request again, (yes, for the THIRD time) but this time the request has the user’s login data in the header AND the request comes over using a secure connection. So this time the client’s login data is transmitted securely!
Note
To make sure the user’s login info is submitted to the server securely, put a transport guarantee on EVERY constrained resource that could trigger the login process!
Remember, when you’re using declarative authentication, the client never makes a direct request for the login. The client triggers the login/authentication process by requesting a constrained resource. So, if you want to make sure that your client’s login data comes back to the server over a secure connection, you need to put a <transport-guarantee> on EVERY constrained resource that could trigger the login form on the client!
That way, the Container will get the request for the constrained resource, but BEFORE telling the browser to get the client’s login data, the Container tells the browser, “You’re not supposed to even MAKE this request until you’re using a secure connection.” Then when the client comes back the second time, the Container THEN says, “Oh, I see you’re on a secure connection, but I still need authentication data from the user.” The browser puts up the login form for the user, gets the user’s info, and sends back this THIRD request over a secure connection.
Sharpen your pencil
Configure the security aspects of a web application by filling in the three blocks in the DD. The web application must have the following behavior:
You want anyone to be able to do a GET on the resources within the Beer/UpdateRecipes directory (including any subdirectories), but you want ONLY those with the security role of “Admin” to be able to do a POST on resources within that directory. Also, you want the data to be protected so that nobody can eavesdrop.
Sharpen your pencil
Answers
You want everyone to be able to do a GET on the resources within the Beer/UpdateRecipes directory (including any subdirectories), but you want ONLY those with the security role of “Admin” to be able to do a POST on resources within that directory. Also, you want the data to be protected so that nobody can eavesdrop.
Sharpen your pencil
Answers
Security goal | What you’d put in the DD |
|---|---|
You want the Container to do BASIC authentication automatically. | <web-app...>
...
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app> |
You want to use your own custom form page, named “loginPage.html” (and deployed directly at the root of the web app), and you want “loginError.html” to be displayed if the client cannot be authenticated. | <web-app...>
...
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/loginPage.html</form-login-page>
<form-error-page>/loginError.html</form-error-page>
</form-login-config>
</login-config>
</web-app> |
You want to constrain everything with a “.do” extension so that all clients can do a GET, but only Members can do a POST. | |
You want to constrain everything within the foo/bar directory so that only those with a security role of Admin can invoke any HTTP methods on those resources. |
