ratcashdev / authenticroast Goto Github PK

What steps will reproduce the problem?
1. Define a custom authenticator that implements begin or end methods
2. Wrap it with CompositeAuthenticator

What is the expected output? What do you see instead?
begin and end methods of the custom authenticator are never called. In my 
application I had to override CompositeAuthenticator and implement begin/end 
methods that loop through all "sub-authenticators" and call their begin/end 
methods respectively.

What steps will reproduce the problem?

1. Deploy a web-app using AuthenticRoast using the versioning feature, e.g. 
web-app##001.war.
2. Attempt to login.
3. Observe the stack trace.

What is the expected output?

A login.

What do you see instead?

A stack trace.

What version of the product are you using?

Current.

On what operating system?

Windows Vista, Tomcat 7.0.27.

Please provide any additional information below.

The cause is a slight mishandling of the JAAS configuration file URL.

The attached version of JAASAuthContextImpl.java fixes the problem.

This situation arises e.g. if you want to set a URL pattern to require SSL but 
you don't want access control. The TomcatAuthenticator returns 'false' if 
roles.length is zero. It should return 'true' in this situation. See 
org.catalina.authenticator.AuthenticatorBase#checkRoles() for the correct 
logic, which is somewhat more complex than this bald summary. I will develop a 
patch for this today.

Why is this? Makes life pretty tricky.

I suggest the one in Extras should be called CompositeAuthenticator.

SimplePrincipal should be removed to allow for greater flexibility.

1. Make it possible to configure everything via web.xml, especially composite 
authenticators, but also e.g. the login & login-error pages and anything else 
of this kind that is presently defined via a constructor parameter or method 
override. The idea being that you don't need to write any code, which will be 
possible if you are using the JAAS system.

2. If binary compatibility isn't a goal, which it doesn't seem to be, make more 
use of the javax.security.auth.message classes, given that they have to be 
present for the system to execute. For example, AuthException; AuthStatus 
instead of AuthenticationRequest.Status, MessageInfo instead of 
AuthenticationRequest, ServerAuthModule instead of PluggableAuthenticator, etc.

3. Pass around a Subject to the various authentication and loadPrincipal() 
methods.

4. The impending JAAS modules do not require any changes to the current API or 
internals. However I would like to make certain facilities available via the 
AuthenticationManager and AuthenticationRequest interfaces instead of via 
getInstance() methods as I presently have it.

TBC

Using the existing JAR files produces a NoSuchMethodError trying to instantiate 
org.apache.catalina.realm.GenericPrincipal, as the first Realm parameter has 
been removed.

The attached Reflection-based patch finds the new constructor and passes the 
new argument list, and appears to work correctly, so there don't seem to be any 
other 6/7 incompatibilities at this stage.

However you need to make a decision as to how to handle Tomcat 7. You will 
either need to (i) continue compiling against Tomcat 6 with this reflective 
patch for 7, or else (ii) start a new submodule that compiles against the 
Tomcat 7 binaries, and all the implications that flow from that such as 
configuring which TomcatAuthenticator you want to use. Or maybe the existing 
Tomcat6 authenticator needs to be split out into another submodule so you can 
just install the one you want.

Patched TomcatAuthenticator is attached for review.

[ERROR]Failed to execute goal 
com.google.code.maven-license-plugin:maven-license-plugin:1.4.0:check (default) 
on project AuthenticRoast-Impl: Resource not found in file system, classpath or 
URL: license-header.txt -> [Help 1]

The method is there to be overridden but nobody calls it that I can see.

Surely this:

        if (logoutAction) {
            manager.forward(request, getNextPath(manager, request));
            return ManageAction.Clear;
        }

should be:

        if (logoutAction) {
            onLogout(manager, request);  // <======
            manager.forward(request, getNextPath(manager, request));
            return ManageAction.Clear;
        }

???

Also it should be clarified that this is called *before* the session is 
destroyed.

EJP

An SSL client certificate authenticator base class is needed.

I will contribute one if I can get it working.

Calling the login-page directly should allow to log in and then redirect to 
some default location.

Currently the behavior is:
* 0.3.2 -> IlleagalStateException in AuthenticationManagerBase
* trunk -> forward to the login-page a second time

The settings named in the Summary force Tomcat to request a client certificate. 
Otherwise the request attribute "javax.servlet.ssl.X509Certificate" is never 
set.

These settings are undesirable in configurations where there are authenticators 
other than SSL, e.g. Form or Basic, because if the user is using a browser to 
login he is presented with a meaningless client-certificate-selection dialog, 
probably listing zero certificates.

Tomcat has internals that will perform an SSL renegotiation to request a client 
certificate, when required by an authentication module. The 
AuthenticationRequestImpl.Tomcat6 class should perform this action on behalf of 
the SSLClientAuthenticator when required, i.e. when the 
"javax.servlet.ssl.X509Certificate" attribute hasn't been set yet.

This fix requires:

1. Add a getPeerCertificates() method to AuthenticationRequest and 
AuthenticationRequestImpl. The basic implementation returns 
request.getAttribute("javax.servlet.ssl.X509Certificate").

2. Modify SSLClientAuthenticator to call this method instead of 
request.getAttribute("javax.servlet.ssl.X509Certificate").

3. Override this method in AuthenticationRequestImpl.Tomcat6 to do the Tomcat 
magic if necessary.

Patch files attached. The pom.xml for the Impl module adds the Apache Tomcat 
'coyote' module, and I brought the 'catalina' module version up to date while I 
was in it.

