[JBoss JIRA] (WFLY-6434) System property 'org.jboss.as.security.jacc-module' not always used
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6434?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6434:
--------------------------------------
Assignee: Winfried Wasser (was: Darran Lofthouse)
Resolution: Done
> System property 'org.jboss.as.security.jacc-module' not always used
> -------------------------------------------------------------------
>
> Key: WFLY-6434
> URL: https://issues.jboss.org/browse/WFLY-6434
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Final
> Reporter: Winfried Wasser
> Assignee: Winfried Wasser
> Fix For: 10.1.0.Final
>
> Attachments: security.patch
>
>
> JaccService of security subsystem does not use the system property 'org.jboss.as.security.jacc-module' for class loader.
> Due to this "not using", the custom JACC module is not used.
> This property was introduced by WFLY-5340
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2021) ENCRYPT: prevent messages from non-members
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2021:
-----------------------------------------------
Pavel Polischouk <pavelp(a)redhat.com> changed the Status of [bug 1313589|https://bugzilla.redhat.com/show_bug.cgi?id=1313589] from NEW to CLOSED
> ENCRYPT: prevent messages from non-members
> ------------------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> * ALTERNATIVE I:
> ** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
> ** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
> ** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
> * ALTERNATIVE II: digital signature
> ** The sender creates a hash from the message (digest) and encrypts the digest with its secret key, and ships it with the message
> ** The receiver decrypts the digest, computes the digest from the message and drops the message if the digests don't match
> ** The diff to the first alternative is that a receiver doesn't even need to deliver the message and stop at (failing) de-serialization.
> ** Downside: additional work to be done and space used when sending the signature with every message
> h3. Scenarios to test (ENCRYPTTest)
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> * R could still resend the _captured message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> h5. Non-member R sending a message encrypted with its own secret key
> * Cluster members would receive that message and decrypt it with their own (different) shared key, leading to garbage in the payload
> * The message would get delivered to the application but de-serialization would fail as the payload is garbage
> ** See ALTERNATIVE above to prevent cluster members from delivering messages from rogue members in the first place
> h4. Properties
> * Rogue non-member R
> * Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
> * Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
> * Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
> * Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
> h4. Issues
> * How do we handle (unicast) JOINs from non-members?
> * Ditto for merge requests (unicasts)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6102) Removing of non-existent mapping-module finishes with outcome success
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6102?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-6102.
------------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Done
WFCORE-1523 fixes this.
> Removing of non-existent mapping-module finishes with outcome success
> ---------------------------------------------------------------------
>
> Key: WFLY-6102
> URL: https://issues.jboss.org/browse/WFLY-6102
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Fedor Gavrilov
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> In case when non-existent mapping-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6793) Batch subsystem cannot be removed with a remove operation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6793?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-6793:
--------------------------------
Fix Version/s: 10.1.0.Final
> Batch subsystem cannot be removed with a remove operation
> ---------------------------------------------------------
>
> Key: WFLY-6793
> URL: https://issues.jboss.org/browse/WFLY-6793
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 10.1.0.Final
>
>
> The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked.
> {code}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration",
> "rolled-back" => true,
> "response-headers" => undefined
> }
> {code}
> -The batch configuration dependency needs to be removed before the its dependencies are removed.-
> -The thread-pool resource should also require a reload before removal.- The thread-pool is used in deployments and therefore shouldn't just be removed without a reload if there are deployments using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6811) Provide ability to start/stop Resource Adapter creation/deletion without restart of server
by Van Halbert (JIRA)
Van Halbert created WFLY-6811:
---------------------------------
Summary: Provide ability to start/stop Resource Adapter creation/deletion without restart of server
Key: WFLY-6811
URL: https://issues.jboss.org/browse/WFLY-6811
Project: WildFly
Issue Type: Enhancement
Components: JCA
Affects Versions: 9.0.0.Final, 10.0.0.Final
Reporter: Ramesh Reddy
Assignee: Stefano Maestri
Currently in WF 10, when a resource adapter is created / deleted using the CLI the "reload-status" is set to "requires restart", based how the resource is expected to be managed in WF. We need ability *avoid* the restart of the server
h3. Why We need it?
In Teiid, it is common practice to add/remove resource adapters dynamically and restarting server will affect performance and usability severely.
* Because delete/re-add is in Teiid's workflow to manage a resource adapters and when we have to restart we loose the whole state of the virtual database. That means we need re-establish runtime status. For example, all the existing sessions will be killed.
* Runtime environment are often shared, that could kill other person's tasks in flight leaving them hanging with errors.
* Every time resource adapter starts we fetch metadata from the source, this is very expensive operation.
* With multi-source feature, it is a feature that user dynamically brings in/out sources as they show up on their dashboard, it would be not possible to support this feature.
* This is a change of behavior from earlier versions of the EAP, our users and customers rely on this feature
As per Teiid project is concerned, we consider this is regression on WF and thus a bug.
h3. Proposed Solution
[~brian.stansberry] suggested the WF management practices here in this document https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Apply...
Based on this the conclusion is that resource adapters, is developed under "all-services" paradigm, not under "resource-services" paradigm, where a explicit header from client to whether to restart or not can avoid having to "reload" the server when a new RA is added or removed. We understand the nature of service dependencies in WF, and how this can affect the other dependent services, but we verified that Teiid will not have those side effects as we designed. Since these sources are effectively exclusively defined for Teiid should not interfere with others. Also, since the request is explicit, should not affect current behavior.
h3. Workarounds Considered
Teiid currently deploy the RAR files in module format (due to product requirements) if allowed this can be changed to deploy .rar files, which is suggested as alternative. This does require lot of code changes and not approved path. Aslo, only half solution as WFLY-6773 we would still need.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6810) Provide ability to start/stop Data Source creation without restart of server
by Van Halbert (JIRA)
Van Halbert created WFLY-6810:
---------------------------------
Summary: Provide ability to start/stop Data Source creation without restart of server
Key: WFLY-6810
URL: https://issues.jboss.org/browse/WFLY-6810
Project: WildFly
Issue Type: Enhancement
Components: JCA
Affects Versions: 10.0.0.Final
Reporter: Ramesh Reddy
Assignee: Stefano Maestri
Currently in WF 10, where a data source is created / removed using the CLI the "reload-status" is set to "requires restart", based how the resource is expected to be managed in WF.
h3. Why We need it?
In Teiid, it is common practice to add/remove data sources dynamically and restarting server will affect performance and usability severely.
* Because delete/re-add is in Teiid's workflow to manage a data sources and when we have to restart we loose the whole state of the virtual database. That means we need re-establish runtime status. For example, all the existing sessions will be killed.
* Runtime environment are often shared, that could kill other person's tasks in flight leaving them hanging with errors.
* Every time data source starts we fetch metadata from the source, this is very expensive operation.
* With multi-source feature, it is a feature that user dynamically brings in/out sources as they show up on their dashboard, it would be not possible to support this feature.
* This is a change of behavior from earlier versions of the EAP, our users and customers rely on this feature
As per Teiid project is concerned, we consider this is regression on WF and thus a bug.
h3. Proposed Solution
[~brian.stansberry] suggested the WF management practices here in this document https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Apply...
Based on this the conclusion is that Data Sources, is developed under "all-services" paradigm, not under "resource-services" paradigm, where a explicit header from client to whether to restart or not can avoid having to "reload" the server when a new DS is added or removed. We understand the nature of service dependencies in WF, and how this can affect the other dependent services, but we verified that Teiid will not have those side effects as we designed. Since these sources are effectively exclusively defined for Teiid should not interfere with others. Also, since the request is explicit, should not affect current behavior.
h3. Workarounds Considered
Since this highly dependent on configuration based data source creation, we can opt to a deployment based data source creation (-ds.xml), however GSS is quick to dismiss this as this not supported feature.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-6809?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-6809:
-----------------------------------------------
Affects Version/s: 10.0.0.Final
> Web authentication not treating "**" role constraint as expected
> ----------------------------------------------------------------
>
> Key: WFLY-6809
> URL: https://issues.jboss.org/browse/WFLY-6809
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
> Attachments: rolestest.war
>
>
> Servlet spec 3.1 states at point 13.3:
> ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.??
> But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403):
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
> version="3.1">
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>**</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> </login-config>
> </web-app>
> {code}
> With the following, and authenticating a user that has a role "**", the requested page is shown:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
> version="3.1">
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>**</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> </login-config>
> <security-role>
> <role-name>**</role-name>
> </security-role>
> </web-app>
> {code}
> Reproducer war is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-6809:
--------------------------------------------------
Summary: Web authentication not treating "**" role constraint as expected
Key: WFLY-6809
URL: https://issues.jboss.org/browse/WFLY-6809
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Guillermo González de Agüero
Assignee: Stuart Douglas
Attachments: rolestest.war
Servlet spec 3.1 states at point 13.3:
??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.??
But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403):
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>**</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app>
{code}
With the following, and authenticating a user that has a role "**", the requested page is shown:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>**</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<role-name>**</role-name>
</security-role>
</web-app>
{code}
Reproducer war is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1639?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1639:
------------------------------------------
I did also question on today's call if this could be solved by somehow executing all MODEL stage operations and only a subset of the RUNTIME operations - in retrospect I realise that will still leave us with the same problem as the subsystem supplied capabilities will not be available as the management interfaces come up.
> Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1639
> URL: https://issues.jboss.org/browse/WFCORE-1639
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha4
>
>
> I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
> https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9...
> I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
> To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
> We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
> This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
> Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months