MCB initialAuthContext with multiple contexts throws java.lang.NullPointerException

[Scott Koranda]

Hello,

I am using MCB 1.0.0 on CentOS 6.5 with Tomcat 6.0.24-62.el6 and Java 1.6.0_43.

If I configure the <intialAuthContext> element in
multi-context-broker.xml with only a single <context>, for example

    <initialAuthContext requestedOnly="false">
            <context name="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" />
    </initialAuthContext>

then with no existing session during the authentication flow I am
presented immediately with the configured method, in this case "Sample
JAAS Based Login Form (Password)".

That is what I expect.

If instead I configure the <initialAuthContext> element with two
<context> elements, for example

    <initialAuthContext requestedOnly="false">
            <context name="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" />
            <context name="http://id.incommon.org/assurance/bronze" />
    </initialAuthContext>

then I am presented, as I expect, a list of two methods. When I choose
one of the methods and click "Continue" I find in my Tomcat log files

SEVERE: Servlet.service() for servlet MCBLoginServlet threw exception
java.lang.NullPointerException
    at edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet.validateSelectedMethod(MCBLoginServlet.java:728)
    at edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet.processSelectedMethod(MCBLoginServlet.java:356)
    at edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet.service(MCBLoginServlet.java:171)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:87)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
    at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
    at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
    at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
    at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
    at java.lang.Thread.run(Thread.java:662)

My browser sees a 500.

In the idp-process.log file I see

23:58:55.189 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:466] - Showing only default contexts from configuration.
23:58:55.190 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:670] - Displaying velocity template of [selectcontext.vm]
23:59:56.298 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:113] - Request received from [xxx.xxx.xxx.xxx]
23:59:56.298 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:117] - Creating new principal object for request.
23:59:56.298 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:121] - principal = [{MCBUsernamePrincipal}[principal]]
23:59:56.299 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:129] - Relying party = [https://example.org/shibboleth-sp]
23:59:56.299 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:166] - Selected method name = [password]
23:59:56.299 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:170] - User selected authentication method to use of [password]
23:59:56.299 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:350] - User selected authentication method to use of [password]

Both of the contexts are defined in the <authContexts> element
and both have corresponding methods that are also defined in
the <authMethods> element.

The SP is not requesting a context.

If I reverse the test and only include the "bronze" context in the
<initialAuthContext> list then I again am immediately presented with a
login form as I expect.

It appears that when the number of contexts is  > 1 in 
<inintialAuthContext> an exception is thrown.

Can a misconfiguration elsewhere cause this?

Thanks,

Scott K