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(a)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(a)lists.jboss.org <javascript:;> https://lists.jboss.org/mailman/listinfo/undertow-dev

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