September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBEE-143) JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name

by Stefan Guilhen (JIRA)

Stefan Guilhen created JBEE-143: ----------------------------------- Summary: JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name Key: JBEE-143 URL: https://issues.jboss.org/browse/JBEE-143 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jacc-api Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: JavaEE Spec APIs 3.0.3.Final As reported by [~jcacek]: JACC 1.1 specification, chapter 3.1.3.1 Translating security-constraint Elements says: {panel} A WebResourcePermission and a WebUserDataPermission must be added to the unchecked policy statements for each url-pattern in the deployment descriptor and the default pattern, "/", that is not combined by the web- resource-collection elements of the deployment descriptor with every HTTP method value. The permission objects must be constructed using the *qualified pattern* as their name and with actions represented by an HTTP method exception list that identifies (as defined in “HTTP Method Exception List”) all the HTTP methods that do not occur in combination with the pattern.The resulting permissions must be added to the unchecked policy statements by calling the addToUncheckedPolicy method on the PolicyConfiguration object. {panel} but the class WarJaccService doesn't use qualified patterns (around line 170 in source code): {code} String excludedString = "!" + getCommaSeparatedString(httpMethods); WebResourcePermission wrp1 = new WebResourcePermission(info.pattern, excludedString); WebUserDataPermission wudp1 = new WebUserDataPermission(info.pattern, excludedString); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-142) JACC permissions with HTTP method exception list are not correctly implemented

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.s... ] Stefan Guilhen updated JBEE-142: -------------------------------- Fix Version/s: JavaEE Spec APIs 3.0.3.Final > JACC permissions with HTTP method exception list are not correctly implemented > ------------------------------------------------------------------------------- > > Key: JBEE-142 > URL: https://issues.jboss.org/browse/JBEE-142 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jacc-api > Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: JavaEE Spec APIs 3.0.3.Final > > > As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification. > There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling > {code} > Object[] methodInfo = WebResourcePermission.canonicalMethods(actions); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-142) JACC permissions with HTTP method exception list are not correctly implemented

by Stefan Guilhen (JIRA)

Stefan Guilhen created JBEE-142: ----------------------------------- Summary: JACC permissions with HTTP method exception list are not correctly implemented Key: JBEE-142 URL: https://issues.jboss.org/browse/JBEE-142 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jacc-api Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final Reporter: Stefan Guilhen Assignee: Stefan Guilhen As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification. There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling {code} Object[] methodInfo = WebResourcePermission.canonicalMethods(actions); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1916) Deployer role within domain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1916: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012592 > Deployer role within domain > --------------------------- > > Key: WFLY-1916 > URL: https://issues.jboss.org/browse/WFLY-1916 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.Beta1 > > > There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to: > a) /server-group=* > b) /deployment=* > But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1916) Deployer role within domain

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-1916: ------------------------------ Comment: was deleted (was: Is this still an issue?) > Deployer role within domain > --------------------------- > > Key: WFLY-1916 > URL: https://issues.jboss.org/browse/WFLY-1916 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.Beta1 > > > There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to: > a) /server-group=* > b) /deployment=* > But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1592) Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1592: ---------------------------------------- [~rob.stryker] Is this still an issue for you? I thought this was new but looking at the history it is a few months old and your linked Jira has been closed. > Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1592 > URL: https://issues.jboss.org/browse/WFLY-1592 > Project: WildFly > Issue Type: Bug > Components: Remoting, Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Rob Stryker > Assignee: Darran Lofthouse > Fix For: 8.0.0.Beta1 > > > Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials. This is most easily replicated as follows: > 1) On remote machine start wildfly alpha1 or alpha2 > 2) on local machine, cd eap-6.1/bin > 3) on local machine: > [rob@rawbdor bin]$ ./jboss-cli.sh > You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. > [disconnected /] connect myhost.net > Authenticating against security realm: ManagementRealm > Username: admin > Password: > Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed > This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2087) Administrator should be prevented from modifying super user and auditor roles.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2087: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from ASSIGNED to POST > Administrator should be prevented from modifying super user and auditor roles. > ------------------------------------------------------------------------------ > > Key: WFLY-2087 > URL: https://issues.jboss.org/browse/WFLY-2087 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged. > The administrator role should be prevented from modifying these two roles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2087) Administrator should be prevented from modifying super user and auditor roles.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2087: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from NEW to ASSIGNED > Administrator should be prevented from modifying super user and auditor roles. > ------------------------------------------------------------------------------ > > Key: WFLY-2087 > URL: https://issues.jboss.org/browse/WFLY-2087 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged. > The administrator role should be prevented from modifying these two roles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2087) Administrator should be prevented from modifying super user and auditor roles.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2087: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012579 > Administrator should be prevented from modifying super user and auditor roles. > ------------------------------------------------------------------------------ > > Key: WFLY-2087 > URL: https://issues.jboss.org/browse/WFLY-2087 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged. > The administrator role should be prevented from modifying these two roles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2166) servlet-connector uses socket-binding's host

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-2166: --------------------------------- Summary: servlet-connector uses socket-binding's host Key: WFLY-2166 URL: https://issues.jboss.org/browse/WFLY-2166 Project: WildFly Issue Type: Bug Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil The servlet-connector has socket-binding attribute that is used to determine the host & port of the HTTP server so that a client can connect to it. It determines the host by calling the SocketBinding's getDestinationAddress().getHostAddress() method. This may lead to issues if the HTTP server is behind a proxy as the servlet-connector will use the address of the HTTP server and bypass the proxy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 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 September 2013