It looks like the NegotiationAuthenticator provides its own
setNext()/getNext() implementation.  This appears to be breaking the
code above.

   @Override
   public void setNext(final Valve nextValve)
   {
      super.setNext(new Valve()
      {

         public String getInfo()
         {
            return nextValve.getInfo();
         }

         public Valve getNext()
         {
            return nextValve.getNext();
         }

         public void setNext(Valve valve)
         {
            nextValve.setNext(valve);

         }

         public void backgroundProcess()
         {
            nextValve.backgroundProcess();
         }

         public void invoke(Request request, Response response) throws IOException, ServletException
         {
            Session session = request.getSessionInternal();
            GSSCredential credential = (GSSCredential) session.getNote(DELEGATION_CREDENTIAL);
            try
            {
               DelegationCredentialManager.setDelegationCredential(credential);
               nextValve.invoke(request, response);
            }
            finally
            {
               DelegationCredentialManager.removeDelegationCredential();
            }
         }

         public void event(Request request, Response response, HttpEvent event) throws IOException, ServletException
         {
            nextValve.event(request, response, event);
         }
      });
   }

The ClusterSessionValve gets put into the pipeline correctly and session
replication works if I comment out the NegotiationAuthenticator.setNext() 
method.

I believe I see the cause, debugging further to be sure - the Valve ClusterSessionValve also implements Lifecycle - I suspect that as the wrapper around the valve does not implement this interface some Lifecycle related notifications are getting missed.

Darran Lofthouse <darran.lofthouse> updated the status of jira SECURITY-733 to Resolved

Darran Lofthouse <darran.lofthouse> made a comment on jira SECURITY-733

JBoss Negotiation makes use of a wrapper to intercept calls through the Valves to ensure the delegation credential is set - this was unfortunately hiding the Lifecycle implementation of the wrapped valve.

The code change now introduces an additional valve in the chain rather than completely wrapping the next valve - this makes the Lifecycle implementation visible.

I've tried to verify it, but it still doesn't work in Negotiation 2.2.3. Application without NegotiationAuthenticator works fine. 

@Derek, It hasn't blocker flag set yet. Is it a customer request? If so I would request the blocker flag for this issue. WDYT?

Setting Blocker flag to ?, we need to discuss this on triage meeting

jboss security negotiation will be probably upgraded in ER7 for ldap login module fix ...

Created attachment 742686 [details]
Simple application with NegotiationAuthenticator

Created attachment 742687 [details]
Simple application without NegotiationAuthenticator

Darran can you look at this (again)?

@Ondrej, It is a customer request.  I would really like to get this fix included in EAP 6.1, but I don't think it has to be a blocker.

Assign to Jaikiran, if he has time to move it forward.

I can't see Darrin's comment on the case, but I see it on the linked jira and in emails...



Darrin, the FIX and RESULT in the Doc Text are a description of how this should be fixed in the future.

Setting need info as I don't understand what is now failing.

Created attachment 757589 [details]
test.war

Steps to reproduce:
0) save attached test.war to /tmp
1) ./domain.sh
2) ./jboss-cli.sh -c
/server-group=main-server-group:write-attribute(name=profile,value=ha)
/server-group=main-server-group:write-attribute(name=socket-binding-group, value=ha-sockets)
/server-group=main-server-group:restart-servers
deploy /tmp/test.war --server-groups=main-server-group
3) make a single request to http://localhost:8080/test/
4) make a single request to http://localhost:8230/test/

And here are the difference against the expected behavior:

==========
With the NegotiationAuthenticator (i.e. test.war)

Step 3) output:
Session attribute 'test': null
Writing 'value' to session attribute 'test'.

Step 4) output:
Session attribute 'test': null
Writing 'value' to session attribute 'test'.

==========
Without the NegotiationAuthenticator (remove WEB-INF/jboss-web.xml from test.war):

Step 3) output:
Session is null!
Session attribute 'test': null
Writing 'value' to session attribute 'test'.

Step 4) output:
Session attribute 'test': value
Writing 'value' to session attribute 'test'.

If you deploy this test.war on two standalone-ha nodes, it works fine.

Steps to reproduce:
0) copy test.war to standalone/deployments on two separate installations
1) ./standalone.sh -c standalone-ha.xml
2) ./standalone.sh -c standalone-ha.xml \
-Djboss.socket.binding.port-offset=150 \
-Djboss.node.name=node2
3) make a single request to http://localhost:8080/test/
4) make a single request to http://localhost:8230/test/

Session attribute is successfully replicated.

Sorry, it doesn't work too. Tested on wrong version.

Update milestone and related.

We are moving this to CP02 as this missed the cutoff.

TODO: 6.3 bug to be created.

Derek Horton <dhorton> updated the status of jira SECURITY-733 to Reopened

Removing privacy flags for inclusion in 6.3.0 Release Notes as a Known Issue.

We nee it for 6.3 CP01 !
I just opened a support-case (01183034).

This should have been a blocker and it's definitely not o.k. to change the target release to 6.4.0.

Reviewing the comments again in this BZ I am considering if the reason I have seen a difference in behaviour is that my testing was after authentication had been performed but the remaining failure scenario is where no authentication is being performed.

Derek mentions above a suspicion regarding a call to getSessionInternal() - one thing I do notice here is that we may be trigering session creation on every request when it is only the ones that attempt authentication that we want a session created for but not sure how this relates.

And as I type that I believe I see the problem, the ClusteredSessionValve is performing some initialisation so that it receives a Callback when a new session is created - however the NegotiationAuthenticator is using sessions before we hit the ClusteredSessionValve so this callback is not being received.

It looks like I should make a small fix to JBoss Negotiation to prevent sessions being created where they are not actually required however I believe this can be resolved with a configuration change.

Firstly a history lesson ;-)

In previous AS/EAP releases SPNEGO would be enabled by first defining a custom authenticator in the global configuration and then in the web.xml set the auth-method to match the name assigned to the authenticator e.g. SPNEGO.

However when we reached AS7 this global configuration was no longer possible and a request for it to be restored was denied, so the workaround was to ask users to add the authenticator valve to jboss-web.xml - during deployment this is detected and the addition of a subsequent authenticator is skipped.

Unfortunately as we see in this BZ this means that the NegotiationAuthenticator valve is now too early in the chain of valves and triggers session creation before the ClusteredSession valve so session creation goes unnoticed.

The good news is under PRODMGT-136 the definition of globally defined authenticators has now been restored so it should now be possible for the NegotiationAuthenticator valve to be defined globally and referenced from the auth-method of the web.xml.  This should be done instead of adding it to jboss-web.xml and should result in it being added in the correct place in the chain of valves AFTER the ClusteredSession valve.

I will go ahead with the minor fix I see is needed here but the comment from Derek re getSessionInternal definitely looks to me to be the issue here.

I am about to send in a PR and ask for this to be switched to ON_QE, the PR will contain the following bug fix: -

https://bugzilla.redhat.com/show_bug.cgi?id=1166724

Note: For this specific bug I don't believe any fix is required and instead the NegotiationAuthenticator should be defined as a global authenticator in the web subsystem and then referenced by the auth-method in the web.xml - the valve definition should be removed from the jboss-web.xml descriptor.

However do take care as the PR minimises when sessions are created which would mask the underlying issue here.

https://github.com/jbossas/jboss-eap/pull/2038 Setting to ON_QA in line with Darran's instructions in https://github.com/jbossas/jboss-eap/pull/2038 and previous comment.