[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=13021369#comment-13021369 ] 

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

Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm
There are two issues:
  - configuration of SASL/ENCRYPT via existing security realm XML elements
  - accessing the configured security realm data from the associated services for injection into ENCRYPT

existing security realm configuration
---------------------------------------------
Relevant to this discussion, the security realm contains the following XML configuration elements:
<server-identities>
 <ssl/>
 <secret/>
</server-identities>
<authentication>
  <users/>
  <local/>
  <ldap/>
  <properties/>
  <jaas/>
  <truststore/>
</authentication>
<authorization>
 <properties/>
</authorization>  
where::
- the <ssl/> element is designed for setting up key material for an SSLContext for incoming remote connections
- the <truststore/> element is designed for setting up key material for SSL two way authentication

configuration: JGroups SASL layer
--------------------------------------------
The existing SASL integration (in JDG) makes use of the configuration in <authorization/>. 
The JGroups SASL layer supports these mechanisms:
SASL mechanism -> SecurityRealm mechanism -> CallbackHandler
PLAIN 	       -> PLAIN			  -> PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler
DIGEST_MD5     -> DIGEST		  -> PropertiesCallbackHandler, UserDomainCallbackHandler
GSSAPI	       -> PLAIN
EXTERNAL       -> CLIENT_CERT             -> ClientCertCallbackHandler
where:
- mechanism determines the way in which user data is handled/encoded between client and server
- callback handler determines how the user data is actually obtained  

So, for example:
- if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the <properties/> or <users/> elements with user information
- if we want to use the PLAIN mechanism, we should populate the <properties/>, <ldap/>, <jaas/> or <users/> elements with user information 

In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs.

configuration: JGroups ENCRYPT layer
--------------------------------------------------
The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use:
- symmetric encryption: a keystore for storing a single secret key
- asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment)

As we need a keystore for ENCRYPT usage, should we:
- reuse the <ssl> element for this purpose? 
- create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. <cluster-ssl>

reuse <ssl/> option
------------------------
If we did reuse the <ssl/> element, we would need to cater to the situation where:
- need to provide SSL two way authentication for incoming connections (using both the <ssl/> and the <truststore/> elements) and 
- need to use the <ssl/> keystore to additionally store secret keys, public keys and private keys for ENCRYPT 
This could be achieved by:
- sharing a single <ssl/> element between the incoming connections requiring SSL and JGroups peers joining a group
- always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the <ssl/> element for both cases   

Some small problems:
1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the <ssl/> attribute provider="JCEKS".

2. The other problem here is that access to the service representing the keystore is not intended for public consumption.
The <ssl/> element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore.  Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do.

use <cluster-ssl/> option
-------------------------------
If we create a new element of <server-identities/> to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT.    

Reuse of the <ssl/> element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity.


> 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.8#6338)