April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFCORE-13: ------------------------------ Fix Version/s: (was: 3.0.0.Beta15) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8546) Server does not fail to start when there is an error in Artemis server

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8546?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-10235 to WFLY-8546: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8546 (was: JBEAP-10235) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: (was: 7.1.0.DR16) > Server does not fail to start when there is an error in Artemis server > ---------------------------------------------------------------------- > > Key: WFLY-8546 > URL: https://issues.jboss.org/browse/WFLY-8546 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > When there is an error that prevents an embedded Artemis server to start, the messaging-activemq subsystem only logs the error. > Instead, it should throw a StartException to prevent the app server to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1043) CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1043?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1043: ------------------------------ Description: CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore. was: CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore. It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. > CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore > ---------------------------------------------------------------------------------------------- > > Key: ELY-1043 > URL: https://issues.jboss.org/browse/ELY-1043 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Blocker > > CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1044) CS tool has to support bulk conversion of vaults to credential stores.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1044?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1044: ------------------------------ Description: CS tool has to support bulk conversion of vaults to credential stores. was: CS tool has to support bulk conversion of vaults to credential stores. It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. > CS tool has to support bulk conversion of vaults to credential stores. > ---------------------------------------------------------------------- > > Key: ELY-1044 > URL: https://issues.jboss.org/browse/ELY-1044 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Blocker > > CS tool has to support bulk conversion of vaults to credential stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8545) CS tool has to have own sh script

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8545?page=com.atlassian.jira.plugin.... ] Darran Lofthouse moved ELY-1068 to WFLY-8545: --------------------------------------------- Project: WildFly (was: WildFly Elytron) Key: WFLY-8545 (was: ELY-1068) Component/s: Security (was: Credential Store) > CS tool has to have own sh script > --------------------------------- > > Key: WFLY-8545 > URL: https://issues.jboss.org/browse/WFLY-8545 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > CS tool has to have own sh script -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ] Ondrej Lukas commented on WFCORE-2615: -------------------------------------- [~dmlloyd] Thanks for clarification. We still think that optimal solution is provide this feature as white-list. Other solutions can lead to confusions and also can mean more effort. In case we decide to leave the current behavior in application server then we should consider renaming allow-sasl-mechanisms to something more descriptive. Instead of meaning "allow mechanisms" it should mean something like "try this mechanism even if configuration does not include all needed attributes for this mechanism". Moreover if current behavior will be part of application server then we have to provide more clear documentation in management model (for JBoss CLI read operation) and XSD. I agree with: _"... the lack of an allowed set seems to mean all-allowed to some people and none-allowed to other people ..."_ but in case when "allow-all" is provided and "forbid-all" does not exist then I think it indirectly implies that lack of allowed set means none-allowed (otherwise "allow-all" is useless). We should consider whether "forbid-all" would be useful - in combination with "allow-sasl-mechanisms" it provides simple way how to enable only specific SASL mechanism. I understand that choosing of mechanism can be improved and there are not boundaries "how" to improve it (e.g. as you said, exclude mechanisms that use certain crypto primitives can be this improvement), but I think then providing "forbid-all" could really help during configuration. [~dlofthouse] could you please share your point of view on this issue? > Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration > ---------------------------------------------------------------------------------- > > Key: WFCORE-2615 > URL: https://issues.jboss.org/browse/WFCORE-2615 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta10 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: dep.war, wireshark.pcapng > > > In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms. > See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce". > This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client. > We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1068) CS tool has to have own sh script

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1068?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1068: ---------------------------------- Description: CS tool has to have own sh script was: CS tool has to have own sh script It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. > CS tool has to have own sh script > --------------------------------- > > Key: ELY-1068 > URL: https://issues.jboss.org/browse/ELY-1068 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > CS tool has to have own sh script -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1068) CS tool has to have own sh script

by Hynek Švábek (JIRA)

Hynek Švábek created ELY-1068: --------------------------------- Summary: CS tool has to have own sh script Key: ELY-1068 URL: https://issues.jboss.org/browse/ELY-1068 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek Švábek Assignee: Darran Lofthouse CS tool has to have own sh script It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1068) CS tool has to have own sh script

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1068?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1068: ------------------------------ Component/s: Credential Store > CS tool has to have own sh script > --------------------------------- > > Key: ELY-1068 > URL: https://issues.jboss.org/browse/ELY-1068 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > CS tool has to have own sh script > It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2646) Elytron, management interface, legacy authentication is "checked" even if Elytron authentication is configured

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2646?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-8544 to WFCORE-2646: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2646 (was: WFLY-8544) Component/s: Security (was: Security) > Elytron, management interface, legacy authentication is "checked" even if Elytron authentication is configured > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2646 > URL: https://issues.jboss.org/browse/WFCORE-2646 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > Regression against DR15. > Authentication by legacy security realm is taken in account even if just Elytron authentication should be used. I don't say legacy authentication is used in priority before Elytron (that works as expected). Just that legacy authentication is somehow "initialized". In this case check "There are no user in mngmt-user.properties file" is performed > Reproducer: > * Configure Elytron authentication for management interface > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password( clear={password="password123"}) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper) > /subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-fs-http-auth) > {code} > * impossible to acces management interface > {code} > curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se... > { > "outcome" : "failed", > "failure-description" : "WFLYDMHTTP0006: The security realm is not ready to process requests, see http://localhost.localdomain:9990/error", > "rolled-back" : "true" > } > {code} > Acces is granted once > * security realm is undefined from management interface > {code} > /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) > {code} > * User is added into ManagementRealm > {code} > ./add-user.sh -u admin -p admin -r ManagementRealm > {code} > {code} > curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se... > "running" > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2017