Hi,
I've added some more code and comments around authentication.
Among other things, I added two CallContextHandlers that support
UserPrincipals and simplify the use of custom authentication filters. I
also made the CallContextHandler work for WebServices. That is, all
bindings can now use the same authentication methods.
- Florian
Hi Jay,
Yes - absolutely happy to do that. I'll wait until I have verified my
work-around more thoroughly but should be able to provide a
documentation
update over the weekend.
Thanks
On Thu, Aug 18, 2016 at 8:50 PM, Jay Brown <jay.br...@us.ibm.com>
wrote:
Emrul,
Thank you for the feedback. Since you are knee-deep in this right
now,
would you consider writing up a paragraph or so (with code snippets,
if
needed) to describe your (verified) work-around while it is still
fresh in
your mind?
If so, Florian and I can add it to the server development guide :
https://github.com/cmisdocs/ServerDevelopmentGuideV2/blob/
master/docs/OpenCMIS%20Server%20Development%20Guide%20-%
202nd%20Edition.pdf?raw=true
Jay Brown
Senior Engineer, ECM Development
IBM Software Group
[image: Inactive hide details for Emrul Islam ---08/18/2016 08:30:50
AM---Hi Florian I understand the considerations here and accept
th]Emrul
Islam ---08/18/2016 08:30:50 AM---Hi Florian I understand the
considerations here and accept that most usages will
From: Emrul Islam <em...@emrul.com>
To: dev@chemistry.apache.org
Date: 08/18/2016 08:30 AM
Subject: Re: Security related question
------------------------------
Hi Florian
I understand the considerations here and accept that most usages will
see a servlet filter to carry out authentication. I still think a
documentation comment or similar would be really helpful because it is
an implementation detail that is not easily apparent - please consider
that as a suggestion.
For my use case its easy enough for me to patch my version of OpenCMIS
and move the token handling code earlier in the request processing
(which I can do because I don't need to read the body). I also agree
that servlet filters are typically where this is done but it isn't an
option in my case since Servlet 3 Asynchronous processing doesn't play
well with servlet filters on all app servers - but that's unrelated to
the Chemistry project.
Thanks for your speedy reply!
On Wed, Aug 17, 2016 at 4:30 PM, Florian Müller <f...@apache.org>
wrote:
> Hi,
>
> You are right - with a few exceptions. ;-)
>
> In many (most?) environments the CMIS server is embedded into a DMS
system
> or an application server or a cloud infrastructure or something similar,
> which does the authentication check before the request actually reaches
the
> CMIS implementation. For a standalone CMIS server a Servlet filter is the
> preferred approach.
> There are many different authentication approaches; standard and
proprietary
> approaches. If you can do the authentication by looking the request HTTP
> headers or checking a SSL client certificate, you should do that before
the
> request hits OpenCMIS. That is, an unauthenticated request is rejected
early
> and the request body is not read. But there are a few authentication
methods
> and authentication rules that require reading the request body first,
> because the authentication information is in the body. For example, if
the
> UsernameToken authentication is used in the Web Service binding the user
> name and password are in the body. A proprietary authentication method
might
> check for a custom parameter that contains an additional secret or an
> application identifier or something similar.
> The body cannot be read twice. If you read the body in a filter, you
break
> at least all CMIS calls that accept content. OpenCMIS has to read the
body.
> To allow those authentication methods that require data from the body,
> OpenCMIS provides multiple places where those checks can be done with
full
> access to the body. In this case you are right. Reading and managing the
> body consumes resources, which will be lost if the authentication is
> rejected. OpenCMIS makes sure that a malicious client cannot send an
> infinite stream of data, but if your resources are smaller than the
built-in
> OpenCMIS limits you are in trouble. In the end it's up to the developers
and
> operators if that is acceptable or not. I wouldn't do it.
>
>
> - Florian
>
>
>
>> Whilst working on a CMIS server implementation I happened to be
>> examining the CmisBrowserBindingServlet class and noticed that for
>> HTTP POST requests POSTHttpServletRequestWrapper is instantiated
>> before any authentication checks are carried out (e.g. before
>> getCallContextHandler() is invoked where a TokenHandler can check the
>> request).
>>
>> POSTHttpServletRequestWrapper appears to process multi-part requests
>> as soon as it is created, getting an output stream to store data.
>>
>> Unless I am mistaken (and forgive me if I am), it is conceivable that
>> this approach is vulnerable to Denial of Service attacks: you can send
>> a bunch of POST requests with multi-part data to the server that will
>> cause it to allocate memory (if less than memory threshold) and or
>> temp file space (if greater than memory threshold) and exhaust system
>> resources.
>>
>> I would suggest that authentication should be checked before
>> processing multi-part requests in keeping with best practices (e.g.
>> rejecting unauthenticated requests as soon as possible).
