Re: Welcome to the new JSR-375 mailing list
On 05/15/2017 07:18 AM, Arjan Tijms wrote:
I agree that the existing mechanisms aren't modern, and that there may be use cases where developers want or need to modify the process. That said, I think the legitimate use cases are probably few and far between. Existing implementations of FORM and BASIC have been refined over the years, such that they are robust and handle most reasonable requirements.
The example you provide above demonstrates the capability, but doesn't demonstrate the need -- in my view, intervening to check username/password length before actually validating the credentials is misguided on separation of duties grounds -- only the identity store can authoritatively say whether the credentials are valid or not -- and is potentially insecure. Best practice when validating credentials is to return "login failed" for all failure cases, regardless of the cause. Returning a different error for bad password vs. invalid user -- or for username/password too short -- reveals information that an attacker could use to break into a system. Timing differences between the two code paths could also reveal information helpful to an attacker.
I have not heard feedback from our customers that they need or want to extend the functionality provided by FORM or BASIC authentication in WebLogic.
Also -- is it not possible to reference a CDI bean, or perform validation on j_username/j_password in some other way, from a login form using the existing mechanism?
My proposal would be specify that the container should use an application-supplied IdentityStore for FORM/BASIC if present, but also that the container is permitted to override an application-provided IdentityStore with one of its own. i spent some time reading the CDI spec, and it appears to me that this would be possible by observing events during bean discovery and replacing the application's bean with a container bean when the appropriate event is fired -- I'm still not sure which event is the most appropriate one, though -- I'd be interested in your thoughts, as you clearly know CDI better than I.
Agreed, and I'm generally a fan of consistency. In this case, the question in my mind is whether consistency alone is a good enough reason to require containers to provide this functionality when it would impose an implementation cost on container vendors and there is no clear functional requirement driving it. Vendors could always choose to provide the functionality, or even re-implement their existing FORM/BASIC support as HAMs, if it were present in the RI.
Refactoring FORM/BASIC to expose it via CDI may or may not be a trivial exercise for any given container vendor. If significant refactoring is involved, vendors may choose to provide two implementations instead. The requirement to also support the custom form API might also be a factor.
Good to know. Does he existing RI implementation meet that requirement?
If a vendor chooses to provide two implementations of FORM/BASIC, that problem will still remain. Mandating functionality to drive testing seems like the tail wagging the dog; a focus on a robust TCK seems like a better approach.
I don't know these technologies well enough to have an informed opinion on whether h:outputText is duplicative of c:out, but it does seem that JSF is layered on JSP/JSTL in a way that, in my conception, JSR-375 is not layered on Servlet. Although JSR-375 and Servlet are different specs, they are tightly integrated, rather than one being simply layered on top of the other.
I still feel like RememberMe is not well-defined. If it's really a session management facility, then it's under-specified, it shouldn't be delegating to an IdentityStore, and there's no clear rationale for implementing a new session management capability in addition to what the container already provides. Existing container session management is almost certainly more robust and more secure than RememberMe. I would argue that long-lived sessions are a bad idea (as distinct from long-lived authentication tokens), but existing containers allow for configurable session lifetimes.
If it's really an authentication token service, then, again, it's underspecified. There are certainly use cases for long-lived tokens, but the specifics of the token matter. OAuth tokens are one example, and are well-specified in terms of token format and content, and the trust models that apply to various types of OAuth tokens and various use cases. Importantly, OAuth tokens use encryption and digital signatures to provide confidentiality, integrity, and trust in the issuer. None of that is specified here because no specific token type (or token protocol) is specified.
The best way to think about RememberMe is probably in terms of a generic mechanism for token issuance, and that seems to be the intent of RememberMeIdentityStore. But it's not fully "plumbed" -- since HAMs are supposed to interact only with IdentityStoreHandler, not IdentityStore, shouldn't IdentityStoreHandler expose generateLoginToken()? Also, the removeLoginToken() method is more consistent with a session model than a token issuance model -- issued tokens, especially long-lived ones, are typically not cached because there's no need to -- they can be cryptographically verified, and they contain all the information needed for user identification and authentication. Lastly, the RememberMe annotation provides very little configurability -- it only supports cookies (not, e.g., HTTP headers, or form fields), and even for cookies allows configuration only for cookie name and lifetime.
The FORM and BASIC annotations make sense to me -- I still have reservations about including them, but I understand the value proposition, and how they're intended to work. RememberMe doesn't seem sufficiently well thought out yet.
As noted above, that sounds more like a long-lived authentication token than a session. Having given it some more thought, I think RememberMe is not really session management or token-based authentication, it's token issuance, but I think it needs to be conceptualized as such, and more fully specified, before it's ready for inclusion in the spec.
I think a key conceptual difference between what happens in step 2 and what happens in step 3. Step two is the container identifying an authentication token and using it to authenticate the user. The function/behavior of step 3 depends on whether FORM is just an alternative authentication mechanism (because multiple acceptable mechanisms are available), or whether step 3 is really a redirect to a token issuance service. (Not necessarily a literal redirect, but a logical redirect.)
I think the answer is that one is a session cookie and the other is not (it's an authentication token). If the model is really token issuance, the fact that only cookies are supported seems like a bit limitation.
Agreed, but an application with both http and https resources has more complicated requirements, given that you don't want users to have to authenticate twice, and given that the servlet spec mandates that the same session be shared across all of an application's resources, both http and https. The presense of multiple session cookies, representing sessions with different lifetimes complicates the situation even more, and potentially presents opportunities for session stealing when login events occur or tokens are refreshed/re-issued.
Agree. I have a better understanding of the motivation for FORM and BASIC annotations/HAMs now. I think I understand RememberMe better as well, but I feel it still needs significant work before it's ready to be specified.
Yes -- thanks for the explanations. I still don't think RememberMe is ready to specify, but I'm more comfortable with the FORM and BASIC annotations. Do you think you could send me a brief write-up of those today?
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803