September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7143: ---------------------------------------- [~honza889] Can you please look at options for a constant permission mapper? I think the LoginPermission does need to be defined in the configuration as there could be cases where identities in a security domain should not be able to authenticate. > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7143: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6924) driver-module-name not writable through the cli

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-6924?page=com.atlassian.jira.plugin.... ] Stefano Maestri resolved WFLY-6924. ----------------------------------- Resolution: Rejected > driver-module-name not writable through the cli > ----------------------------------------------- > > Key: WFLY-6924 > URL: https://issues.jboss.org/browse/WFLY-6924 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: trippstowe > Assignee: Stefano Maestri > Priority: Minor > > this used to work with previous versions > /subsystem=datasources/jdbc-driver=mysql/:write-attribute(name=driver-module-name,value=com.mysql.jdbc) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0048: Attribute driver-module-name is not writable", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7147) Standardize access to node1's address in the test suite

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-7147?page=com.atlassian.jira.plugin.... ] Jan Martiska moved JBEAP-6082 to WFLY-7147: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7147 (was: JBEAP-6082) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: 10.0.0.Final (was: 7.1.0.DR4) > Standardize access to node1's address in the test suite > ------------------------------------------------------- > > Key: WFLY-7147 > URL: https://issues.jboss.org/browse/WFLY-7147 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 10.0.0.Final > Reporter: Jan Martiska > Assignee: Jan Martiska > > Multinode tests in the TS which need to obtain the address of node1, do it in various non-standardized ways, it would be nice to standardize that. JBEAP-5998 added the possibility to obtain node1 address from {{TestSuiteEnvironment}} class, this issue will try to update the existing tests where it is appropriate. > In addition, let's fix {{ClusteredJPA2LCTestCase}} which currently fails when running with node1 set, because the test assumes it is always 127.0.0.1. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2640) Unable to add cached-connection-manager after removing it once

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-2640?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-2640: ------------------------------- I think the problem of this issue is that the {{:remove()}} and {{:add()}} operations should be disabled. > Unable to add cached-connection-manager after removing it once > -------------------------------------------------------------- > > Key: WFLY-2640 > URL: https://issues.jboss.org/browse/WFLY-2640 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Masafumi Miura > Assignee: Ingo Weiss > > {{<cached-connection-manager>}} is enabled in jca subsystem by default: > {code:xml} > <subsystem xmlns="urn:jboss:domain:jca:1.1"> > ... > <cached-connection-manager /> > </subsystem> > {code} > However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource. > {code} > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add > { > "outcome" => "failed", > "failure-description" => "JBAS014803: Duplicate resource [ > (\"subsystem\" => \"jca\"), > (\"cached-connection-manager\" => \"cached-connection-manager\") > ]", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7126) No log messages comming from Elytron

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7126?page=com.atlassian.jira.plugin.... ] Ingo Weiss reassigned WFLY-7126: -------------------------------- Assignee: Ingo Weiss (was: Darran Lofthouse) > No log messages comming from Elytron > ------------------------------------ > > Key: WFLY-7126 > URL: https://issues.jboss.org/browse/WFLY-7126 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7126) No log messages comming from Elytron

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7126?page=com.atlassian.jira.plugin.... ] Ingo Weiss commented on WFLY-7126: ---------------------------------- Got it. I will see what I can do here. > No log messages comming from Elytron > ------------------------------------ > > Key: WFLY-7126 > URL: https://issues.jboss.org/browse/WFLY-7126 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7146) Elytron, regex-name-validating-rewriter - 'match' attribute required and unclear description

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7146?page=com.atlassian.jira.plugin.... ] Jan Kalina moved JBEAP-6077 to WFLY-7146: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7146 (was: JBEAP-6077) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR4) > Elytron, regex-name-validating-rewriter - 'match' attribute required and unclear description > -------------------------------------------------------------------------------------------- > > Key: WFLY-7146 > URL: https://issues.jboss.org/browse/WFLY-7146 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Attribute 'match' is required when adding 'regex-name-validating-rewriter' although when reading the resource description via CLI, I can see that it has defined default value (true) and in [XSD file|https://github.com/wildfly-security/elytron-subsystem/blob/1.0.0.Alp...] it is not stated as a 'required'. Try: > {code} > /subsystem=elytron/regex-name-validating-rewriter=nameRewriter:add(pattern=".*") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0172: match is required", > "rolled-back" => true > } > {code} > When you try to add also with 'match' attribute then rewriter is added successfully. > Also - the 'match' attribute description in CLI is not quite clear: > {code} > /subsystem=elytron/regex-name-validating-rewriter=nameRewriter:read-resource-description > ... > "match" => { > "type" => BOOLEAN, > "description" => "Should names that match the pattern be rejected or names that don't", > "expressions-allowed" => true, > "nillable" => false, > "default" => true, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > ... > {code} > After reading the description I still don't know what happens when pattern matches the name and value of 'match' attribute is set to 'true' - will it be rejected or not? > Expected behaviour: > # 'match' attribute to be arbitrary (or change XSD so it is in sync with model) > # more clear description of 'match' attribute -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7145) Key-store atttribute read-only occures in xsd, but not in model

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7145?page=com.atlassian.jira.plugin.... ] Jan Kalina moved JBEAP-6074 to WFLY-7145: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7145 (was: JBEAP-6074) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Key-store atttribute read-only occures in xsd, but not in model > --------------------------------------------------------------- > > Key: WFLY-7145 > URL: https://issues.jboss.org/browse/WFLY-7145 > Project: WildFly > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There is a attribute {{read-only}} mentioned in XSD. > {code} > <xs:attribute name="read-only" type="xs:boolean" > use="optional" default="false"> > <xs:annotation> > <xs:documentation> > When set to 'true' this attribute prevents the in-memory > representation of the file from being written back to the file. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > But not in model. Therefore can't be used. Is that feature related to modifiable realms, which was deffered to 7.2? So probably should be removed from XSD? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ] Tomas Remes commented on WFLY-7140: ----------------------------------- There is test available at https://github.com/tremes/wildfly/tree/ejb_lookup_test > Injection with @EJB is not working as expected with CDI (REST) beans > -------------------------------------------------------------------- > > Key: WFLY-7140 > URL: https://issues.jboss.org/browse/WFLY-7140 > Project: WildFly > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. > @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") > is not working correct if used in a CDI Bean in the reproducer example. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 2016