jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Boston (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-6575) Provide a secure external URL to a DataStore binary.
Date Mon, 04 Sep 2017 07:39:02 GMT

    [ https://issues.apache.org/jira/browse/OAK-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152217#comment-16152217

Ian Boston commented on OAK-6575:

I will make the changes (CloudFrontS3SignedUrlAdapterFactory, 1.11.24) to the patch in a moment
and report back here when done.

I thought long and hard about URI vs PrivateURI vs PublicURI before suggesting PrivateURI.
Here is my logic.

This feature potentially leaks direct access to protected content managed by Oak, arguably
bypassing Oak security. Therefore it must as secure by default as possible and minimise the
risk of mistakes. The proposed usage of a uri obtains by adapting to PublicURI or PrivateURI
is clear. A Private URI is something that is private and should not be sent out to the world.
A PublicURI is public and can be sent out to the world. Its unlikely a programmer in Sling
or AEM is going to make a mistake. The URI class has a big benefit in that it is an existing
API part of the JRE and so doesn't require any special treatment from a dependency point of
view. However, adapting to URI gives no indication of where it is safe to use. If the URI
is public, then its safe to use everywhere. If the URI is private, then it is not. For that
reason using a URI class to indicate a private uri risks the developer in Sling or AEM using
it, without any knowledge, as a public uri breaching the security promises of this feature.

For these reasons I suggested keeping URI to represent the public URI, since it can be used
anywhere, and introducing a new PrivateURI so that private uris were only generated by developers
that had added the dependency to the API and were using it without doubt over its intended

I hope my reasoning makes sense. If you dont agree then I think we need to introduce new APIs
and not use URI or URL at all. This will certainly cause problems downstream as this feature
will require a new dependency, directly on Oak, to be utilized. I have no doubt that will
generate a RTC and delay as it will require changes to the pom.xml.

> Provide a secure external URL to a DataStore binary.
> ----------------------------------------------------
>                 Key: OAK-6575
>                 URL: https://issues.apache.org/jira/browse/OAK-6575
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: blob, core, jcr
>            Reporter: Ian Boston
>             Fix For: 1.8
> Where the DataStore is a DataStore that may be accessed over an independent API it would
be advantageous for Oak to provide a secure URL to allow direct, read only access to the current
immutable instance of that binary.  The term "secure" needs to be defined, but typically it
would a URL that is valid for a appropriately short length of time to ensure that the risk
of the URL being used by a user that it was not intended for, is minimised. It should also
ensure that anyone in possession of the URL could not use the information in the url to create
a valid URL or a valid URL to a different binary.
> One example of such a URL might be a AWS Signed URL as used by AWS CloudFront to access
private content. The signed url being signed by a private key known only to the Oak instance
and the the CloudFront or S3 instance. The signed url having a significantly low ttl so that
a redirect by the same client would work.  
> Oak should only emit these URLs to sessions that could otherwise read the binary directly
from Oak, and Oak should be in complete control of the nature of the url and the security
mechanisms applied to the URL.
> The viability of the approach has been investigated showing that given a JCR Binary it
is possible to get the Oak Blob Content Identifier using ValueImpl.getBlob((Value)jcrBinary).getContentIentifier()
and form there, knowing the way in which the DataStore implementation transforms that into
a pointer into the datastore implementation form a URL to be made secure.
> To achieve the above, internal implementation details specific to the Oak DataStore implementation
are required, hence this request to implement as a part of Oak rather than to reverse engineer
in some external project.
> Since API changes are often significant using the Sling AdapaterFactory approach would
allow a ServletFilter to selectively use the URL in a redirect, avoiding any new API methods
to existing Oak APIs. A new interface might be required, in the example below that interface
is SignedBinaryURL.
> {code}
> public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse,
FilterChain filterChain) throws IOException, ServletException {
>         if ( servletRequest instanceof SlingHttpServletRequest  && servletResponse
instanceof SlingHttpServletResponse) {
>             if ("GET".equals(((SlingHttpServletRequest) servletRequest).getMethod())){
>                 Resource resource = ((SlingHttpServletRequest) servletRequest).getResource();
>                 SignedBinaryURL url = resource.adaptTo(SignedBinaryURL.class);
>                 if (url != null) {
>                     ((SlingHttpServletResponse) servletResponse).sendRedirect(url.getURL());
>                     return;
>                 }
>             }
>         }
>         filterChain.doFilter(servletRequest, servletResponse);
>     }
> {code}
> If the AdapterFactory to go from Binary to SingedBinaryURL is not present then url will
always be null, and no-op. If it is present, and Oak decides no URL is appropriate, then no-op.
> Only if the Oak DS implementation being used supports the external URL and Oak decides
it is appropriate, will a url be available and a redirect performed.
> I have used AWS S3 URLs as an example, however the approach should be applicable (and
pluggable) to most REST based APIs to private binary content.

This message was sent by Atlassian JIRA

View raw message