[undertow-dev] "unauthenticatedIndentity" in Undertow
Wolfgang Knauf
wolfgang.knauf at gmx.de
Wed Aug 13 16:01:55 EDT 2014
Hi Arjan,
thanks for the explanations. But I think I won't continue digging deeper
in the "unauthenticatedIdentity" area ;-). Seems this is something that
is not worth to know about ;-)
Best regards
Wolfgang
-------- Original-Nachricht --------
Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow
Von: arjan tijms <arjan.tijms at gmail.com>
An: Wolfgang Knauf <wolfgang.knauf at gmx.de>
Kopie (CC): "undertow-dev at lists.jboss.org" <undertow-dev at lists.jboss.org>
Datum: 12.08.2014 12:28
> On Sunday, August 10, 2014, Wolfgang Knauf wrote:
>
> I think my
> basic question should be "what is the unauthenticatedIdentity used
> for?"
>
>
> Afaik the unauthenticated identity that's exposed to user code is a very
> unfortunate result of the fact that whoever wrote the first EJB spec
> thought it was a good idea to add the requirement "never null" to the
> return value of EJBContext#getCallerPrincipal.
>
> I'm sure it was done with the best intentions, but without also defining
> a constant that we can use to compare to (ie via a reference) OR an
> explicit "isCallerAuthenticated" method, this has been nothing but a
> world of hurt.
>
> The problem is that now there's no real good way to check if a user is
> authenticated in EJB. A null return would be a good method, but since
> that value is mysteriously not allowed the container has to use a
> regular principal. You should then compare the name of this principal to
> whatever the container has decided to use to determine if the user is
> authenticated or not.
>
> This is a recipe for disaster, since without reserving a name, any name
> the container chooses could be a valid name in the application domain.
> It just can't work this way.
>
> As a workaround some containers like JBoss offer the option to remap the
> name to something, should it clash.
>
> . If this question is answered, the next question could be "how
> could one use it in a web app or application client?"
>
>
> See above, to test if the user is authenticated or not.
>
> I tried to call HttpServletRequest.authenticate() in an unsecured JSP
> page, and this redirected me to my login form - so no help ;-).
>
>
> This is because the SAM or login module that you configured wasn't
> instructed to "do nothing" ;)
>
> But my mentioning of request#authenticate was just an explanation of how
> a SAM could "do nothing" even after an explicit request for
> authentication. A SAM is a special case here since it's always called
> for every request (just like a Servlet Filter). If I'm not mistaken,
> JBoss' proprietary login modules are only called when authentication is
> explicitly required.
>
> Kind regards,
> Arjan
>
>
> Best regards
>
> Wolfgang
>
> -------- Original-Nachricht --------
> Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow
> Von: arjan tijms <arjan.tijms at gmail.com <javascript:;>>
> An: Wolfgang Knauf <wolfgang.knauf at gmx.de <javascript:;>>
> Kopie (CC): "undertow-dev at lists.jboss.org <javascript:;>"
> <undertow-dev at lists.jboss.org <javascript:;>>
> Datum: 09.08.2014 14:33
>
> > Hi,
> >
> > Although it's not directly what you asked, one thing which you
> may want
> > to take into account is that in the web layer (via
> HttpServletRequest)
> > the user/caller principal corresponding to the unauthenticated
> identity
> > is always null. When using the EJBContext that same user/caller
> > principal is something container specific (although contrary to
> the web
> > layer never null).
> >
> > EJB is underspecified here (just as the run-as principal).
> Likewise, the
> > way in which a security context established in the web layer
> propagates
> > to EJB is not clear either. There's a vague paragraph about a
> security
> > domain that should be consulted, which JBoss takes very literally
> (for
> > secured beans it attempts to re-authenticate instead of
> propagating the
> > established context), for non-secured beans it doesn't do this.
> >
> > Finally there are a couple of implementation differences between
> JBoss'
> > native login modules and the Java EE standard JASPIC ones. For JASPIC
> > you would call HttpServletRequest.authenticate() and the "login
> module"
> > (SAM) would pass a null to the CallerPrincipalCallback in order to
> > establish the unauthenticated identity.
> >
> > Hope this somehow helps.
> >
> > On Friday, August 8, 2014, Wolfgang Knauf <wolfgang.knauf at gmx.de
> <javascript:;>
> > <mailto:wolfgang.knauf at gmx.de <javascript:;>>> wrote:
> >
> > Hi guys,
> >
> > I try to sort out the "unauthenticatedIdentity" feature for
> JAS login
> > modules in WildFly 8.
> > To my understanding, when logging in without
> username/password, the
> > login module should fallback to this
> "unauthenticatedIndentity", which
> > can only access public content (e.g. unsecured or @PermitAll ejb
> > methods).
> >
> > But without a login, my public ejb method shows that
> > "this.sessionContext.getCallerPrincipal().getName()" returns
> > "anonymous", which is NOT the "unauthenticatedIdentity" value.
> > And "httpRequest.login(null, null)" will fail because of the
> Undertow
> > implementation.
> >
> > How can a switch to the user name declared in the
> > "unauthenticatedIdentity"?
> >
> > Same question e.g. here:
> https://community.jboss.org/thread/237899
> >
> > Seems I have a basic misunderstanding about this ;-), but I
> don't find a
> > clear explanation in the web...
> >
> > Best regards
> >
> > Wolfgang Knauf
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org <javascript:;> <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
More information about the undertow-dev
mailing list