Re: Welcome to the new JSR-375 mailing list


Will Hopkins
 

Arjan, et al.:

On 05/12/2017 07:44 PM, Arjan Tijms wrote:

On Fri, May 12, 2017 at 11:46 PM, Will Hopkins <will.hopkins@...> wrote:
 
The form, custom form, and basic authentication mechanisms are part of what I think belongs in the RI. The servlet spec already requires support for form, custom form, basic, etc. -- these seem to me to be implementations of specific authentication mechanisms, not part of an API. Not only that, but containers already have to implement those mechanisms, so it's not clear what the value is in forcing a different implementation of the same feature.

The custom form specifically is not available in the Servlet spec, and that one is an important addition which aligns the form approach with platform services and APIs such as bean validation, CDI, and JSF, and modern programming techniques.

Can you explain more about that? What does Custom Form do that's not already available (apart from leveraging IdentityStore), and what benefits does the alignment bring for apps?

The regular form and basic authentication mechanisms are present not only for consistency reasons, but also make it both trivial and guaranteed to use the JSR 375 identity store with them, which wouldn't hold for the existing Servlet authentication mechanisms.

Support for IdentityStores could be achieved more simply and directly (from a container implementer's POV), by simply mandating that FORM and BASIC auth methods (perhaps CERT as well) use application-provided IdentityStores when present.

Maybe even more important, JSR 375 authentication mechanisms are fully CDI beans, which brings with them all the CDI features such as decorators, interceptors, alternatives and CDI extensions that can work with them.

I do see value in that, although I'm not sure how often decorators or interceptors would be needed for BASIC or FORM, in particular, and it would always be possible for an app developer to write the appropriate HAM -- or leverage an RI implementation. The calculus would be different if we had more time, but it doesn't seem essential (to me) that they be specified as part of the API.

It also gives a practical advantage of exercising the same code paths as user's custom authentication mechanisms would exercise. By using the Servlet ones, those paths would be partially different.

Any given app is likely to have one or the other, not both, and custom schemes are, by definition, custom.

I'm fine with keeping these in the RI, but the API should be reserved for general-purpose APIs, rather than implementation details of for specific mechanisms. The real value of HttpAuthenticationMechanism is to allow applications to provide their own authentication mechanisms.

That too, but several default implementations are important just as well. JASPIC already allows applications to provide their own authentication mechanisms, but it's often seen as too abstract and not a complete solution.

The point of HAM is that it eliminates the most of the complexity, overcoming that barrier. BASIC auth is BASIC auth, regardless of where/how implemented, as long as it works. The value of something like HAM is to allow application developers to provide an auth mechanism when the standard mechanisms aren't sufficient.

If you compare this to e.g. JSF, you see that it defines the UIComponent interface for custom components, but also provides a small number of default components that all use that interface.

The servlet container already provides default implementations of FORM and BASIC, just not ones that leverage HAM. Does JSF provide multiple implementations of each default UIComponent?

How both the provided HttpAuthenticationMechanisms and in JSF the provided UIComponents are implemented is an implementation detail. We were quite careful in making sure the actual bean type does not leak and that implementation details do not appear in the API.

To that end, the specific RememberMe usage for the implementation of the two form mechanisms is indeed an implementation detail, but moving it does mean an amount of work for the RI has to be done, which does take some time and re-testing for code that has already been tested in practice for well over a year.

Since there's no real problem with RememberMe, it just seems a bit wasteful to take this work upon us now, and we can better spend the little time that we have elsewhere IMHO.

I have some architectural concerns about the general approach of implementing HAMs for BASIC and FORM auth, and with RememberMe in particular.

It's possible that I don't fully understand the intent of RememberMe, but it looks to me like what it's really doing is session management, not authentication. The RememberMeIdentityStore isn't really an identity store at all, it's a cache of authenticated users. If we really wanted to specify session management, we could do so, but the servlet spec already says how servlet containers should do session management. Shouldn't we integrate with that existing capability, rather than building a redundant, and less capable, feature on top of the existing feature? Do we really want two session cookies rather than one? Have we specified it fully enough? How does RememberMe ensure that the cookies it issues are protected against session stealing attacks? Do we require that the cookie is marked secure? If so, how does it work if an authenticated user makes a request over a non-SSL connection? Existing servlet containers have worked through these kinds of issues over many years, and are generally pretty robust at this point; we should leverage their existing capabilities.

Similarly the FORM and BASIC implementations, if left in the API, should be required to integrate with container session management, so that behavior is uniform for apps that use HAM and apps that don't. Authentication is authentication; session management is different, and mostly (though not entirely) orthogonal.

In part where I'm coming from is that I see a difference between a framework that's mean to run in a wide variety of platforms, some of which may be Java EE containers, and some of which may not, and a JSR, which is explicitly meant to be *part* of the Java EE platform, and fully integrated with it -- not merely layered on top. I think we should be specifying where JSR-375 needs to integrate with the servlet container, not how it can duplicate or re-implement existing functionality.

Those are my initial thoughts, anyway. I do see the benefits of the fact that HAMs are CDI beans, but, at a minimum, I think there's complexity here, and some questions that need to be resolved, and little or no time to do so. That's probably my fault, but we are where we are.

Thoughts?

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.