[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-363:
------------------------------------
Fix Version/s: 3.0.0.Alpha15
(was: 3.0.0.Alpha14)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha15
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1802:
-------------------------------------
Fix Version/s: 3.0.0.Alpha15
(was: 3.0.0.Alpha14)
> Integrate OpenSSL Provider registration with Elytron
> ----------------------------------------------------
>
> Key: WFCORE-1802
> URL: https://issues.jboss.org/browse/WFCORE-1802
> Project: WildFly Core
> Issue Type: Task
> Reporter: Stuart Douglas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha15
>
>
> We need to remove the following block from SecurityRealmResourceDefinition: -
> {code}
> static {
> //register the Openssl Provider, if possible
> //not really sure if this is the best place for it
> try {
> OpenSSLProvider.register();
> DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider();
> } catch (Throwable t){
> DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider");
> }
> }
> {code}
> Registration will then be possible within the Elytron subsystem configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 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.Alpha15
(was: 3.0.0.Alpha14)
> 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.Alpha15
>
>
> 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.3#72005)
9 years, 5 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.Alpha15
(was: 3.0.0.Alpha14)
> 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.Alpha15
>
>
> 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.3#72005)
9 years, 5 months
[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.Alpha15
(was: 3.0.0.Alpha14)
> 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.Alpha15
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # 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
(v7.2.3#72005)
9 years, 5 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.Alpha15
(was: 3.0.0.Alpha14)
> 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.Alpha15
>
>
> 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.3#72005)
9 years, 5 months