On Sunday, August 10, 2014, Wolfgang Knauf wrote:
I think my
basic question should be "what is the unauthenticatedIdentity used
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
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.
-------- Original-Nachricht --------
Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow
Datum: 09.08.2014 14:33
> 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(a)gmx.de
> 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",
> can only access public content (e.g. unsecured or @PermitAll ejb
> But without a login, my public ejb method shows that
> "this.sessionContext.getCallerPrincipal().getName()" returns
> "anonymous", which is NOT the "unauthenticatedIdentity"
> And "httpRequest.login(null, null)" will fail because of the Undertow
> How can a switch to the user name declared in the
> Same question e.g. here: https://community.jboss.org/thread/237899
> Seems I have a basic misunderstanding about this ;-), but I don't
> clear explanation in the web...
> Best regards
> Wolfgang Knauf
> undertow-dev mailing list
undertow-dev mailing list