Details
-
Bug
-
Resolution: Timed out
-
Low
-
None
-
5.1.5, 5.2.5
-
2
-
Severity 3 - Minor
-
Description
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