[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
[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
[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
[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
[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
[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
[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
[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
[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