[
https://issues.apache.org/jira/browse/SHINDIG-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141514#comment-13141514
]
[email protected] commented on SHINDIG-1636:
--------------------------------------------------------
bq. On 2011-11-01 19:00:41, Jesse Ciancetta wrote:
bq. > This looks good to me, however if we're going to go this route I
wouldn't mind seeing the BlobCrypterSecurityTokenCodec changed to always expect
to get the actual token key from ContainerConfig -- and then making the code
that parses the container.js file smart enough to be able to resolve
res://key-file or file:///path/to/key-file automatically (or if not prefixed to
take the value from container.js as is). I think this would work well for this
particular case and would be a nice addition to the ContainerConfig code.
bq. >
bq. > It's pretty straight forward to add that support to ContainerConfig and
I've got a patch that does that which I could post if people are interested --
I'd need to add some additional unit tests around the enhancements to the
ContainerConfig loader but other than that it should be good to go.
bq. >
bq. > Or you could commit this as is and I could post that as a follow on
patch at a later date and if people like it we could move to it. Either way is
fine with me.
That was something I was thinking we could tackle later. I'm just trying to
identify the minimal amount of changes that will unblock my use case and then
we can focus on making it better.
- Stanton
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2648/#review2993
-----------------------------------------------------------
On 2011-11-01 18:12:28, Stanton Sievers wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2648/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-11-01 18:12:28)
bq.
bq.
bq. Review request for shindig, Ryan Baxter and Dan Dumont.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. This patch is to illustrate the minimal set of changes needed to allow the
BlobCrypterSecurityTokenCodec to have a key provided by the config instead of
needing a key file to be provided.
bq.
bq.
bq. This addresses bug SHINDIG-1636.
bq. https://issues.apache.org/jira/browse/SHINDIG-1636
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodecTest.java
1195457
bq. http://svn.apache.org/repos/asf/shindig/trunk/config/container.js
1195457
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java
1195457
bq.
bq. Diff: https://reviews.apache.org/r/2648/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Updated existing JUnits and added one more.
bq.
bq.
bq. Thanks,
bq.
bq. Stanton
bq.
bq.
> Create a mechanism to provide an encryption key to the SecurityToken workflow
> -----------------------------------------------------------------------------
>
> Key: SHINDIG-1636
> URL: https://issues.apache.org/jira/browse/SHINDIG-1636
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Stanton Sievers
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Currently,
> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.loadContainers(ContainerConfig,
> Collection<String>, Map<String, BlobCrypter>, Map<String, String>) reads an
> encryption key from a keyfile to instantiate the BlobCrypter. The keyfile is
> defined in the container.js. An improvement to this behavior would be to
> provide an injectable KeyProvider class that can return the key. This would
> allow the key to reside anywhere instead of in a static keyfile.
> Update:
> The old approach was to provide a KeyProvider class but that turned out to be
> a little too heavy and there was some contention over the best
> implementation. Until there is a consensus on the best way to implement that
> abstraction, we can simply add another config value to the container.js that
> is the key itself and have the codec read and use that value if it exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
