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

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)