Re: Welcome to the new JSR-375 mailing list
On 05/16/2017 08:19 AM, Arjan Tijms wrote:
OK, good point.
Yes, but there's a difference between the form complaining because you didn't enter *anything*, and complaining about specific issues with with the values a user *did* enter.
I've been thinking in terms of adding new APIs while not necessarily fixing things that aren't broken, but I understand the POV.
OK, yhat seems like a good approach, I'll make sure it's spec'd that way. I don't think I'll spec the idea about requiring the container to use an app-supplied IdentityStore -- you've convinced me about the FORM and BASIC annotations, so that's how the app can leverage an IdentityStore for FORM and BASIC.
How do you feel about specifing that HAMs are only required to be enabled when the app is deployed with <auth-method>AUTHMECH</auth-method>, though, to ensure that containers can continue support legacy apps using the existing code paths, and to ensure deterministic behavior when, for example, two implementations of FORM or BASIC are still present in the container. Containers could still choose to provide just one impl, and to implement all functionality via HAM, and apps could ensure they always got HAM by specifying the AUTHMECH, but legacy behavior got be safely preserved if a container vendor chose.
Yep. I see the value. I do think this will add significant additional implementation work for containers, though.
True. Hopefully, if the spec is well written and faithfully translated into test cases we can keep issues to a minimum.
So the light-bulb went off a little while ago. I had been thinking in terms of bank-level security, general-purpose architecture for token issuance, integration with container session management,etc. -- then I remembered that my bank won't let me stay logged in longer than 20 minutes, but lots of other sites have little "Remember Me" checkboxes, and I understood the use case. It's really not a distinct architectural function, it's more like a feature added onto authentication, so the current implementation makes sense. Sorry for being so dense about it.
Agree it's an implementation detail, but if what you mean is that the client should store only a hash, that doesn't provide any additional security, because the hash will be as good as the "original" token -- it must be possible to use the hash as the authentication token, because that's all the client will have access to. If it's just an identifier, then any unique, random value of sufficient size will do. Hashing algorithms can provide those, but don't really add much value over a good PRNG. If the token carries data, it will have to be encrypted, and the client will have to retain the actual token, not just a hash of it.
Let's not add anything else new. ;)
Yep, I just didn't get the use case right away.
I guess I see them all as functionally distinct now. The first analogy that comes to mind is the hierarchy of storage for a CPU -- the CPU operates on data in registers; data is loaded into registers from the L2 cache, when there's an L2 cache miss the data is loaded from core memory, and data that's not in core memory is read from disk. The fallback process from HTTP session to RememberMe to credentials-based authentication seems analagous.
Thanks, saw your recent pull request. I don't think every aspect has to be fully documented in the spec -- javadoc is fine as a detail-level reference -- but I do think the spec needs to at least mention the existence of every significant feature, and probably provide some high level discussion of the feature's purpose and function.
So, on to the next topic -- there are a couple other interfaces I think need to be moved, removed, and/or tweaked:
I agree with the concern, and intend to remove it from the spec (i.e., API javadoc).
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803