[
https://issues.apache.org/jira/browse/SHINDIG-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141466#comment-13141466
]
[email protected] commented on SHINDIG-1636:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2648/#review2993
-----------------------------------------------------------
Ship it!
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.
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.
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.
- Jesse
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
