On 11/16/2016 05:56 PM, arjan tijms wrote:
> Hi,
>
> On Tue, Nov 15, 2016 at 9:44 PM, Rudy De Busscher
> <rdebusscher_at_gmail.com <mailto: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.
I agree. I don't yet understand the proposed mechanisms as well as you
all, but it sounds like there is no requirement for an IdentityStore to
be configured and/or used, so that shouldn't cause a deployment
failure. A warning of some sort would be useful for diagnosing
authentication failures, though.
>
>
> 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!
Yes.
>
> 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.
I agree. I asked about OAuth because I was asked to find out how the EG
feels about it, but getting the foundation right is definitely more
important.
>
> 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
> <mailto:jsr375-experts+unsubscribe_at_googlegroups.com>.
> To post to this group, send email to
> jsr375-experts_at_googlegroups.com
> <mailto: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
> <https://groups.google.com/d/optout>.
>
>
--
Will Hopkins | Platform Security Architect | +1.781.442.0310
Oracle Cloud Application Foundation
35 Network Drive, Burlington, MA 01803