-
Bug
-
Resolution: Timed out
-
Low
-
None
-
5.1.5, 5.2.5
-
2
-
Severity 3 - Minor
-
Let's preface this with - custom authenticators are not supported nor are 3rd party add-ons, but there is likely a bug in the seraph api here that either needs documentation to be updated or a fix implemented.
When using a custom authenticator (Confluence HTTP authenticator) authenticating against shibboleth, If getUserFromBasicAuthentication(request, response) is called on com.atlassian.seraph.auth.DefaultAuthenticator from within a custom authenticator's login method, it will loop forever.:
java.lang.StackOverflowError
at net.sf.hibernate.impl.SessionImpl.<init>(SessionImpl.java:543)
at net.sf.hibernate.impl.SessionFactoryImpl.openSession(SessionFactoryImpl.java:314)
at net.sf.hibernate.impl.SessionFactoryImpl.openSession(SessionFactoryImpl.java:327)
at net.sf.hibernate.impl.SessionFactoryImpl.openSession(SessionFactoryImpl.java:335)
at org.springframework.orm.hibernate.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:412)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:374)
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:263)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:101)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at sun.proxy.$Proxy43.requiresElevatedSecurityCheck(Unknown Source)
at com.atlassian.confluence.security.seraph.ConfluenceElevatedSecurityGuard.performElevatedSecurityCheck(ConfluenceElevatedSecurityGuard.java:62)
at com.atlassian.seraph.auth.DefaultAuthenticator.getUserFromBasicAuthentication(DefaultAuthenticator.java:507)
at shibauth.confluence.authentication.shibboleth.RemoteUserAuthenticator.login(RemoteUserAuthenticator.java:699)
at com.atlassian.seraph.auth.DefaultAuthenticator.getUserFromBasicAuthentication(DefaultAuthenticator.java:525)
at shibauth.confluence.authentication.shibboleth.RemoteUserAuthenticator.login(RemoteUserAuthenticator.java:699)
at com.atlassian.seraph.auth.DefaultAuthenticator.getUserFromBasicAuthentication(DefaultAuthenticator.java:525)
at shibauth.confluence.authentication.shibboleth.RemoteUserAuthenticator.login(RemoteUserAuthenticator.java:699)
Report from the Confluence add-on developer's page:
If getUserFromBasicAuthentication(request, response) is called on com.atlassian.seraph.auth.DefaultAuthenticator from within a custom authenticator's login method, it will loop forever.
You understand that they do not support custom authenticators. You also understand that explaining to you how to use their API is not part of the support agreement of Confluence. However, there is a common problem with usage of their seraph API by an authenticator, and this may be a vector for a DoS attack on Confluence, since one request can take down the server. Further, it may be accidentally triggered by a space export when using a custom authenticator that calls that method from their authenticator's login method to allow basic auth for space export. In other words, unless there is a way to get this to work, they cannot claim to work with SSO's like Shibboleth.
Tell them that you understand that they may have no way to fix this or provide a workaround, but that at the very least, they should (a) add to documentation about authenticator development to indicate that this method should not be called from an authenticator's login method (directly or indirectly) and that basic auth is not supported with custom authenticators fully which will affect some functionality of Confluence like the ability to export spaces, and (b) they should consider warning developers of known Confluence authenticators directly about this issue, since it is a possible attack vector.
https://github.com/chauth/confluence_http_authenticator/issues/9
Answers post detailing the behavior and log result linked above:
https://answers.atlassian.com/questions/183170/confluence-cli-with-confluence-http-authenticator-in-5-1
[CONFSERVER-32580] Error thrown when calling seraph api from custom authenticator
Thanks for filing this. I can make basic auth support optional in the Confluence HTTP Authenticator (used by those using Shibboleth and perhaps others), but it seems like something that should be allowed for space export, etc. and this code was actually from a suggestion to add this call some time back by Atlassian in email, although I'm pretty sure Joe had that method being called from getUser, but for some reason I remember that we need to use login, but I can't remember the reason:
On Nov 1, 2012, at 1:01 AM, Joseph Clark wrote:
Hi Gary,
I hope you don't mind me emailing you directly. Are you still maintaining the Confluence Shibboleth Authenticator?
I'm just sending off a quick note to you to let you know that I've had a bug report against the SSO Authenticator code I gave to you that was used to get the Shibb authenticator working with Confluence 4.x. Jamie Echlin recently borrowed the same code and discovered that it doesn't currently work with HTTP Basic authentication or with Confluence's built-in "remember me" cookie, for those users who fall back to the default Confluence login.
If this is a use case that would affect your authenticator, you may wish to apply the same change - you can see it here - https://bitbucket.org/jaysee00/example-confluence-sso-authenticator/changeset/a58987dbb016d408a42b6c113fd42aa6
(removed paragraph here of unrelated chit-chat)
Cheers,
Joe Clark
Atlassian Developer Relations
referenced in this commit: https://github.com/chauth/confluence_http_authenticator/commit/2729a0936b2cf9914e648a53bf3b39b995bf3b6d
Anyway, I'll plan on leaving the call to the getUserFromBasicAuthentication method in the custom authenticator's login method, but making its usage optional via configuration, and if I'm wrong about us needing to do that within the login method, I can try to more to getUser, but unfortunately, I have no Shib environment setup to test with directly anytime soon, so it will be up to others to test. In addition, it sounds like since this is tied to something like space export, it probably is called rarely, so the main danger is that it could be abused, it sounds like.
Thanks again.
Thank you for taking the time to raise, comment or vote on this Bug. We regret to inform you that due to a limited number of reports and based on our current backlog of higher impact issues that we are closing this issue as Timed Out.
If this issue is still impacting you on a recent version please feel free to comment with the affected version. Any further details you may be able to provide regarding reproduction or impact of this issue may help us better address this issue.
Thanks again.
Regards,
Confluence Development