What does it mean that MicroProfile 1.2 does not depend on Servlets?

[sst...@redhat.com]

While there is no need for a manifest use of the traditional servlet APIs as used in servlet classes and filters, we are implicitly relying on WARs as the portable deployment unit in test cases and examples. As JWT is a security related spec, you cannot get very far with JAX-RS, and one immediate example is the authentication mechanism required in a MicroProfile deployment. The next step up is a requirement on a transport security guarantee. Neither of these can be defined by metadata that exist in JAX-RS.

This is metadata that exists in the web.xml and corresponding security annotations. I don't see a reason to not use these metadata as a portable means to describe requirements of a JAX-RS based deployment.

[John D. Ament]

I have no issue support annotations from javax.annotation package, they can be used pretty easily.  I think that even comes in transiently from CDI dependency.

However, I have a pretty broad issue with support WARs.  Specifically, I don't support WAR files.  I use a "hack" in the Arquillian containers for OWB and Weld to get tests to pass (and just had to fix something with service loaders, as mentioned in another thread).  I've brought up before that MP doesn't really state anything about packaging requirements, and it would be an issue to suddenly require WAR packaging support at runtime.

[Heiko Rupp]

As far as I understand, Servlet spec is no part of MP yet, so making a spec depend on Servlets seems to be a bad idea. JAX-RS also apparently seem not depend on Servlets (even if most implementations use them).

[Werner Keil]

If that was an optional dependency for a particular feature, why not. 

There won't be a "One-Size-fits-All" approach, otherwise "Micro" becomes "Big" and Bloated very soon.

E.g. if Health, Monitoring or Failsafe each needed to be used without the other or without Configuration (should the implementating vendor use another framework like Dropwizard, Archaius, etc.) then they should not be forced to use or implement all the other stuff just to be "100% Microprofile compatible".

More importantly, one service will probably need Health+Config, another one Failsafe+Health, the next one maybe all three, etc.

So not only Servlet if it really benefits one of the implementations/features a lot should be optional, most APIs also have to be.

Werner

[sst...@redhat.com]

I'm not talking about the entire specification at this point, just a common deployment vehicle that TCKs use to convey the requirements of an application to the container being tested. I cannot see having to create a MicroProfile specific deployment construct when a web archive(war) is just a standardized zip file with any number of open source implementations capable of parsing it's metadata.

[sst...@redhat.com]

That is a different discussion than what I'm driving at in this thread. That is a discussion of level of certification to the suite of MicroProfile APIs. Here I am talking about a need to package a self describing deployment that is consistently used by all MP TCKs. I cannot see a good argument for this not being a WAR just because we don't want to pull in all of the servlet spec dependencies. All that is required is a set of annotations and web.xml parsing.

Given the Arquillian WebArchive abstraction, the support burden on non-servlet based containers is pretty low.

[sst...@redhat.com]

A hack at the test suite layer is all that is required at this point. However, there is no annotation analog to the login-config section of the web.xml descriptor, and this is the only mechanism for conveying the authentication and security realm of web application. If we have to add an Arquillian extension to parse and make this information available, fine, but I'm not in favor of having to create MP specific deployment artifacts when this effort is supposed to be an evolution of Java EE. 

[John D. Ament]

Or we introduce a new annotation that means the same thing.  But at the same time, I'm not sure that adding something to web.xml as a security constraint is the right thing.  Usually login configs do things like redirect or that old school prompt window w/ username/password.  

[sst...@redhat.com]

We can't add anything to web.xml so I'm not sure what you mean by that. Since there is no existing Java EE @LoginConfig annotation, I'm fine with adding it. So, that should require a separate microprofile-annotations project to start collecting the reusable annotations we create as a @LoginConfig annotation is a general security notion, not specific to JWT.

Right, the auth-method has a well defined request/challenge response protocol with associated headers, which if MP-JWT is used as, needs to fit in correctly with.

[Guillermo González de Agüero]

I think JSR375 should be able to cover the equivalent of the @LoginConfig [1], not the security-contraints though at the moment.


Regards,

Guillermo González de Agüero

[1] https://javaee.github.io/security-spec/spec/jsr375-spec.html#_annotations_and_built_in_httpauthenticationmechanism_beans

[sst...@redhat.com]

I'm not seeing that from what you referenced. It looks like that is just a facility to map the form used with FORM authentication to a backing bean. We might be able to leverage the HttpAuthenticationMechanism interface and provide a marker MPJWTHttpAuthenticationMechanism sub interface or some such. 

[Guillermo González de Agüero]

Hi,

There are a few common mechanisms, all based on the basic HTTP authentication or in the said form. That's the equilavent to the web.xml login-form (with the absence of the certificate login method).

But they are just facilities to enable a HttpAuthenticationMechanism. You can just create your own CDI bean implementing the HttpAuthenticationMechanism and do your custom authentication there e.g. reading the JWT data.

Take a look at this example test: https://github.com/javaee/security-soteria/blob/master/test/app-custom/src/main/java/org/glassfish/soteria/test/TestAuthenticationMechanism.java

Regards,

Guillermo González de Agüero

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/GdeqU3perxQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6b44af9c-f87e-4047-9e36-af6c69754041%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.