[
https://issues.apache.org/jira/browse/TOMEE-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629650#comment-17629650
]
Stefan Kalscheuer commented on TOMEE-4065:
------------------------------------------
I had a short look at the specs. Apparently there is really not much of obvious
reading about the actual usage.
[Security 2.0 spec,
§2.4.4|https://jakarta.ee/specifications/security/2.0/jakarta-security-spec-2.0.html#logintocontinue-annotation]
says (underlined emphasis by myself):
{quote}The annotation is also used to configure the login page [...] for the
b{+}uilt-in form-based authentication mechanisms{+} (implicitly suggesting, but
not requiring, that those authentication mechanisms use the backing interceptor
for this annotation, which is described below).
[...]
The container MUST provide an interceptor implementation [...] that backs the
_LoginToContinue_ annotation and intercepts calls to the {+}configured
_HttpAuthenticationMechanism_{+}.
{quote}
One might interpret the "built-in" as one of {{@Form-}} or
{{@CustomFormAuthenticationMechanismDefinition}}, as both declare form-based
aiuthentication mechanisms.
The latter though does not specify anything about the auth mechanism.
Quoting the
[JavaDocs|https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/authentication/mechanism/http/LoginToContinue.html]:
{quote}When the {{LoginToContinue}} annotation is used on a custom
authentication mechanism, EL expressions in attributes of type String are
evaluated for every request requiring authentication. Both immediate and
deferred syntax is supported, but effectively the semantics are always deferred.
When the {{LoginToContinue}} annotation is used as attribute in either the
{{FormAuthenticationMechanismDefinition}} or
{{{}CustomFormAuthenticationMechanismDefinition{}}}, expressions using
immediate syntax are evaluated only once when the
{{HttpAuthenticationMechanism}} bean is created. [...]
{quote}
they state a difference between annotated mechanisms and custom
implementations, so I would assume there are other valid ways to use it.
Okay, so in this case the _tomee-security_ implementation picks up the custom
mechanism and intercepts the call when trying to redirect. From the given
annotations it cannot tell whether the actual mechanism is form-based or not.
It's definitely not build-in. So from the very first spec quote we might assume
it's simply not within the "must" criteria.
I had a working EE8 application using _Soteria_ to partially re-implement on
top of a TomEE 9 platform. Did not verify it being supported in current
releases.
If that's just a slightly out-of-spec feature, I'm totally fine with it being
unsupported. (actually using a different way of redirection in the specific
application where I encountered the issue)
> LoginToContinue interceptor fails on custom auth mechanism
> ----------------------------------------------------------
>
> Key: TOMEE-4065
> URL: https://issues.apache.org/jira/browse/TOMEE-4065
> Project: TomEE
> Issue Type: Bug
> Affects Versions: 9.0.0-M8, 9.0.0.RC1
> Reporter: Stefan Kalscheuer
> Priority: Major
>
> I stumbled across an issue using a custom _HttpAuthenticationMechanism_
> implementation using the _@LoginToContinue_ annotation directly.
> *Minimal example code:*
> {code:java}
> @ApplicationScoped
> @AutoApplySession
> @LoginToContinue
> public class AuthMechanism implements HttpAuthenticationMechanism {
> @Override
> public AuthenticationStatus validateRequest(HttpServletRequest request,
> HttpServletResponse response,
> HttpMessageContext
> httpMessageContext) throws AuthenticationException {
> /* do auth stuff */
> }
> } {code}
>
> *Expected behavior*
> I would expect the application server to redirect any request to a protected
> URL to the login page (without additional specification this would be
> "/login" here).
>
> *Observable behavior*
> Apparently this raises an error 500:
> {quote}java.lang.IllegalArgumentException
> org.apache.tomee.security.cdi.LoginToContinueInterceptor.getLoginToContinue(LoginToContinueInterceptor.java:221)
>
> org.apache.tomee.security.cdi.LoginToContinueInterceptor.processContainerInitiatedAuthentication(LoginToContinueInterceptor.java:134)
>
> org.apache.tomee.security.cdi.LoginToContinueInterceptor.validateRequest(LoginToContinueInterceptor.java:78)
>
> org.apache.tomee.security.cdi.LoginToContinueInterceptor.intercept(LoginToContinueInterceptor.java:63)
> ...
> {quote}
>
> The interceptor checks whether the invocation target implements
> _LoginToContinueMechanism_ and calls {_}getLoginToContinue(){_}. Because we
> do have a custom implementation here, this does not apply and raises an
> exception.
>
> *Possible solution*
> My workaround is a minor extension of the interceptor, i.e. add a fallback to
> a class-level annotation of the target.
> {code:java}
> private LoginToContinue getLoginToContinue(final InvocationContext
> invocationContext) {
> if (invocationContext.getTarget() instanceof LoginToContinueMechanism) {
> return ((LoginToContinueMechanism)
> invocationContext.getTarget()).getLoginToContinue();
> }
> // WORKAROUND START
> LoginToContinue annotation =
> invocationContext.getTarget().getClass().getAnnotation(LoginToContinue.class);
> if (annotation != null) {
> return annotation;
> }
> // WORKAROUND END
> throw new IllegalArgumentException();
> }
> {code}
>
> *RFC*
> Did I miss or misinterpret anything here or should the behavior of the
> interceptor be extended, e.g. with the lines proposed above?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
