Mailing-List: contact oak-issues-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Mon, 4 Sep 2017 04:16:00 +0000 (UTC)
From: "Amit Jain (JIRA)" <jira@apache.org>
To: oak-issues@jackrabbit.apache.org
Message-ID: <JIRA.13096993.1503486423000.18906.1504498560160@Atlassian.JIRA>
In-Reply-To: <JIRA.13096993.1503486423000@Atlassian.JIRA>
References: <JIRA.13096993.1503486423000@Atlassian.JIRA> <JIRA.13096993.1503486423623@jira-lw-us.apache.org>
Subject: [jira] [Commented] (OAK-6575) Provide a secure external URL to a
 DataStore binary.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 04 Sep 2017 04:16:09 -0000


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

Amit Jain commented on OAK-6575:
--------------------------------

[~ianeboston], [~chetanm]

I can commit the change but
bq. Hence we would need to expose a custom type
The question is should this custom type be for the native S3 signed URL or the CloudFront signed URL. It seems more natural to me to have the URI for the native S3 signed URL coming from the S3DataStore pov and have something like a PublicURI exposed for CloudFront etc. which need additional configuration/setup over the plain S3 setups.

There are a couple of small changes I propose to make to the patch:
* Rename the {{S3SignedUrlAdapterFactory}} and its related tests to something like {{CloudFrontS3SignedUrlAdapterFactory.java}}. If you have a better suggestion please let me know
* Change {{aws-java-sdk-cloudfront}} version to {{1.11.24}} since, the current recommendation is to use that version for the S3DataStore. Higher versions than this require some more dependencies to be included in the applications. The upgrade to 1.11.150 can be made in another issue after internal testing.

[~ianeboston] let me know if these changes seem ok to you.

> 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
(v6.4.14#64029)