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@gmail.com>
An: Wolfgang Knauf <wolfgang.knauf@gmx.de>
Kopie (CC): "undertow-dev@lists.jboss.org" <undertow-dev@lists.jboss.org>
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@gmx.de
> <mailto:wolfgang.knauf@gmx.de>> 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@lists.jboss.org <javascript:;>
>     https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev