[JBoss JIRA] (JGRP-1967) SASL protocol cannot handle MERGE requests properly
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1967?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1967:
---------------------------
Fix Version/s: 3.6.7
> SASL protocol cannot handle MERGE requests properly
> ---------------------------------------------------
>
> Key: JGRP-1967
> URL: https://issues.jboss.org/browse/JGRP-1967
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 3.6.7
>
>
> The SASL merge authentication fails because the merge leader is asked to merge with itself.
> 3741 [TRACE] SASL: B: received CHALLENGE from A
> 3744 [TRACE] SASL: B: sending RESPONSE to A
> 3744 [TRACE] SASL: A: received RESPONSE from B
> 3745 [TRACE] SASL: A: sending CHALLENGE to B
> 3745 [DEBUG] SASL: Authentication successful for user
> 3746 [TRACE] SASL: B: received CHALLENGE from A
> 3746 [TRACE] SASL: B: authentication complete from A
> A: [A|1] (2) [A, B]
> B: [A|1] (2) [A, B]
> A: [A|10] (1) [A]
> B: [B|10] (1) [B]
> 3823 [DEBUG] GMS: B: I will be the merge leader. Starting the merge task. Views: {A=[A|10] (1) [A], B=[B|10] (1) [B]}
> 3825 [DEBUG] GMS: B: merge task B::1 started with 2 participants
> 3825 [TRACE] GMS: B: sending MERGE_REQ to [B, A]
> 3826 [TRACE] SASL: B: received CHALLENGE from B
> 3829 [TRACE] GMS: B: queue is suspended; request LEAVE(B, false) is discarded
> 3827 [WARN] SASL: failed to validate CHALLENGE from B, token
> javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Missing username.
> at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:417) ~[?:1.7.0_85]
> at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:244) ~[?:1.7.0_85]
> at org.jgroups.auth.sasl.SaslServerContext.nextMessage(SaslServerContext.java:73) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:810) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) [classes/:?]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:295) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) [classes/:?]
> at org.jgroups.protocols.TP$3.run(TP.java:1511) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [?:1.7.0_85]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [?:1.7.0_85]
> at java.lang.Thread.run(Thread.java:745) [?:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (JGRP-1967) SASL protocol cannot handle MERGE requests properly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/JGRP-1967?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned JGRP-1967:
-------------------------------------
Assignee: Tristan Tarrant (was: Bela Ban)
> SASL protocol cannot handle MERGE requests properly
> ---------------------------------------------------
>
> Key: JGRP-1967
> URL: https://issues.jboss.org/browse/JGRP-1967
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
>
> The SASL merge authentication fails because the merge leader is asked to merge with itself.
> 3741 [TRACE] SASL: B: received CHALLENGE from A
> 3744 [TRACE] SASL: B: sending RESPONSE to A
> 3744 [TRACE] SASL: A: received RESPONSE from B
> 3745 [TRACE] SASL: A: sending CHALLENGE to B
> 3745 [DEBUG] SASL: Authentication successful for user
> 3746 [TRACE] SASL: B: received CHALLENGE from A
> 3746 [TRACE] SASL: B: authentication complete from A
> A: [A|1] (2) [A, B]
> B: [A|1] (2) [A, B]
> A: [A|10] (1) [A]
> B: [B|10] (1) [B]
> 3823 [DEBUG] GMS: B: I will be the merge leader. Starting the merge task. Views: {A=[A|10] (1) [A], B=[B|10] (1) [B]}
> 3825 [DEBUG] GMS: B: merge task B::1 started with 2 participants
> 3825 [TRACE] GMS: B: sending MERGE_REQ to [B, A]
> 3826 [TRACE] SASL: B: received CHALLENGE from B
> 3829 [TRACE] GMS: B: queue is suspended; request LEAVE(B, false) is discarded
> 3827 [WARN] SASL: failed to validate CHALLENGE from B, token
> javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Missing username.
> at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:417) ~[?:1.7.0_85]
> at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:244) ~[?:1.7.0_85]
> at org.jgroups.auth.sasl.SaslServerContext.nextMessage(SaslServerContext.java:73) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:810) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) [classes/:?]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:295) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) [classes/:?]
> at org.jgroups.protocols.TP$3.run(TP.java:1511) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [?:1.7.0_85]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [?:1.7.0_85]
> at java.lang.Thread.run(Thread.java:745) [?:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (JGRP-1967) SASL protocol cannot handle MERGE requests properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1967?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1967:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1267599|https://bugzilla.redhat.com/show_bug.cgi?id=1267599] from NEW to ASSIGNED
> SASL protocol cannot handle MERGE requests properly
> ---------------------------------------------------
>
> Key: JGRP-1967
> URL: https://issues.jboss.org/browse/JGRP-1967
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Tristan Tarrant
> Assignee: Bela Ban
>
> The SASL merge authentication fails because the merge leader is asked to merge with itself.
> 3741 [TRACE] SASL: B: received CHALLENGE from A
> 3744 [TRACE] SASL: B: sending RESPONSE to A
> 3744 [TRACE] SASL: A: received RESPONSE from B
> 3745 [TRACE] SASL: A: sending CHALLENGE to B
> 3745 [DEBUG] SASL: Authentication successful for user
> 3746 [TRACE] SASL: B: received CHALLENGE from A
> 3746 [TRACE] SASL: B: authentication complete from A
> A: [A|1] (2) [A, B]
> B: [A|1] (2) [A, B]
> A: [A|10] (1) [A]
> B: [B|10] (1) [B]
> 3823 [DEBUG] GMS: B: I will be the merge leader. Starting the merge task. Views: {A=[A|10] (1) [A], B=[B|10] (1) [B]}
> 3825 [DEBUG] GMS: B: merge task B::1 started with 2 participants
> 3825 [TRACE] GMS: B: sending MERGE_REQ to [B, A]
> 3826 [TRACE] SASL: B: received CHALLENGE from B
> 3829 [TRACE] GMS: B: queue is suspended; request LEAVE(B, false) is discarded
> 3827 [WARN] SASL: failed to validate CHALLENGE from B, token
> javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Missing username.
> at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:417) ~[?:1.7.0_85]
> at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:244) ~[?:1.7.0_85]
> at org.jgroups.auth.sasl.SaslServerContext.nextMessage(SaslServerContext.java:73) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:810) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) [classes/:?]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:295) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) [classes/:?]
> at org.jgroups.protocols.TP$3.run(TP.java:1511) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [?:1.7.0_85]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [?:1.7.0_85]
> at java.lang.Thread.run(Thread.java:745) [?:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (JGRP-1967) SASL protocol cannot handle MERGE requests properly
by Tristan Tarrant (JIRA)
Tristan Tarrant created JGRP-1967:
-------------------------------------
Summary: SASL protocol cannot handle MERGE requests properly
Key: JGRP-1967
URL: https://issues.jboss.org/browse/JGRP-1967
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.6
Reporter: Tristan Tarrant
Assignee: Bela Ban
The SASL merge authentication fails because the merge leader is asked to merge with itself.
3741 [TRACE] SASL: B: received CHALLENGE from A
3744 [TRACE] SASL: B: sending RESPONSE to A
3744 [TRACE] SASL: A: received RESPONSE from B
3745 [TRACE] SASL: A: sending CHALLENGE to B
3745 [DEBUG] SASL: Authentication successful for user
3746 [TRACE] SASL: B: received CHALLENGE from A
3746 [TRACE] SASL: B: authentication complete from A
A: [A|1] (2) [A, B]
B: [A|1] (2) [A, B]
A: [A|10] (1) [A]
B: [B|10] (1) [B]
3823 [DEBUG] GMS: B: I will be the merge leader. Starting the merge task. Views: {A=[A|10] (1) [A], B=[B|10] (1) [B]}
3825 [DEBUG] GMS: B: merge task B::1 started with 2 participants
3825 [TRACE] GMS: B: sending MERGE_REQ to [B, A]
3826 [TRACE] SASL: B: received CHALLENGE from B
3829 [TRACE] GMS: B: queue is suspended; request LEAVE(B, false) is discarded
3827 [WARN] SASL: failed to validate CHALLENGE from B, token
javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Missing username.
at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:417) ~[?:1.7.0_85]
at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:244) ~[?:1.7.0_85]
at org.jgroups.auth.sasl.SaslServerContext.nextMessage(SaslServerContext.java:73) ~[classes/:?]
at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:810) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) [classes/:?]
at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) [classes/:?]
at org.jgroups.protocols.Discovery.up(Discovery.java:295) [classes/:?]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) [classes/:?]
at org.jgroups.protocols.TP$3.run(TP.java:1511) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [?:1.7.0_85]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [?:1.7.0_85]
at java.lang.Thread.run(Thread.java:745) [?:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5476) Load balancer garbles path parameters in URL
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-5476:
-------------------------------------
Summary: Load balancer garbles path parameters in URL
Key: WFLY-5476
URL: https://issues.jboss.org/browse/WFLY-5476
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.CR2, 9.0.1.Final
Reporter: Harald Wellmann
Assignee: Stuart Douglas
Using WildFly as mod-cluster load balancer, any path parameters in URLs reach the backend servers with incorrect URL encoding, e.g.
{noformat}
/one;a=b%3Bc%3Dd%2Ftwo%3Be%3Df%3Bg%3Dh
{noformat}
See UNDERTOW-555.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-995) Add possibility to enable debug mode by setting environment variable in standalone scripts
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-995?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-995:
----------------------------------
Assignee: James Perkins (was: Tomaz Cerar)
> Add possibility to enable debug mode by setting environment variable in standalone scripts
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-995
> URL: https://issues.jboss.org/browse/WFCORE-995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Scripts
> Reporter: Tomaz Cerar
> Assignee: James Perkins
>
> It's common practice in Docker to control image run by configuring environment variables.
> E.g.
> {code:bash}
> docker run -e POSTGRES_PASSWORD=mysecretpassword -d postgres
> {code}
> The Cloud Enablement team adds such a possibility to EAP docker images. They [replaces|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-d...] initial value of {{DEBUG_MODE}}:
> {code:bash}
> # Enhance standalone.sh to make remote JAVA debugging possible by specifying
> # DEBUG=true environment variable
> sed -i 's|DEBUG_MODE=false|DEBUG_MODE="${DEBUG:-false}"|' $JBOSS_HOME/bin/standalone.sh
> {code}
> It's not a clean solution. This change should be made in original scripts and not on a Dockerfile level.
> Please allow configuring the {{DEBUG_MODE}} from environment variables (in similar as e.g. the {{JAVA_OPTS}} are handled.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (ELY-311) Upgrade JMockit
by David Lloyd (JIRA)
David Lloyd created ELY-311:
-------------------------------
Summary: Upgrade JMockit
Key: ELY-311
URL: https://issues.jboss.org/browse/ELY-311
Project: WildFly Elytron
Issue Type: Task
Reporter: David Lloyd
The current version of JMockit screws up stack traces. Update to at least 1.19.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5132) Authorization does not work correctly for remoting EJB when kerberos is only authentication module in security realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5132?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-5132:
-----------------------------------
Fix Version/s: 10.0.0.Final
> Authorization does not work correctly for remoting EJB when kerberos is only authentication module in security realm
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5132
> URL: https://issues.jboss.org/browse/WFLY-5132
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Final
>
>
> Authorization does not work correctly for remoting secured EJB when Kerberos is only authentication module in security realm. If any another authentication module is used, then authorization works fine. Access is also granted when nonsecured EJB is used.
> Use following settings:
> - only kerberos as authentication module in security realm
> - properties as authorization module in security realm which adds kerberos user needed role
> - secured EJB deployed on server (grant access for mentioned above role)
> - standalone application invoking this secured EJB method
> In case when user with valid kerberos ticket runs this application, following exception is thrown:
> {noformat}
> javax.ejb.EJBAccessException: WFLYSEC0027: Invalid User
> at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:69)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:49)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5131) Kerberos authentication for remoting EJB without interaction does not fallback correctly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5131?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-5131:
-----------------------------------
Fix Version/s: 10.0.0.Final
> Kerberos authentication for remoting EJB without interaction does not fallback correctly
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-5131
> URL: https://issues.jboss.org/browse/WFLY-5131
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Final
>
>
> In case when kerberos authentication with properties fallback is correctly configured in security realm and user without correct kerberos ticket tries to invoke EJB via EJB client, then EJB client asks for kerberos username in interactive mode. It works correctly when user interacts with this mode but it causes inconvenience for access without user interaction. Fallback cannot be taken into account because EJB invocation stucks in interactive mode which leads to RuntimeException: Operation failed with status WAITING. There should be any possibility how to disable interactive mode for users which invoke EJB without kerberos.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months