Re: Welcome to the new JSR-375 mailing list
Arjan, et al.:
On 05/12/2017 07:44 PM, Arjan Tijms wrote:
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?
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.
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.
Any given app is likely to have one or the other, not both, and custom schemes are, by definition, custom.
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.
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?
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.
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803