camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-7079) Improvements to camel-shiro's ShiroSecurityProcessor
Date Wed, 18 Dec 2013 14:00:09 GMT

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

Mime
View raw message