[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by Ladislav Petera (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
Ladislav Petera commented on WFLY-4618:
---------------------------------------
[~atijms] you are absolutely right... thanks a lot for the quick and detailled answer, this solves my problem
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2056:
---------------------------
Description:
Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
* message bundlers at the sender and
* message batch handling at the receiver
This needs to be done for both requests and responses.
Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
was:
Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
* message bundlers at the sender and
* message batch handling at the receiver
This needs to be done for both requests and responses
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2056:
--------------------------------
Comment from Sanne:
I would also like to experiment with:
- thread priorities
- kernel settings optimised for latency
- try a different (kernel) scheduler
- pin threads which are on the "critical path" to dedicated CPU cores
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
arjan tijms edited comment on WFLY-4618 at 4/22/16 7:15 PM:
------------------------------------------------------------
{quote}arjan tijms have you run into this issue with your JASPIC tests?{quote}
I think the issue here is that there's a confusion between whether authentication for the current request is mandatory, and whether the authentication module itself is mandatory.
>From the issue's description I'm pretty sure the former is meant. The proposed solution mentioned by Stuart is correct, but for completeness; this property has to be checked on the Map contained within the {{MessageInfo}} parameter that's passed in the {{validateRequest}} method. The following shows an example:
{code:java}
Boolean.valueOf((String) messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory"));
{code}
This works correctly in all versions of WildFly.
Per request authentication is mandatory when the resource is secured (i.e. matches a security constraint) OR when {{HttpServletRequest#authenticate}} has been called for that request. There's no problem in {{JASPIAuthenticationMechanism}} (now {{JASPICAuthenticationMechanism}}). It's explicitly specified in the JASPIC spec that an authentication module is always called for every request, whether the resource is secured or non-secured and whether the caller has been authenticated before within the same http session or not.
Now the {{MessagePolicy}} is a different thing entirely. This could be used when for instance multiple authentication modules are used, which are managed by the authentication context ({{ServerAuthContext}}). The intend was here that this would function kinda like we see in PAM and JAAS, where multiple modules can be configured with REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL.
*edit*: reading the spec again, I'm actually not so sure about {{MessagePolicy#isMandatory}} anymore, but I am sure about the {{MessageInfo}} variant being able to be used and working in all servers that I tested to far. I'll contact the spec lead for clarification
Unfortunately, the way how multiple modules would exactly have to work together was never specified. JASPIC 1.0 put up some base infrastructure for it, but this was never really followed up on, leaving the implementation details up to the server. The spec lead explains this in some more detail here: https://java.net/jira/browse/JASPIC_SPEC-15
In practice, I haven't seen {{MessagePolicy}} used a lot.
Long story short, use the {{MessageInfo}} for the property Stuart mentioned and not the method on {{MessagePolicy}}.
was (Author: atijms):
{quote}arjan tijms have you run into this issue with your JASPIC tests?{quote}
I think the issue here is that there's a confusion between whether authentication for the current request is mandatory, and whether the authentication module itself is mandatory.
>From the issue's description I'm pretty sure the former is meant. The proposed solution mentioned by Stuart is correct, but for completeness; this property has to be checked on the Map contained within the {{MessageInfo}} parameter that's passed in the {{validateRequest}} method. The following shows an example:
{code:java}
Boolean.valueOf((String) messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory"));
{code}
This works correctly in all versions of WildFly.
Per request authentication is mandatory when the resource is secured (i.e. matches a security constraint) OR when {{HttpServletRequest#authenticate}} has been called for that request. There's no problem in {{JASPIAuthenticationMechanism}} (now {{JASPICAuthenticationMechanism}}). It's explicitly specified in the JASPIC spec that an authentication module is always called for every request, whether the resource is secured or non-secured and whether the caller has been authenticated before within the same http session or not.
Now the {{MessagePolicy}} is a different thing entirely. This could be used when for instance multiple authentication modules are used, which are managed by the authentication context ({{ServerAuthContext}}). The intend was here that this would function kinda like we see in PAM and JAAS, where multiple modules can be configured with REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL.
Unfortunately, the way how multiple modules would exactly have to work together was never specified. JASPIC 1.0 put up some base infrastructure for it, but this was never really followed up on, leaving the implementation details up to the server. The spec lead explains this in some more detail here: https://java.net/jira/browse/JASPIC_SPEC-15
In practice, I haven't seen {{MessagePolicy}} used a lot.
Long story short, use the {{MessageInfo}} for the property Stuart mentioned and not the method on {{MessagePolicy}}.
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-4618:
-----------------------------------
{quote}Each ServerAuthContext obtained through getAuthContext must initialize its encapsulated ServerAuthModule objects with a non-null value for requestPolicy{quote}
This part is indeed technically not implemented correctly in WildFly. I had in my notes somewhere to one day add some tests for this, but since the {{MessagePolicy}} is almost never used I didn't look at this yet.
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-4618:
-----------------------------------
{quote}arjan tijms have you run into this issue with your JASPIC tests?{quote}
I think the issue here is that there's a confusion between whether authentication for the current request is mandatory, and whether the authentication module itself is mandatory.
>From the issue's description I'm pretty sure the former is meant. The proposed solution mentioned by Stuart is correct, but for completeness; this property has to be checked on the Map contained within the {{MessageInfo}} parameter that's passed in the {{validateRequest}} method. The following shows an example:
{code:java}
Boolean.valueOf((String) messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory"));
{code}
This works correctly in all versions of WildFly.
Per request authentication is mandatory when the resource is secured (i.e. matches a security constraint) OR when {{HttpServletRequest#authenticate}} has been called for that request. There's no problem in {{JASPIAuthenticationMechanism}} (now {{JASPICAuthenticationMechanism}}). It's explicitly specified in the JASPIC spec that an authentication module is always called for every request, whether the resource is secured or non-secured and whether the caller has been authenticated before within the same http session or not.
Now the {{MessagePolicy}} is a different thing entirely. This could be used when for instance multiple authentication modules are used, which are managed by the authentication context ({{ServerAuthContext}}). The intend was here that this would function kinda like we see in PAM and JAAS, where multiple modules can be configured with REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL.
Unfortunately, the way how multiple modules would exactly have to work together was never specified. JASPIC 1.0 put up some base infrastructure for it, but this was never really followed up on, leaving the implementation details up to the server. The spec lead explains this in some more detail here: https://java.net/jira/browse/JASPIC_SPEC-15
In practice, I haven't seen {{MessagePolicy}} used a lot.
Long story short, use the {{MessageInfo}} for the property Stuart mentioned and not the method on {{MessagePolicy}}.
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-105) Option to have LoggingToolsProcessor to not use javax.annotation.Generated
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-105?page=com.atlassian.jira.plugi... ]
Sanne Grinovero commented on LOGTOOL-105:
-----------------------------------------
As an alternative to enabling this switch, I've found that adding the dependency explicitly also works fine.
For example in a Maven build I can add them as dependencies to the annotation processor:
{code:xml}
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>2.2.4</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.jboss.logging.processor.apt.LoggingToolsProcessor</processor>
</processors>
<compilerArguments>-AskipGeneratedAnnotation=false -AtranslationFilesPath=${project.basedir}/src/main/resources/ -source 1.7 -target 1.7</compilerArguments>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-processor</artifactId>
<version>${jbossLoggingProcessorVersion}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>jsr250-api</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</plugin>{code}
> Option to have LoggingToolsProcessor to not use javax.annotation.Generated
> --------------------------------------------------------------------------
>
> Key: LOGTOOL-105
> URL: https://issues.jboss.org/browse/LOGTOOL-105
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Fix For: 2.1.0.Alpha1
>
>
> To allow projects using the JBoss Logging annotation processor to test latest Java 9 Jigsaw builds, we need to be able to workaround issue
> https://bugs.openjdk.java.net/browse/JDK-8152842
> I'm introducing an annotation processor option which will cause the generated source code to "forget" to mark the generated code with {{javax.annotation.Generated}}.
> -{{AskipGeneratedAnnotation=true}}
> The JMH annotation processor followed a similar path:
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901643
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4618:
--------------------------------------
You can check this in the validateRequest method call, but I think you are right that this is not implemented correctly. From the spec:
{code}
Each ServerAuthContext obtained through getAuthContext must initialize its encapsulated ServerAuthModule objects with a non-null value for requestPolicy. The encapsulated authentication modules may be initialized with a null value for responsePolicy.
{code}
[~atijms] have you run into this issue with your JASPIC tests?
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6550) Invalid use of ModuleIdentifier.create(String) for dynamic names prevents use of slots
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6550?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6550:
-----------------------------------
Component/s: JCA
JMS
Security
Security Manager
Web (Undertow)
> Invalid use of ModuleIdentifier.create(String) for dynamic names prevents use of slots
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6550
> URL: https://issues.jboss.org/browse/WFLY-6550
> Project: WildFly
> Issue Type: Bug
> Components: JCA, JMS, Security, Security Manager, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The ModuleIdentifier.create(String) method is a convenience method for creating an id with a slot of "main". Using this method for user-provided module names prevents the user from encoding a slot into their string. Better is to use ModuleIdentifier.fromString(String) which will parse out a slot if present.
> WFCORE-1499 is due to this problem; reviewing the PR for it led me to investigate core and full for other occurrences. Found a few.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years