[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC
by István Tóth (JIRA)
[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-5739:
-----------------------------------
I have sent a PR that fixes this:
https://github.com/picketbox/picketbox/pull/62
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-5739
> URL: https://issues.jboss.org/browse/WFLY-5739
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR4
> Reporter: Arjan t
> Assignee: Darran Lofthouse
> Labels: jacc, jaspic
>
> After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
> For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
> {code:java}
> Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
>
> boolean hasAccess = Policy.getPolicy().implies(
> new ProtectionDomain(
> new CodeSource(null, (Certificate[]) null),
> null, null,
> subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
> ),
> new WebResourcePermission("/protected/Servlet", "GET"))
> ;
> {code}
> As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
> This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
> {code:java}
> String[] rolesArray = groupPrincipalCallback.getGroups();
> int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
>
> if( sizeOfRoles > 0 )
> {
> List<Role> rolesList = new ArrayList<Role>();
> for( int i = 0; i < sizeOfRoles ; i++ )
> {
> Role role = new SimpleRole( rolesArray[ i ] );
> rolesList.add( role );
> }
> RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
> // if the current security context already has roles, we merge them with the incoming roles.
> RoleGroup currentRoles = currentSC.getUtil().getRoles();
> // *** ROLES ARE ONLY SET HERE ***
> if (currentRoles != null) {
> currentRoles.addAll(roles.getRoles());
> }
> else {
> currentSC.getUtil().setRoles( roles );
> }
> }
> // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
> // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
> Subject subject = groupPrincipalCallback.getSubject();
> if( subject != null )
> {
> // if the current security context already has an associated subject, we merge it with the incoming subject.
> Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
> if (currentSubject != null) {
> subject.getPrincipals().addAll(currentSubject.getPrincipals());
> subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
> subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
> }
> currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-6200:
-------------------------------
I think [~mvera31] is saying that before this issue gets fixed, the {{connection_url}} is mandatory. After this issue gets fixed, it is not mandatory any longer. ;)
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6671.
----------------------------------
Resolution: Cannot Reproduce Bug
I could not reproduce this
> ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6671
> URL: https://issues.jboss.org/browse/WFLY-6671
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
> Reporter: river shen
> Assignee: Stuart Douglas
> Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
>
>
> When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
> if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
> It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
> We have attached a minimal web application that reproduce this issue.
> Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 months