[JBoss JIRA] (WFCORE-1658) JBEAP-2830 enhancements were not forward ported to upstream
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1658?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1658:
-------------------------------------
Fix Version/s: 3.0.0.Alpha4
(was: 2.2.0.CR9)
> JBEAP-2830 enhancements were not forward ported to upstream
> -----------------------------------------------------------
>
> Key: WFCORE-1658
> URL: https://issues.jboss.org/browse/WFCORE-1658
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Brian Stansberry
> Assignee: Dmitrii Tikhomirov
> Priority: Blocker
> Fix For: 3.0.0.Alpha4
>
>
> JBEAP-2830 includes changes to the logging subsystem's template.xml that EAP full relies upon. These were never forward ported to upstream, meaning that EAP builds can't consume core 2.2 or later.
> I believe there's no problem applying the changes. EAP will use one of the supplements while WildFly will not.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1658) JBEAP-2830 enhancements were not forward ported to upstream
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1658?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1658:
-------------------------------------
Fix Version/s: 2.2.0.CR9
(was: 2.2.0.CR8)
> JBEAP-2830 enhancements were not forward ported to upstream
> -----------------------------------------------------------
>
> Key: WFCORE-1658
> URL: https://issues.jboss.org/browse/WFCORE-1658
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Brian Stansberry
> Assignee: Dmitrii Tikhomirov
> Priority: Blocker
> Fix For: 2.2.0.CR9
>
>
> JBEAP-2830 includes changes to the logging subsystem's template.xml that EAP full relies upon. These were never forward ported to upstream, meaning that EAP builds can't consume core 2.2 or later.
> I believe there's no problem applying the changes. EAP will use one of the supplements while WildFly will not.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBASMP-84) Default packaging types links ejb projects to a mave-plugin project which is ignored by default
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-84?page=com.atlassian.jira.plugin.... ]
James Perkins moved WFMP-50 to JBASMP-84:
-----------------------------------------
Project: JBoss AS Maven Plugins (was: WildFly Maven Plugin)
Key: JBASMP-84 (was: WFMP-50)
Component/s: (was: Maven Plugin)
Fix Version/s: 7.9.Final
(was: 1.1.0.Alpha11)
> Default packaging types links ejb projects to a mave-plugin project which is ignored by default
> -----------------------------------------------------------------------------------------------
>
> Key: JBASMP-84
> URL: https://issues.jboss.org/browse/JBASMP-84
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 7.9.Final
>
>
> The {{org.wildfly.plugin.deployment.PackageType}} static mapping links the EJB packaging type to the {{MAVEN_PLUGIN}} type which by default is skipped for deployments. The proper type needs to be added to the map.
> {code:java}
> static {
> DEFAULT_TYPES = new HashMap<>();
> DEFAULT_TYPES.put(MAVEN_PLUGIN.packaging, MAVEN_PLUGIN);
> DEFAULT_TYPES.put(POM.packaging, MAVEN_PLUGIN);
> DEFAULT_TYPES.put(EJB.packaging, MAVEN_PLUGIN);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-5329 to WFLY-6863:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6863 (was: JBEAP-5329)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.GA)
(was: 7.0.1.CR1)
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6863
> URL: https://issues.jboss.org/browse/WFLY-6863
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ]
Radoslav Husar resolved WFLY-6863.
----------------------------------
Fix Version/s: 10.1.0.CR1
Resolution: Done
Resolved with mod_cluster 1.3.3.Final upgrade.
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6863
> URL: https://issues.jboss.org/browse/WFLY-6863
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.1.0.CR1
>
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6864) Subject not populated with groups/roles when authenticated via JASPIC
by James Perkins (JIRA)
James Perkins created WFLY-6864:
-----------------------------------
Summary: Subject not populated with groups/roles when authenticated via JASPIC
Key: WFLY-6864
URL: https://issues.jboss.org/browse/WFLY-6864
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.0.0.CR4
Reporter: Arjan t
Assignee: Darran Lofthouse
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)
9 years, 9 months
[JBoss JIRA] (WFLY-6864) Subject not populated with groups/roles when authenticated via JASPIC
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6864?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned WFLY-6864:
-----------------------------------
Assignee: James Perkins (was: Darran Lofthouse)
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-6864
> URL: https://issues.jboss.org/browse/WFLY-6864
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Arjan t
> Assignee: James Perkins
> 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)
9 years, 9 months
[JBoss JIRA] (WFLY-6726) Add help text about jboss.undefinded.host for the wsdl-host attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6726:
--------------------------------------
Fix Version/s: 10.1.0.CR1
Assignee: Claudio Miranda (was: Alessio Soldano)
Resolution: Done
> Add help text about jboss.undefinded.host for the wsdl-host attribute
> ---------------------------------------------------------------------
>
> Key: WFLY-6726
> URL: https://issues.jboss.org/browse/WFLY-6726
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: Claudio Miranda
> Assignee: Claudio Miranda
> Fix For: 10.1.0.CR1
>
>
> would be doable to add the text to the
> resource-description of wsdl-url, related to the use of
> jboss.undefined.host ?
> The path
> /deployment=*/subsystem=webservices/endpoint=*:read-resource-description
> I ask that because HAL consumes and exposes the resource-description
> of each attribute and having the help text about the
> jboss.undefined.host in wsdl-host also helps CLI users.
> A suggestion for the text:
> "Webservice endpoint WSDL URL. If wsdl-host is set to
> jbossws.undefined.host, Wildfly uses the requester's host when
> rewriting the <soap:address>"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months