Yep I copied it from there. My original fix was just to call super.getUser in place of the above to avoid the duplication, but that got into an infinite loop, well at least a stackoverflow. I'm not quite sure why.

Tested out your suggested fix, Jamie, and it worked beautfiully (looks like it came from DefaultAuthenticator.getUser?... I don't know why I didn't think to include this logic in the fitst place).

I've updated the repo with the changes and all looks good. Thanks, again!

Thanks for the bug report - I (arrogantly) assumed there would be no bugs in the code and so didn't bother setting up the issue tracker.

I'll investigate and patch the issue today, and all enable issues on the bitbucket project.

Issue tracking does not seem to be enabled on your bitbucket project so I'll report what seems to be a bug here.

Remember me does not appear to work with this authenticator (https://answers.atlassian.com/questions/101759/confluence-remember-me-doesn-t). I would say it's this line: https://bitbucket.org/jaysee00/example-confluence-sso-authenticator/src/890ae2e42724a8ae9eb3ecfbab7d758f7bd009b0/src/main/java/com/atlassian/confluence/seraph/example/ExampleSSOAuthenticator.java?at=master#cl-103

Because you call getUserFromSession, this sets up a session. Because there is a session, getUserFromCookie is never called, in com.atlassian.seraph.auth.DefaultAuthenticator#getUser.

If debug is on, you hit the line: "Session found; BUT it has no Principal in it".

I don't know how to fix this properly. My workaround is to change the line linked by the bitbucket link to:

            log.info("No SSO information present in request.");

            final Principal cookieUser = getUserFromCookie(request, response);
            if (cookieUser != null)
            {
                return cookieUser;
            }

            if (RedirectUtils.isBasicAuthentication(request, getAuthType()))
            {
                final Principal basicAuthUser = getUserFromBasicAuthentication(request, response);
                if (basicAuthUser != null)
                {
                    return basicAuthUser;
                }
            }

            return null;

Quick note mostly for Joseph. It took a matter of minutes to integrate my SSO code into your example code and it worked straight off the bat, thanks so much. I've thrown out nearly all my custom home-spun code that tried to do the same but didn't quite work.

I completely agree that Joe's code should be shipped with confluence, such that I can easily subclass it, and not have to check bitbucket for any changes with every confluence release. As there is a non-trivial amount of code that Joe has provided this seems likely, and is yet another chance for stuff to go wrong with upgrades (and there is already plenty of scope for massive cock-ups when upgrading).

Would be great if the post-login code could be triggered in some way other than just authenticate(username, password), which a custom SSO authenticator, eg PKI, is never going to call.

Related: https://answers.atlassian.com/questions/97536/how-do-i-get-hold-of-a-directorymanager-or-directoryinstanceloader-in-confluence