July 2016 - jboss-jira - Jboss List Archives

[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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > 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 (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1400) Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1400?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1400: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1400 > URL: https://issues.jboss.org/browse/WFCORE-1400 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha4 > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1489: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha4 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1438) Elytron integration with logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1438: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Elytron integration with logging subsystem > ------------------------------------------ > > Key: WFCORE-1438 > URL: https://issues.jboss.org/browse/WFCORE-1438 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha4 > > > This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1429) Add property to skip LogManager check at startup

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1429?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1429: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Add property to skip LogManager check at startup > ------------------------------------------------ > > Key: WFCORE-1429 > URL: https://issues.jboss.org/browse/WFCORE-1429 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Dominique Broeglin > Assignee: James Perkins > Priority: Minor > Fix For: 3.0.0.Alpha4 > > > At startup, Wildfly checks that the default log manager (as returned by {{java.util.logging.LogManager.getLogManager()}} ) is {{org.jboss.logmanager.LogManager}}: > https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java... > This breaks some cases where the LogManager is wrapped because of the needs of that particular JVM like in OSv ( https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main... ). > As suggested on the mailing list, I would like to propose adding a property to bypass that check. Something along the lines of "jboss.logging.logManagerCheck = false/true" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1547) Integrate CredentialStore into Core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1547?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1547: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Integrate CredentialStore into Core > ----------------------------------- > > Key: WFCORE-1547 > URL: https://issues.jboss.org/browse/WFCORE-1547 > Project: WildFly Core > Issue Type: Sub-task > Components: Security > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 3.0.0.Alpha4 > > > Create necessary API for integrating Elytron CredentialStore API into WildFly Core. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > > 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 (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1515) Improve PersistentResourceDefinition to make it easier to register attribute write handlers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1515?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1515: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Improve PersistentResourceDefinition to make it easier to register attribute write handlers > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1515 > URL: https://issues.jboss.org/browse/WFCORE-1515 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha4 > > > Currently if you want to take register custom write handler you need to override whole registerAttributes methods and do it yourself all the way. > We could add PersistentResourceDefinition.getAttributeHandlers() method that returns > a Map<String, OperationStepHandler>. > And then registerAttributes uses the map instead of hardcoding ReloadRequiredWriteAttributeHandler. Default impl just fills the map values with > ReloadRequiredWriteAttributeHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1600) Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1600?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1600: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances. > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1600 > URL: https://issues.jboss.org/browse/WFCORE-1600 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha4 > > > These are for use when security realms are directly referenced, although Elytron types these should not be advertised as capabilities as these are for specific backwards compatibility requirements and not to increase their use as Elytron capabilities. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016