[
https://issues.apache.org/jira/browse/SLING-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston updated SLING-6979:
------------------------------
Description:
This issue is a PoC. It adds a capability to Sling so that Sling can issue
authorizations on request to access external data APIs. It will have a SPI
allowing concrete implementations, as there are many different possible scheme.
For instance, when configured with AWS S3 implementations of those SPIs, on
request it will issue signed policy authorizations that allow a client to
perform the authorised operation on the AWS S3 REST API, for a specific key,
for a specific time period. This would support the client performing a direct
upload to S3 as detailed in
[http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html]. The
same pattern with a different authorization mechanisms would allow Sling to
emit X-Accell-Redirect headers for a Proxy LB like nginX to stream directly
from the storage. This effectively removes the task of streaming bytes through
Sling from Sling ensuring that all request threads in Sling are short lived,
not consuming survivour heap space. Long lived threads holding onto references
from stack will cause those objects to land in survivor heap costing more to GC
when the operation is complete, even if the transfer is streamed via the JVM.
Implementation will use a servlet attached to a resourceType. The Resource with
that resource type will contain the configuration information and SPI
implementation reference, so that requests to that Resource generate
authorizations of the appropriate form. The configuration should be capable of
mapping entire subtrees of individual resources. How the Resource path maps to
a storage path is an implementation detail to follow Sling best practice in
this area. (ie RESTfull)
The PoC will be done in a branch, and can be deleted if a complete failure.
Branch is at
was:
This issue is a PoC. It adds a capability to Sling so that Sling can issue
authorizations on request to access external data APIs. It will have a SPI
allowing concrete implementations, as there are many different possible scheme.
For instance, when configured with AWS S3 implementations of those SPIs, on
request it will issue signed policy authorizations that allow a client to
perform the authorised operation on the AWS S3 REST API, for a specific key,
for a specific time period. This would support the client performing a direct
upload to S3 as detailed in
[http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html]. The
same pattern with a different authorization mechanisms would allow Sling to
emit X-Accell-Redirect headers for a Proxy LN like nginX to stream directly
from the storage. This effectively removes the task of streaming bytes through
Sling from Sling ensuring that all request threads in Sling are short lived,
not consuming survivour heap space. Long lived threads holding onto references
from stack will cause those objects to land in survivor heap costing more to GC
when the operation is complete, even if the transfer is streamed via the JVM.
Implementation will use a servlet attached to a resourceType. The Resource with
that resource type will contain the configuration information and SPI
implementation reference, so that requests to that Resource generate
authorizations of the appropriate form. The configuration should be capable of
mapping entire subtrees of individual resources. How the Resource path maps to
a storage path is an implementation detail to follow Sling best practice in
this area. (ie RESTfull)
The PoC will be done in a branch, and can be deleted if a complete failure.
> Support authorization of access to external content
> ---------------------------------------------------
>
> Key: SLING-6979
> URL: https://issues.apache.org/jira/browse/SLING-6979
> Project: Sling
> Issue Type: New Feature
> Reporter: Ian Boston
> Assignee: Ian Boston
>
> This issue is a PoC. It adds a capability to Sling so that Sling can issue
> authorizations on request to access external data APIs. It will have a SPI
> allowing concrete implementations, as there are many different possible
> scheme. For instance, when configured with AWS S3 implementations of those
> SPIs, on request it will issue signed policy authorizations that allow a
> client to perform the authorised operation on the AWS S3 REST API, for a
> specific key, for a specific time period. This would support the client
> performing a direct upload to S3 as detailed in
> [http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html]. The
> same pattern with a different authorization mechanisms would allow Sling to
> emit X-Accell-Redirect headers for a Proxy LB like nginX to stream directly
> from the storage. This effectively removes the task of streaming bytes
> through Sling from Sling ensuring that all request threads in Sling are short
> lived, not consuming survivour heap space. Long lived threads holding onto
> references from stack will cause those objects to land in survivor heap
> costing more to GC when the operation is complete, even if the transfer is
> streamed via the JVM.
> Implementation will use a servlet attached to a resourceType. The Resource
> with that resource type will contain the configuration information and SPI
> implementation reference, so that requests to that Resource generate
> authorizations of the appropriate form. The configuration should be capable
> of mapping entire subtrees of individual resources. How the Resource path
> maps to a storage path is an implementation detail to follow Sling best
> practice in this area. (ie RESTfull)
> The PoC will be done in a branch, and can be deleted if a complete failure.
> Branch is at
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
