[JBoss JIRA] (WFCORE-2633) Allow specification of "non-sensitive" values on an AttributeDefinition
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2633:
----------------------------------------
Summary: Allow specification of "non-sensitive" values on an AttributeDefinition
Key: WFCORE-2633
URL: https://issues.jboss.org/browse/WFCORE-2633
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management, Security
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Beta14
The RBAC system requires the user to be in a role with permissions to perform "security sensitive" actions in order to manipulate "defined" attributes with a sensitivity constraint applied. And "defined" in this case includes attributes that are not explicitly configured by the user but which have default values. But for attributes without default values that are left undefined, the non-sensitive roles are allowed to perform that action.
The requirement here is to open this up such that certain "defined" values (explicitly configured or default) also are treated as non-sensitive.
See WFCORE-8521 for an explicit example of this. If the datasource subsystem "elytron-enabled" attribute has a value of "false", and other related attributes are left undefined, that basically means there is no configuration set up for how the DS should authenticate to the DB. Such a setup is likely useless (since the DB most likely requires authentication) but in and of itself doesn't involve anything security sensitive on the WildFly side, so configuring false shouldn't be sensitive. It's analogous to leaving other related attributes like "username" and "password" undefined which in previous releases was considered to be non-sensitive.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8521) RBAC user with Maintainer role is not any more able to create datasource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8521?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved JBEAP-10176 to WFLY-8521:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8521 (was: JBEAP-10176)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
Security
(was: Domain Management)
(was: JCA)
(was: Security)
Affects Version/s: (was: 7.1.0.DR12)
Affects Testing: (was: Regression)
> RBAC user with Maintainer role is not any more able to create datasource
> ------------------------------------------------------------------------
>
> Key: WFLY-8521
> URL: https://issues.jboss.org/browse/WFLY-8521
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Security
> Reporter: Pavel Jelinek
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: authorization, domain-management, rbac
>
> User gets
> {code}
> Unknown error
> Authentication required.
> {code}
> This is regression compared to EAP 7.0.0.GA.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2559) caching-realm with ldap-realm cannot be added when LDAP is unreachable
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2559?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski reassigned WFCORE-2559:
------------------------------------------
Assignee: Bartosz Baranowski (was: Darran Lofthouse)
> caching-realm with ldap-realm cannot be added when LDAP is unreachable
> ----------------------------------------------------------------------
>
> Key: WFCORE-2559
> URL: https://issues.jboss.org/browse/WFCORE-2559
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta9
> Reporter: Ondrej Lukas
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> In case when caching-realm is used together with ldap-realm and LDAP server (which is used by that ldap-realm) is unreachable, then caching-realm cannot be added.
> This issue also causes that this realm service is not correctly started when server is started. It means that in case when LDAP server is unreachable during starting application server, then this realm will not work until it will be reloaded again and LDAP will be reachable.
> Following exception occurs for CLI command:
> {code}
> /subsystem=elytron/caching-realm=some-cache-realm:add(realm=some-ldap-realm)
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> Caused by: java.net.ConnectException: Connection refused"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"]
> },
> "rolled-back" => true
> }
> {code}
> Following exception occurs in server log when mentioned above CLI command is executed:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.some-cache-realm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:153)
> at org.wildfly.security.auth.realm.CachingSecurityRealm.<init>(CachingSecurityRealm.java:60)
> at org.wildfly.security.auth.realm.CachingModifiableSecurityRealm.<init>(CachingModifiableSecurityRealm.java:53)
> at org.wildfly.extension.elytron.CachingRealmDefinition$RealmAddHandler.lambda$createService$0(CachingRealmDefinition.java:143)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:187)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:149)
> ... 9 more
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:442)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:356)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:227)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:462)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:185)
> ... 10 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 32 more
> 09:26:07,954 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("caching-realm" => "some-cache-realm")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> Caused by: java.net.ConnectException: Connection refused"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8520) Exclude journal type MAPPED from allowed journal type values
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8520?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-10172 to WFLY-8520:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8520 (was: JBEAP-10172)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR12)
(was: 7.1.0.DR13)
(was: 7.1.0.DR14)
> Exclude journal type MAPPED from allowed journal type values
> ------------------------------------------------------------
>
> Key: WFLY-8520
> URL: https://issues.jboss.org/browse/WFLY-8520
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
>
> CLI shows value {{MAPPED}} as allowed for parameter {{journal-type}}.
> {code}
> /subsystem=messaging-activemq/server=default:read-resource-description
> {code}
> {panel}
> "journal-type" => {
> "type" => STRING,
> "description" => "The type of journal to use.",
> "attribute-group" => "journal",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => "ASYNCIO",
> "allowed" => [
> "NIO",
> "ASYNCIO",
> {color:#d04437}"MAPPED"{color}
> ],
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> {panel}
> This feature is not supported. Choosing journal type MAPPED results in following exception
> {code}
> 14:26:10,232 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 73) AMQ224000: Failure in initialisation: java.lang.IllegalArgumentException: AMQ119051: Invalid journal type MAPPED
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:140) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.<init>(AbstractJournalStorageManager.java:216) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.<init>(JournalStorageManager.java:104) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:1863) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2000) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:62) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:520) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:469) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:412) [artemis-jms-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-15.jar:7.1.0.Alpha1-redhat-15]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-15.jar:7.1.0.Alpha1-redhat-15]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-15.jar:7.1.0.Alpha1-redhat-15]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_65]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_65]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final-redhat-1.jar:2.2.1.Final-redhat-1]
> {code}
> From user experience point of view, this MAPPED should be excluded from allowed values for attribute {{journal-type}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HAWKULARQE-84) Adjust Timelines to new widgetastic
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created HAWKULARQE-84:
----------------------------------------
Summary: Adjust Timelines to new widgetastic
Key: HAWKULARQE-84
URL: https://issues.jboss.org/browse/HAWKULARQE-84
Project: Hawkular QE
Issue Type: Task
Reporter: Hayk Hovsepyan
Assignee: Hayk Hovsepyan
Currently Timelines are disabled because of UI changes.
But now CFME QE team did some adjustments, and we need to reuse them in our test_provider_timelines.py
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months