[
https://jira.jboss.org/jira/browse/JBESB-2121?page=com.atlassian.jira.plu...
]
Daniel Bevenius commented on JBESB-2121:
----------------------------------------
Even as it stands we have a situation where only a specific set of
servers would be able to reauthenticate, those with the correct credentials in their
kestore. If the >message were to be sent to another set of ESBs or even to clients
without access to those credentials then they have no means of authenticating them.
Yes, this is intentional. The requirement here is that the correct credentials exist
in the keystores and that the ESBs have these in common.
The other question that spring to mind with the current code is what
is the reason for sending credentials around?
The reason is that the subject is used
when executing the pipeline.
At present the pipeline will decrypt the context and, if successful,
will do no authentication. If this is unsuccessful then it has no access to the
credentials to perform an authentication.
Yes, that is correct. But this has sort of
been a moving target and this was not always the case.
I'm really not sure anymore what should be passed between the ESB and what
requirements we have for interoperability :(
So I definitely think that we should talk and see if we can get the requirements set and
then take it from there.
Replace crypto util with sealed object
--------------------------------------
Key: JBESB-2121
URL:
https://jira.jboss.org/jira/browse/JBESB-2121
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Security
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP1
The crypto util classes are used to encrypt the SecurityContext but we should be able to
use a SealedObject.
The util also relies on having a keystore configured but it would be sufficient to have
the key(s) automatically generated on startup and use this to encrypt the session
information.
Another issue with the class is that the encrypt/decrypt methods repeatedly encrypt the
serialised data in chunks but the encrypt/decrypt sizes are very dependent on the block
cipher in use (currently RSA). If the configuration specifies a different cipher then
this is likely to fail. If we can move to a SealedObject then this should no longer be an
issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira