Authenticated-only elements not being obtained by registered user about rdap-server

[dhfelix]

Apparently, if a request with an authorization header makes a request to a servlet that does not have security constraint configured, the authorization header is discarded, so the servlet can't read a username (because is always "null") and only brings "public" information.

Typically, stock HTTP authentication operates in an all-or-nothing model:

1. Client requests resource anonymously.
2. Server answers “401 - Unauthorized”.
3. Client repeats the request, including credentials in a header field named “Authorization”.
4. Server validates credentials and returns the resource on success.
   (Technically, users can provide credentials prematurely if they foresee the 401 and want to skip the first and second steps, but the above is more practical.)

As a result, protected objects are completely concealed until clients have identified themselves. Even if the servlet knows that some information should be made public, HTTP bans any access lacking Authorization. If you want to support “optional” authentication (allowing partial objects to be accesed by anonymous users), you often need to work around the model.

One way to do it is by providing “default” authentication to anonymous users. In other words, you register a dummy, “anonymous” user in your servlet container, and you append a corresponding Auhorization header to every request lacking one before it reaches the server. The servlet then takes care of returning only “public” information to this user, and reveal other information normally to others.

[ydahhrk]

@dhfelix

You're mostly talking about anonymous users trying to access partially-public information.

OblivionWielder is having trouble getting private information even though he's logged in. (And, presumably, security constraints are in place.)

[dhfelix]

​
@ydahhrk you are right, I did not finish my answer and do not check it before sending it.

Apparently, if a request with an authorization header makes a request to a servlet that does not have security constraint configured (in web.xml), the authorization header is discarded, so the servlet can't read a username (because is always "null") and thats why only brings "public" information.

So we need to add security constraint to all our servlets, this way we make sure that the authentication header is not discarded, but adding security constraint to the servlets creates another issue, it will now be necessary to provide a user and password when doing the request to a page that could be visited anonymously.

A workaround to the second problem will be to generate a role that indicates that a user is anonymous or not authenticated, also create a user that will be linked to that anonymous or 'not authenticated' role. e.g. create a user with empty string in the username and password fields, so when the user is asked to insert the credentials, he may leave the fields empty and will be able to get the requested object that contains only public information.

In conclusion, a servlet with no security restrictions, can only display information cataloged as public, and a servlet with security should always contain the authentication header which will prevent the page can be visited anonymously, which it may be solved with the comments in the preceding paragraph.

Here is an example of web.xml with what I mentioned.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://xmlns.jcp.org/xml/ns/javaee"
	xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
	id="WebApp_ID" version="3.1">

	<display-name>rdap-server</display-name>

	<error-page>
		<location>/exception</location>
	</error-page>

	<security-constraint>
		<web-resource-collection>
			<web-resource-name>Search pages</web-resource-name>
			<description>Links that can't be visited anonymously</description>
			<url-pattern>/nameservers</url-pattern>
			<url-pattern>/domains</url-pattern>
			<url-pattern>/entities</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>AUTHENTICATED</role-name>
		</auth-constraint>
	</security-constraint>

	<security-constraint>
		<web-resource-collection>
			<web-resource-name>query pages</web-resource-name>
			<description>Pages that can be visited anonymously leaving the user field and 
			password empty, as long as the corresponding user has been previously generated 
			in the database and the anonymous role is linked.</description>
			<url-pattern>/nameserver/*</url-pattern>
			<url-pattern>/domain/*</url-pattern>
			<url-pattern>/entity/*</url-pattern>
			<url-pattern>/ip/*</url-pattern>
			<url-pattern>/autnum/*</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>AUTHENTICATED</role-name>
			<role-name>ANONYMOUS</role-name>
		</auth-constraint>
	</security-constraint>

	<security-role>
		<role-name>AUTHENTICATED</role-name>
	</security-role>

	<security-role>
		<role-name>ANONYMOUS</role-name>
	</security-role>

	<login-config>
		<auth-method>BASIC</auth-method>
	</login-config>

</web-app>

[dhfelix]

I discovered that now that the user name (authentication header) can already be read by the servlet, the "dummy" or "anonymous" user is treated as a "registered/authenticated" user, therefore, a variable (anonymous_username) was generated in the configuration properties file to indicate which username is treated as anonymous, and thus filter and treat as "unregistered/not authenticated" that anonymous user.