[
https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz edited comment on WFLY-1067 at 9/30/14 4:09 PM:
--------------------------------------------------------------------
This integration exercise is going to be tricky. The AS security infrastructure is
completely based on a very narrow set of mechanisms (callbacks, SSLContexts) and does not,
as far as I can tell, give direct access to the initial configuration information, such as
the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the
other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to
the initial configuration information, like the password files and keystores.
This could be helped by having some means to access the original configuration information
for each mechanism. I suppose it could be looked up from the model in the addressable
resource for the realm, given the realm and the mechanism. Whether or not this is
legitimate or the best way of providing this information or will cause complications is
another matter.
The SASL JGroups protocol layer does already provide integration with security-realms for
authentication. Tristan has cited this as the main reason for implementing the layer. But
this does not help with ENCRYPT nor the non-standard AUTH mechanisms.
was (Author: rachmato):
This integration exercise is going to be tricky. The AS security infrastructure is
completely based on a very narrow set of mechanisms (callbacks, SSLContexts) and does not,
as far as I can tell, give direct access to the initial configuration information, such as
the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the
other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to
the initial configuration information, like the password files and keystores.
This could be helped by having some means to access the original configuration information
for each mechanism. I suppose it could be looked up from the model in the addressable
resource for the realm, given the realm and the mechanism. Whether or not this is
legitimate or the best way of providing this information or will cause complications is
another matter.
Integrate JGroups with core AS security infrastructure
------------------------------------------------------
Key: WFLY-1067
URL:
https://issues.jboss.org/browse/WFLY-1067
Project: WildFly
Issue Type: Feature Request
Components: Clustering, Security
Reporter: Brian Stansberry
Assignee: Richard Achmatowicz
Container task for better integrating JGroups security with overall AS security. The
basic concept is the various security aware aspects of JGroups will expose an SPI, and the
AS can create implementations of those SPIs that integrate with the AS security realms.
The AS JGroups subsystem will inject the implementation into the JGroups runtime
components.
Subtasks are for the various aspects. These can be done separately but a common overall
design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)