You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org> on 2013/12/18 15:00:09 UTC

[jira] [Updated] (CAMEL-7079) Improvements to camel-shiro's ShiroSecurityProcessor

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

Colm O hEigeartaigh updated CAMEL-7079:
---------------------------------------

    Attachment: camel.patch.2
                camel.patch.1

> Improvements to camel-shiro's ShiroSecurityProcessor
> ----------------------------------------------------
>
>                 Key: CAMEL-7079
>                 URL: https://issues.apache.org/jira/browse/CAMEL-7079
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: Colm O hEigeartaigh
>         Attachments: camel.patch.1, camel.patch.2
>
>
> I am attaching two different patches for some improvements to the ShiroSecurityProcessor in Camel's camel-shiro component. I'd like some feedback on which patch should apply.
> The scenario is that a ShiroSecurityToken object is retrieved in the ShiroSecurityProcessor. Currently, this object is first encrypted, and then decrypted, before authentication/authorization checking applies. 
> a) Patch "1" makes no change to the current functionality of the processor, but provides a performance improvement to avoid encrypting + decrypting a ShiroSecurityToken object. We only need to decrypt a "String" or "ByteSource" header, not a ShiroSecurityToken object.
> b) Patch "2" follows the old pattern of encrypting + decrypting the ShiroSecurityToken object, but replaces the unencrypted token in the exchange, with the subsequent encrypted token. This may help avoid unintentional propagation of plaintext values in subsequent communications.
> The tests all pass with both approaches. 



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)