Hi,
On Tue, Nov 15, 2016 at 9:44 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> 1) When there are no (Authenticating) IdentityStores defined (No
> IdentityStore with ValidationType.BOTH or ValidationType.AUTHENTICATION)
> what should be done in that situation?
>
> When the system has no way of validating the credentials, this is clearly
> an error I guess. Probably the best thing is that during the deployment
> (CDI Extension AfterBeanDiscovery method execution) of the application an
> error is thrown. Or should we log only a warning?
>
It's a good question, thanks, but not super easy to answer I think.
The authentication mechanism would not be obliged to delegate to a handler
(and thus identity store). I think it was Darran who explained here that in
some cases an authentication mechanism is so tightly coupled to identity
validation/retrieval that the mechanism must be allowed to do this by
itself.
And even if the authentication mechanism does delegate to the handler, then
a custom handler (or alternative or decorator) could choose not to
delegate. So a deployment error is quite hard to generate here.
For the moment I implemented in Soteria that during the execution of the
> IdentityStoreHandler, CredentialValidationResult.INVALID_RESULT is
> returned. (Fixing the NullpointerException in this situation)
>
For the moment that sounds indeed like the best solution.
> 2) When there is no HttpAuthenticationMechanism available (by means of a
> 'CDI definition annotation' or by implementing the interface), I guess we
> can carry on as usual. Because the developer can always start
> authentication by calling the SecurityContext methods.
>
IIf there's no HttpAuthenticationMechanism available, then by default the
Servlet native mechanism defined in web.xml will become active, and if
there's none the container's default will usually be activated (I have to
double check if it's not the Servlet spec that mandates a default to BASIC
if nothing is declared in web.xml).
So if there's no HttpAuthenticationMechanism available, then using the
SecurityContext methods will causes the native Servlet mechanism to be
triggered.
What we also may like to have is an equivalent to HttpServletRequest#login
that goes directly to the identity store (i.e. logs a user in right away
without going through any mechanism). Because of the method signature of
HttpServletRequest#login and the way the Java EE specs are currently
defined this is not entirely easy :( (I had a conversation about this with
Alex last year)
> Probably this needs also to be mentioned in the spec docs.
>
Absolutely!
I feel it's this kind of nitty gritty that's most important to get right.
Higher level big features such as OAuth would really be nice, but these
kinds of very basic details is what we need to get right first are foremost
IMHO.
Kind regards,
Arjan Tijms
>
> Best regards
> Rudy
>
> --
> You received this message because you are subscribed to the Google Groups
> "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsr375-experts+unsubscribe_at_googlegroups.com.
> To post to this group, send email to jsr375-experts_at_googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jsr375-experts/CAL%2Bwt-6Li%3DVaLLRu_PsM_a442GM7j8Fs-
> W4qbo1rj0izUT5SeQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-6Li%3DVaLLRu_PsM_a442GM7j8Fs-W4qbo1rj0izUT5SeQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>