[
https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz edited comment on WFLY-1067 at 10/2/14 11:56 AM:
---------------------------------------------------------------------
What follows is a proposal for integrating JGroups with Wildfly in the short term, and
some comments on what to do in the longer term. These comments are based on discussions
with Bela and the clustering group (all confessed security non-experts). I'd also
appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and
the implementations do not make use of "modern" security mechanisms such as
callbacks and SSLContexts for obtaining authentication information and setting up
encrypted channels
- the SASL protocol is standards-based but does not implement the standard fully; support
for Quality of Protection in a multicast environment is not provided, and so is a not a
complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not
supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come
up to standard with "modern" security, might be an desirable improvement on the
current situation. The SASL layer could have QoP added in the form of multicast-friendly
encryption, based on the modern security mechanisms referred to earlier, in a pared down,
clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified
in security realms. Achieving this through direct use of security realms is not easy as
AUTH and ENCRYPT require access to security information in a form which is hidden by the
SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make
use of callbacks). SASL in its current form can be configured for authentication using the
security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of
work; a much simper option is to bypass the security realm interface and read the file
information from the security realm model itself (i.e. obtaining the keystore and
truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking
of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector
uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate
between the OptionsMap, Callbacks and SSLContext which Remoting expects and the
OptionsMap, Callbacks and SSLContext which the security realm provides. This interface
will probably not change as it is based on an agreed set of "modern" mechanisms.
A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and
that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described
in a previous post, and get the required security configuration information as described
above (from the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a
more modern implementation as the JGroups protocols are refactored and as Elytron becomes
more widely used.
Feedback appreciated.
was (Author: rachmato):
What follows is a proposal for integrating JGroups with Wildfly in the short term, and
some comments on what to do in the longer term. These comments are based on discussions
with Bela and the clustering group (all confessed security non-experts). I'd also
appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and
the implementations do not make use of "modern" security mechanisms such as
callbacks and SSLContexts for obtaining authentication information and setting up
encrypted channels
- the SASL protocol is standards-based but does not implement the standard fully; support
for Quality of Protection in a multicast environment is not provided, and so is a not a
complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not
supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come
up to standard with "modern" security, might be an desirable improvement on the
current situation. The SASL layer could have QoP added in the form of multicast-friendly
encryption, based on the modern security mechanisms referred to earlier, in a pared down,
clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified
in security realms. Achieving this through direct use of security realms is not easy as
AUTH and ENCRYPT require access to security information in a form which is hidden by the
SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make
use of callbacks). SASL in its current form can be configured for authentication using the
security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of
work; a much simper option is to bypass the security realm interface and read the file
information from the security realm model itself (i.e. obtaining the keystore and
truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking
of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector
uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate
between the OptionsMap, Callbacks and SSLContext which Remoting expects and the
OptionsMap, Callbacks and SSLContext which the security realm provides. This interface
will probably not change as it is based on an agreed set of "modern" mechanisms.
A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and
that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described
above, and get the required security configuration information as described above (from
the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a more modern
implementation as the JGroups protocols are refactored and as Elytron becomes more widely
used.
Feedback appreciated.
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)