[jboss-jira] [JBoss JIRA] (SECURITY-745) WebJASPIAuthenticator doesn't register Subject with SecurityContext

[Jörn Tysper (JIRA)]

    [ https://issues.jboss.org/browse/SECURITY-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091770#comment-13091770 ] 

Jörn Tysper commented on SECURITY-745:
--------------------------------------

Hi,

this problems seems still to be around.

I was searching for a replacement for the [GenericHeaderBasedAuthentication|https://developer.jboss.org/wiki/GenericHeaderBasedAuthentication] that works within the Undertow platform. In case there is one please point me to the correct place - on was only able to find tomcat based solutions...

We are running Wildfly 9.0.0.Final and I am facing the exact same issue as the one described.


Scenario: I wrote an Undertow AuthenticationMechanism that I use in a simple enterprise application with a web module and an ejb module.
In the web module  I have an secured path configured via web.xml where I expect an authenticated user.
I also have included the Undertow Authentication Mechansim which registers correctly.

When I access the page, I do get authenticated correcltly via the Undertow Authentication Mechanism and also receive a valid Subject and Principal (with according Roles) in the WebContainer.
The servlet then accesses a local EJB which also has role-restrictions applied.
Here I receive an authorization error since the Subject is null.

The same scenario works just fine when I simply refresh the page and the JSESSIONSSO token is set.

Would moving away from the Undertow Authentication Mechanism to a JASPIC Module solve this issue?
Any help would be highly appreciated since this is the last thing that keeps us from moving away from WebSphere (there we are using a trust association interceptor (TAI) for header based authentication).

> WebJASPIAuthenticator doesn't register Subject with SecurityContext
> -------------------------------------------------------------------
>
>                 Key: SECURITY-745
>                 URL: https://issues.jboss.org/browse/SECURITY-745
>             Project: PicketBox 
>          Issue Type: Feature Request
>            Reporter: arjan tijms
>            Assignee: Stefan Guilhen
>              Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After an authenticated identity is established, WebJASPIAuthenticator registers this with the current request, session (if cache is enabled) and optionally SSO:
> {code}
>   /**
>      * <p>
>      * Registers an authenticated Principal and authentication type in our request, in the current session (if there is one),
>      * and with our SingleSignOn valve, if there is one.  Set the appropriate cookie to be returned.
>      * </p>
>      *
>      * [...[
>      */
>     @Override
>     protected void register(...)
> {code}
> [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/org/jboss/as/web/security/jaspi/WebJASPIAuthenticator.java#L241]
> What it does *not* do however is registering this same information with the [SecurityContext|http://grepcode.com/file/repo1.maven.org/maven2/org.picketbox/picketbox-spi-bare/4.0.18.Final/org/jboss/security/SecurityContext.java] where the EJB programmatic security can pick it up.
> Now in the next request {{org.jboss.as.web.security.SecurityContextAssociationValve}} will do this registration, but this means:
> # Programmatic EJB security ({{EJBContext#isCallerInRole}} etc) can not be used in the same request in which authentication took place, since the {{SecurityContextAssociationValve}} runs before {{WebJASPIAuthenticator}}
> # This mechanism depends on the session cache being used. _(This is true by default in JBoss, but it should not be according to the JASPIC spec and users may opt to disable it, possibly since some SAM could require this in order to function correctly)_
> I would like to propose putting code like the following in the mentioned {{register}} method or just after it, e.g.
> {code}
> protected boolean authenticate(Request request, HttpServletResponse response, LoginConfig config) throws IOException {
> 	// [...]
> 	// if the client principal is not a jboss generic principal, we need to build one before registering.
> 	if (!(clientPrincipal instanceof JBossGenericPrincipal))
> 	    clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal, gpc);
> 	
> 	this.register(request, response, clientPrincipal, authMethod, pvc != null ? pvc.getUsername() : null,
> 	        pvc != null && pvc.getPassword() != null ? new String(pvc.getPassword()) : null);
> 	// NEW: Associate Subject with SecurityContext
> 	
> 	SecurityContext context = SecurityActions.getSecurityContext();
> 	if (context == null) {
> 		throw PicketBoxMessages.MESSAGES.invalidNullSecurityContext();
> 	}
> 	
> 	JBossGenericPrincipal jbossGenericPrincipal = (JBossGenericPrincipal) clientPrincipal;
> 	context.getUtil().createSubjectInfo(new SimplePrincipal(
> 		jbossGenericPrincipal.getName()), 
> 		jbossGenericPrincipal.getCredentials(),
> 		jbossGenericPrincipal.getSubject()
> 	);
> {code}
> Maybe the security context should be created if it does not exists, but I think it should always exist at the given point, shouldn't it?
> Note that this depends on SECURITY-744, since in the current trunk version of {{WebJASPIAuthenticator}} the {{Subject}} isn't build at all.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)