[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ 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)
10 years
[JBoss JIRA] (WFLY-3928) JBossSecuritySubjectFactory throws NullPointerException during JBoss shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3928?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3928:
----------------------------------------
I did some very preliminary poking around that I'll paste here in case it saves someone some time. Plus it has a question that [~raggz] hopefully can answer:
My *guess* is it's missing dependency problem.
If you turn on TRACE logging for category org.jboss.as.security, do you see logging like this:
"Exception getting AuthenticationManager for domain=<thesecuritydomain>" ?
This would be coming from [1].
If I'm right though you'll need input from someone more familiar with wiring up security domain dependencies to get feedback on what to do to fix the problem.
[1] https://github.com/jbossas/jboss-eap/blob/6.x/security/subsystem/src/main...
> JBossSecuritySubjectFactory throws NullPointerException during JBoss shutdown
> -----------------------------------------------------------------------------
>
> Key: WFLY-3928
> URL: https://issues.jboss.org/browse/WFLY-3928
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Environment: JBoss EAP 6.3
> Reporter: Tom Ross
> Assignee: Darran Lofthouse
>
> During JBoss shutdown we can see the following exception:
> {noformat}
> 2014-09-22 16:23:51,193 ERROR [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000903: Error creating Subject for crash recovery: java:/xa-resource-adapter/XAQueueConnectionFactory (null): java.lang.NullPointerException
> at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:83)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl$1.run(XAResourceRecoveryImpl.java:300)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl$1.run(XAResourceRecoveryImpl.java:261)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getSubject(XAResourceRecoveryImpl.java:260)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:165)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (JBJCA-1225) Timers should be canceled upon shutdown
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1225:
--------------------------------------
Summary: Timers should be canceled upon shutdown
Key: JBJCA-1225
URL: https://issues.jboss.org/browse/JBJCA-1225
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0.CR1, 1.1.8.Final, 1.0.28.Final
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.0.Final
Let the BootstrapContext keep track of the timers, and call cancel() and purge()
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-95:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1079106|https://bugzilla.redhat.com/show_bug.cgi?id=1079106] from POST to MODIFIED
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
> Key: LOGMGR-95
> URL: https://issues.jboss.org/browse/LOGMGR-95
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Livingston
> Assignee: James Perkins
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
> Logger.getLogger("a");
> Logger.getLogger("a.b.c");
> Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-146) Cleanup/fix IPV6 testsuite
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-146?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky updated WFCORE-146:
-------------------------------------
Priority: Blocker (was: Major)
This is a blocker for the CLI because its tests can't be included into the core testsuite. I am postponing work on some of the CLI issues until this is resolved.
> Cleanup/fix IPV6 testsuite
> --------------------------
>
> Key: WFCORE-146
> URL: https://issues.jboss.org/browse/WFCORE-146
> Project: WildFly Core
> Issue Type: Task
> Affects Versions: 1.0.0.Alpha8
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 1.0.0.Alpha9
>
>
> CLI testsuite cannot be ported over to Core as we have problems with IPV6 testsuite.
> Testsuite configuration for ipv6 should be unified and simplified to make all this work in core and in full without extra params to build
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-145) CLI run-batch command cannot process files with comments or blank lines
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-145?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFCORE-145:
------------------------------------------
To be able to run the testsuite we need WFCORE-146 fixed.
> CLI run-batch command cannot process files with comments or blank lines
> -----------------------------------------------------------------------
>
> Key: WFCORE-145
> URL: https://issues.jboss.org/browse/WFCORE-145
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.Alpha8
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> In the JBoss CLI tool, the "run-batch --file=script.cli" command cannot
> successfully process lines that start with "#" or blank lines. Comments and
> blank lines help readability when creating cli batch scripts.
> However, running the batch file containing comments/blank lines as a parameter
> to jboss-cli.sh works just fine (./jboss-cli.sh -c --file=script.cli). This
> difference in accepted syntax creates some confusion for users who are new to
> the CLI tool.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years