Invalid Authorization header: Bearer

[mplwork]

I have NTLM configured as the only allowed authentication method:

web.xml

    <filter>
        <filter-name>SecurityFilter</filter-name>
        <filter-class>waffle.servlet.NegotiateSecurityFilter</filter-class>
        <init-param>
            <param-name>waffle.servlet.spi.NegotiateSecurityFilterProvider/protocols</param-name>
            <param-value>
              NTLM
            </param-value>
        </init-param>
    </filter>

The works fine generally but I keep getting java.lang.RuntimeException: Invalid Authorization header: Bearer exceptions for certain requests.

What is the reason for this? Is there anything else I need to configure?

Waffle is at

 	<dependency>
  		<groupId>com.github.waffle</groupId>
  		<artifactId>waffle-jna</artifactId>
  		<version>1.9.1</version>
  	</dependency>

Full stack trace:

java.lang.RuntimeException: Invalid Authorization header: Bearer
      at waffle.util.AuthorizationHeader.getSecurityPackage(AuthorizationHeader.java:82)
      at waffle.servlet.spi.SecurityFilterProviderCollection.doFilter(SecurityFilterProviderCollection.java:142)
      at waffle.servlet.NegotiateSecurityFilter.doFilter(NegotiateSecurityFilter.java:168)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
      at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
      at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
      at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
      at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:791)
      at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
      at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
      at java.lang.Thread.run(Unknown Source)

[pedroneil]

Have you found your way out of this yet?

[mplwork]

Have you found your way out of this yet?

I cheated. I wrote a filter that removes any authorization header which isn't one of ntlm, negotiate or basic. After that the request is passed on to waffle.

I was expecting this kind of logic in waffle itself but I am not sure if that would be the right approach. Comments welcome.

[pedroneil]

It's the source software that is sending a Bearer Token. Waffle only supports a single Authorization header and as far as I know the HTTP Authorization RFC only supports a single Authorization header.
If you own the source software, you probably want to stop it sending the Bearer Authorization Header e.g. Authorization: Bearer iueirADSFejwiiX.. and if you can't then change the client software, then using the filter to strip the authorization header is probably your way forward.

[mplwork]

It is Word and Excel that sends the Bearer token.

[hakanai]

We hit this as well, but we want to pass the header because we're using multiple types of authentication.

The assumption Waffle is making is that the header payload is always a single Base64 chunk:

waffle/Source/JNA/waffle-jna/src/main/java/waffle/util/AuthorizationHeader.java

Line 106 in 15660fa

return Base64.getDecoder().decode(this.getToken());

However, RFC 6750 defines a header which is treated as "invalid" by this method.

Perhaps the bug is that Waffle isn't reading the authentication scheme when making this decision? It should be seeing that the scheme is "Bearer" and not attempting to decode the header at all.

[pedroneil]

You would configure your authentication in your web.xml for the resources that are not to be covered by waffle. The error might be in your application configuration and or deployment model.?

…

On Thu, 14 Mar 2019, 04:10 Trejkaz (pen name), ***@***.***> wrote: We hit this as well, but we want to pass the header because we're using multiple types of authentication. The assumption Waffle is making is that the header payload is always a single Base64 chunk: https://github.com/Waffle/waffle/blob/15660fa9043f818fcc39aa20be5c65ead4fe4c28/Source/JNA/waffle-jna/src/main/java/waffle/util/AuthorizationHeader.java#L109 However, RFC 6750 defines a header which is treated as "invalid" by this method. Perhaps the bug is that Waffle isn't reading the authentication scheme when making this decision? It should be seeing that the scheme is "Bearer" and not attempting to decode the header at all. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#674 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAINCfW40pw-H8kGPWl-S8p6EKf-wTxks5vWcvAgaJpZM4aYjde> .

[hakanai]

The same URL is covered by both types of authentication. :)

[pedroneil]

To achieve that, I had to use the security filter it supports excluding bearer and exclude path patterns

…

On Thu, 14 Mar 2019, 07:24 Trejkaz (pen name), ***@***.***> wrote: The same URL is covered by both types of authentication. :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#674 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAINJjmqchnXcKJbLeHwzBg8GFS_BLXks5vWfkegaJpZM4aYjde> .

[hazendaz]

@trejkaz I think you are stating here that you believe waffle has a bug. Any chance you could review this again and see about raising a PR that might resolve this within waffle?

[hakanai]

I'm not completely clear on what the behaviour should be at the moment as it has been some time since investigating stuff surrounding this issue. My impression is that AuthorizationHeader assumes that all authorisation headers are in the format expected by WAFFLE itself. Does this mean that the issue is in AuthorizationHeader, or is the issue that AuthorizationHeader is being used when it should not?

[hazendaz]

Thanks @trejkaz I'm not super familar with this type and was just reviewing what we had out here. I'll try to review over this and see if its us. I do see the earlier stack trace so I have something to go on. I just will be unlikely to have fixed in this next release. However, that said, the next release has a few nice fixes coming and some 'sonar' considered vulnerability fixes so if anything you find some time down the road and can play around with this more, please try the release at that time. I plan to release in next week or so 2.2.0. Thanks.