I don't know how any of this plays out in the JSR196 world. I certainly 
couldn't find anything in the specification (i.e. a PublicKeyCallback) that 
supports it. So the JSR196 implementation will continue to rely on the 
container having already got the certificate from the client. I've provided a 
possible override of the method for JSR196 but it may well be that just 
removing this is a better option.

I also don't know how it plays out in an SSO environment.

Note that to use this in association with clients that don't send the correct 
RFC 5746 messages, you may also need to configure Tomcat's SSL Connector with 
allowUnsafeLegacyRenegotiation="true". Java clients and servers should ideally 
use Java versions > 1.5 update 26, or > 1.6 update 22.

Authenticators need a way to access the current JAAS realm.

In my application the Subject and therefore its Principals are part of the 
HttpSession. This will only work if SimplePrincipal is Serializable. Patch 
attached.

Please provide at least a build.xml

This should be available via an overridable method, e.g. getRealmName().

I would like to be able to set REQUEST_PATH_NOTE in RequestHandler to be
some default location like a homepage. Currently when I log out of my app I
am taken back to login page and REQUEST_PATH_NOTE is cleared. So if I try
to log back in it won't work because the authenticator doesn't know where
to forward the request to.

Something like setPathForRequest(String path) maybe?

It's a bit risky to rely on ThreadLocal for these stores. It would be better to 
store things as request attributes. Also ThreadLocal usage promotes lots of 
nasty warnings from Tomcat when shutting it down, they are considered as memory 
leaks for some reason.

This is not an issue, rather a request for guidance.
What is the right way of implementing a FORM-based authenticator, especially 
the method checkCredentials()?
It seems I can't inject any kind of BEANS into this class (CDI or EJB) and thus 
I can't reach my database records. Looking up the beanManager is also 
unreliable.

Is direct JDBC the only possibility apart from configuring a JDBC realm in the 
container (actually would this even work properly when using JASPIC)?

The FormAuthenticator uses a redirect rather than a forward to show the login 
page. In my system (TC 6.0.26) this caused a redirection loop. The Tomcat 
FormAuthenticator uses forward() for this purpose, which seems to work. Code 
change required is in AuthenticationManagerBase:

            // Modified EJP 9 November 2010 to match Tomcat's FormAuthenticator.
//            authRequest.getHttpServletResponse().sendRedirect(
//                    context + path);
            RequestDispatcher disp = authRequest
                .getServletContext()
                .getRequestDispatcher(context+path);
            disp.forward(authRequest.getHttpServletRequest(), authRequest.getHttpServletResponse());
            authRequest.getHttpServletResponse().flushBuffer();
            // end EJP

plus suitable imports.

Following need to be added to TomcatAuthenticator.

    // This is an @Override for Tomcat 7, but not for Tomcat 6.
    public void login(String username, String password, Request request)
    {
        // Until I figure out the implementation if any.
        // Not sure that it really makes sense to support this in
        // a JAAS environment.
        throw new UnsupportedOperationException("login");
    }

    // This is an @Override for Tomcat 7, but not for Tomcat 6.
    public void logout(Request request)
    {
        // Just clear the remote user.
        request.setUserPrincipal(null);
        request.setAuthType(null);
            Session session = request.getSessionInternal(false);
        session.setPrincipal(null);
        session.removeNote(Constants.SESS_USERNAME_NOTE);
        session.removeNote(Constants.SESS_PASSWORD_NOTE);
    }

DelegatingAuthenticator calls the abstract method createAuthenticators() in its 
constructor. This is generally considered to be poor practice as the derived 
class is only half-constructed at this point. In my case it caused an NPE 
trying to log the created authenticators or indeed log any exceptions while 
creating them. The createAuthenticators() method should be called lazily when 
the result is needed.

The TomcatAuthenticator runs entirely its own regime about authentication and 
security constraint checking, and it registers a SimplePrincipal rather than a 
Tomcat GenericPrincipal with Tomcat so the default implementation of 
RealmBase.hasRole() always returns false, and this propagates up all the way to 
HttpServletRequest.isUserInRole() always returning false as well.

This can be most simply fixed by registering a GenericPrincipal with Tomcat in 
the TomcatAuthenticator:

    protected void register(AuthenticationRequest request,
            SimplePrincipal simplePrincipal) {
        try {
            Tomcat6Request req =
                    (Tomcat6Request) request;
            GenericPrincipal    gp = new GenericPrincipal(context.getRealm(), simplePrincipal.getName(), null, new LinkedList<String>(simplePrincipal.getGroups()), simplePrincipal);
            req.getCatalinaRequest().setAuthType("ROAST");
            req.getCatalinaRequest().setUserPrincipal(gp);
            Session session = req.getCatalinaRequest().getSessionInternal(true);
            session.setAuthType("ROAST");
            session.setPrincipal(gp);
            session.setNote(Constants.SESS_USERNAME_NOTE, simplePrincipal.getName());
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    }

This fix is tested. This fix also has the side-effect of making AuthenticRoast 
more compatible with existing Tomcat-based applications that know about 
GenericPrincipal for their own fell purposes, e.g. my own JAAS login module set.

However I must say I would like to get rid of SimplePrincipal altogether. It 
would be better to use javax.security.auth.Subject throughout, and make it all 
subject to user-configurable UserPrincipal and RolePrincipal classes in the 
same way as the Tomcat JAAS Realm is.

Hi, congratulations. Good job. 

I'm doing testing with your project. But I have a problem. I do not see how to 
use SSO across multiple web-apps. Is there a way to associate AuthenticRoast 
with a realm? Or is there another way to support SSO?

 Greetings!