[jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008191#comment-13008191 ] 

Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------

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)