Jaspic: handle access to unprotected resource

Question

I'm studying JASPIC, I start a little project from scratch to explore it and how it behave on Wildfly. First step is to invoke my SAM validateRequest method and return content of an unprotected resource, the index.html page. Ok, validateRequest is invoked. I check if MessageInfo javax.security.auth.message.MessagePolicy.isMandatory property is set to false. Here comes the hard times. In my first try, if property is set to false validateRequest returns AUTH_SUCCESS value, but browser get back a 403 error. In my second try validateRequest returns null, browser get back a 200 but it there is no data in the response (nothing about index.html). What should I do to handle servlet requests correctly? You can find the source here. Thanks.

Answer 1

What should I do to handle servlet requests correctly?

Understand and adhere to the relevant sections of the specification. For the typical Servlet-oriented ServerAuthModule (SAM), those are:

• The generic overview of the server-side message processing model (point 2 is where validateRequest gets called), provided by § 1.2.5 and § 2.1.5.2. The later, as well as the model's state diagram on page 25 (page 39 in the PDF) are of particular importance.
• The HTTP Servlet Container Profile's specialization of the above, to be found in § 3.8.3.2, § 3.8.4 and § 3.9.

Of course, since you implement the factories as well, there are quite a few additional details of varying significance you should be aware of, thus it will be likely harder for you to get away with avoiding to read the first three chapters in their entirety.

Returning SUCCESS from validateRequest

Whenever the validateRequest implementation of your SAM is to return AuthStatus.SUCCESS (null is not an option), it must communicate the caller's identity to the (Servlet) runtime prior to returning, regardless of the caller actually having been authenticated or being anonymous. That can be accomplished by handling a CallerPrincipalCallback, and/or at least a single GroupPrincipalCallback (it is possible to assign groups to the anonymous caller), via the runtime-provided CallbackHandler. Constructing either of those callbacks with a null Principal (name) argument signals to the runtime that the caller is to be considered anonymous, or that no groups are to be associated with it, respectively. Again, note that no default assumption of the caller being anonymous is made by a compliant runtime; it must be told explicitly, otherwise the outcome is undefined.

The semantics of SUCCESS is that the request shall be allowed to propagate to the (Servlet-based) service endpoint, iff group-(role-)based caller authorization succeeds. For authorization to take place, however, the runtime must be made aware of the caller's identity, which is why the aforementioned callbacks are necessary.

AuthStatus values vs HTTP Response Status Codes

The relationship between the two can be a tad confusing. The former are protocol-neutral and essentially state transition labels in the message processing model. In theory they constrain the later; in practice, since multiple components and the application server itself may alter the response's status, it is advisable that you assign it yourself in non-AuthStatus.SUCCESS/AuthStatus.SEND_SUCCESS validateRequest/secureResponse return cases.