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

[email protected] commented on SHINDIG-1636:
--------------------------------------------------------



bq.  On 2011-10-24 18:09:46, Henry Saputra wrote:
bq.  > 
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java,
 line 93
bq.  > <https://reviews.apache.org/r/2362/diff/6/?file=52120#file52120line93>
bq.  >
bq.  >     Since we are trying to be flexible, I was trying to find useable 
injection points for the BlobSecurityTokenCodec so SHindig implementors dont 
have to override this file to extend it. 
bq.  >     
bq.  >     So any internal "new" is bad. For now it looks ok bc default key and 
domain listeners do exactly what it needs to do to update the keys but since 
the purpose of this patch also to make it extendible might as well inject while 
you can.
bq.  
bq.  Dan Dumont wrote:
bq.      I would rather see inline anonymous creation of the generic 
ValueChangeListener used here rather than doing a new KeyProvidedValueListener.
bq.      
bq.      The ProvidedValueListener generic interface is provided by the 
abstraction and shouldn't need to be injected.
bq.      I think that it's easier to follow if we just add anonymous 
implementations inline.  But that's just me.
bq.      
bq.      Anyway, the focus of these patches is to move the logic of building 
derived values from the config (key to use) into these ValueProvider classes so 
that they can be more easily overridden by injection.  It's possible that we 
could also move the derived keys into the provider also, we weren't sure how 
generic that task would be for different kinds of crypto.

ProvidedValueListener -> ValueChangeListener 


- Dan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2362/#review2797
-----------------------------------------------------------


On 2011-10-24 17:58:20, Stanton Sievers wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2362/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-10-24 17:58:20)
bq.  
bq.  
bq.  Review request for Ryan Baxter, Dan Dumont and Jesse Ciancetta.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  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. 
bq.  
bq.  Initial review to Dan, Ryan, and Jesse.  Once we've decided that this 
seems like a rational approach, I'll add the dev list.
bq.  
bq.  This patch depends on https://reviews.apache.org/r/2467/
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/main/java/org/apache/shindig/auth/BasicSecurityTokenCodec.java
 1187375 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java
 1187375 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/DefaultSecurityTokenCodec.java
 1187375 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/KeyFileKeyProvider.java
 PRE-CREATION 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/KeyProvider.java
 PRE-CREATION 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodecTest.java
 1187375 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/DefaultSecurityTokenCodecTest.java
 1187375 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/KeyFileKeyProviderTest.java
 PRE-CREATION 
bq.  
bq.  Diff: https://reviews.apache.org/r/2362/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  Updated and ran existing JUnits.  
bq.  Created new JUnits for the new KeyFileKeyProvider.  
bq.  Performed manual functional tests with encrypted security tokens in the 
sample common container.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Stanton
bq.  
bq.


                
> Create a KeyProvider 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.

--
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

        

Reply via email to