EAP 6 - SPNEGO security with fallback to FORM user and password

Solution Verified - Updated -

Environment

  • Red Hat JBoss Application Enterprise Platform (EAP)
    • 6.x

Issue

  • We want to use SPNEGO security as default to make SSO work for our Windows users, but also allow users who don't have Windows (more generally: a kerberos enabled setup) to login with a username and password.
  • How to failover or use FORM based authentication without changing the auth method and keeping it to SPNEGO in the web.xml?
  • We have configured kerberos and SSO is working as expected inside the network. Now some of our user use their own systems and they can't access the application,for these users we need to add a fall back which will prompt for those users to provide their username/password and allow them to log in.

Resolution

This document is NOT valid for EAP 5. Please consult EAP 5 - SPNEGO security with fallback to FORM user and password

First setup SPNEGO as per usual, following the documentation and the article How to configure JBoss EAP 6 for SPNEGO (AD) authentication?

The next step is to add a standard security domain of your choice, usually an LdapExt pointing to your Active Directory.

                <security-domain name="ADRealm" cache-type="default">
                    <authentication>
                        <login-module name="LdapExtended-Module" code="LdapExtended" flag="required">
                            <module-option name="java.naming.provider.url" value="ldap://kdc2008.jbossuk.com:389"/>
                            <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
                            <module-option name="java.naming.security.authentication" value="simple"/>
                            <module-option name="bindDN" value="test"/>
                            <module-option name="bindCredential" value="secret"/>
                            <module-option name="baseCtxDN" value="CN=Users,DC=jbossuk,DC=com"/>
                            <module-option name="baseFilter" value="(sAMAccountName={0})"/>
                            <module-option name="rolesCtxDN" value="CN=Users,DC=jbossuk,DC=com"/>
                            <module-option name="roleFilter" value="(member={1})"/>
                            <module-option name="roleAttributeID" value="memberOf"/>
                            <module-option name="roleNameAttributeID" value="cn"/>
                            <module-option name="roleRecursion" value="0"/>
                            <module-option name="roleAttributeIsDN" value="true"/>
                            <module-option name="searchScope" value="SUBTREE_SCOPE"/>
                            <module-option name="throwValidateError" value="true"/>
                        </login-module>
                    </authentication>
                </security-domain>

Then modify your SPNEGO login module, adding a reference to the above domain:

                        <login-module name="SPNEGOUsers-Module" code="SPNEGOUsers" flag="requisite">
                            <module-option name="usernamePasswordDomain" value="ADRealm"/>
                            <module-option name="password-stacking" value="useFirstPass"/>
                            <module-option name="serverSecurityDomain" value="host"/>
                            <module-option name="removeRealmFromPrincipal" value="true"/>
                        </login-module>

Lastly you will need to add a standard JavaEE login form to your application and setup the login and error pages in web.xml 1

   <login-config>
    <auth-method>SPNEGO</auth-method>
    <realm-name>SPNEGO</realm-name>
        <form-login-config>
            <form-login-page>/login.jsp</form-login-page>
            <form-error-page>/error.jsp</form-error-page>
        </form-login-config>
   </login-config>

Logic Flow of the fallback authentication mechanism

At a high level, the fallback authentication flow is as follows: If SPNEGO based authentication fails, the SPNEGO login module invokes a "secondary" security-domain to authenticate the users. Once the "secondary" security-domain has authenticated the user, then control is returned to the SPNEGO login module and the flow continues on as normal. This "secondary" security-domain only needs to be able to verify a username and password.

Any roles that are assigned to the user by the "secondary" security-domain are discarded by the SPNEGO login module.

The secondary security-domain is only expected to provide the equivalent functionality that the SPNEGOLoginModule would provide should SPNEGO based authentication have occurred. After the authentication step whichever login module ended up handling authentication control continues back down the login module stack and role loading will happen using the chained login module.

When this fallback was developed it was developed along the lines that we are expecting fallback to be against the same repository of users, most likesly something like SPNEGO against Active Directory or fallback to LDAP queries and connections for authentication. For this reason the already defined chained login module was seen as sufficient to perform
the role loading as it was already in place anyway.

Limitations

JBoss Negotiation was designed such that it treats NTLM tokens somewhat like SPNEGO tokens. The fallback to FORM logic is only available in the case when no SPNEGO (or NTLM) tokens are present. As a result, a login form will not be presented to the browser if the browser sends an NTLM token.
As described in Why does SPNEGO Fallback To Form Authentication not working on JBoss EAP?, this limitation has been fixed since EAP 6.2.3.

  1. To Fallback to BASIC please do refer to "SPNEGO security with fallback to BASIC" Knowledge Solution. ↩︎

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments