[ 
https://issues.apache.org/jira/browse/OAK-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amit Jain updated OAK-6575:
---------------------------
    Fix Version/s:     (was: 1.7.10)

> 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, security
>            Reporter: Ian Boston
>            Assignee: Amit Jain
>             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)

Reply via email to