[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1145:
-------------------------------------
Fix Version/s: 3.0.0.Alpha12
(was: 3.0.0.Alpha11)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha12
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 2 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1282:
-------------------------------------
Fix Version/s: 3.0.0.Alpha12
(was: 3.0.0.Alpha11)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha12
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 2 months
[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1533:
-------------------------------------
Fix Version/s: 3.0.0.Alpha12
(was: 3.0.0.Alpha11)
> Integrate Management Access Control permission assignment with Elytron
> ----------------------------------------------------------------------
>
> Key: WFCORE-1533
> URL: https://issues.jboss.org/browse/WFCORE-1533
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha12
>
>
> A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role.
> Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection.
> This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron.
> After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based.
> _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 2 months
[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1598:
-------------------------------------
Fix Version/s: 3.0.0.Alpha12
(was: 3.0.0.Alpha11)
> Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1598
> URL: https://issues.jboss.org/browse/WFCORE-1598
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha12
>
>
> In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request.
> For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 2 months
[JBoss JIRA] (WFCORE-1891) Split WildFly Elytron into two modules with a public / private split.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1891?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1891:
-------------------------------------
Fix Version/s: 3.0.0.Alpha12
(was: 3.0.0.Alpha11)
> Split WildFly Elytron into two modules with a public / private split.
> ---------------------------------------------------------------------
>
> Key: WFCORE-1891
> URL: https://issues.jboss.org/browse/WFCORE-1891
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha12
>
>
> The Elytron jar will be contained within a private module, possibly 'elytron-private' then a module 'elytron' will depend on this and make the public packages visible.
> The following packages have been identified as being private: -
> org.wildfly.security._private
> org.wildfly.security.asn1
> org.wildfly.security.auth.realm
> org.wildfly.security.auth.realm.*
> org.wildfly.security.authz.jacc
> org.wildfly.security.credential.store.impl
> org.wildfly.security.security.digest
> org.wildfly.security.http.impl
> org.wildfly.security.security.keystore
> org.wildfly.security.mechanism.oauth2
> org.wildfly.security.mechanism.scram
> org.wildfly.security.password.impl
> org.wildfly.security.password.util
> org.wildfly.security.pem
> org.wildfly.security.sasl
> org.wildfly.security.sasl.* (Except util)
> org.wildfly.security.util
> org.wildfly.security.util_private
> org.wildfly.security.x500
> org.wildfly.security.x500.cert
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 2 months