[undertow-dev] "unauthenticatedIndentity" in Undertow

arjan tijms arjan.tijms at gmail.com
Tue Aug 12 06:28:16 EDT 2014


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140812/19535f2d/attachment-0001.html 


More information about the undertow-dev mailing list