[JBoss JIRA] (WFCORE-916) Kerberos authentication into Management Console does not fallback correctly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-916?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-916:
------------------------------------
Fix Version/s: 2.0.0.CR7
> Kerberos authentication into Management Console does not fallback correctly
> ----------------------------------------------------------------------------
>
> Key: WFCORE-916
> URL: https://issues.jboss.org/browse/WFCORE-916
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 2.0.0.CR7
>
>
> Fallback management realm is not taken into account for Kerberos authentication into Management Console. In cases when Kerberos authentication to Management Console is configured also with fallback mechanism (properties, security-domain...) and one of:
> - realm in principal is not set correctly
> - path to keytab is not set correctly
> is set in EAP configuration and when user with valid kerberos ticket tries to access Management Console then fallback is not taken into account and user cant access management console.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (JBLOGGING-118) Subclass of java.util.logging.Level creates PermGen memory leak
by Murmur Murmur (JIRA)
Murmur Murmur created JBLOGGING-118:
---------------------------------------
Summary: Subclass of java.util.logging.Level creates PermGen memory leak
Key: JBLOGGING-118
URL: https://issues.jboss.org/browse/JBLOGGING-118
Project: JBoss Logging
Issue Type: Bug
Components: jboss-logging-jdk
Affects Versions: 3.3.0.Beta1
Environment: JDK7, Tomcat 7, OpenJPA-2.4.1, ValidationAPI-1.x, hibernate-validator-5.2.1, jboss-logging (fresh from github).
Reporter: Murmur Murmur
Assignee: James Perkins
Subclass of java.util.logging.Level creates PermGen memory leak if webapp provides jboss-logging.jar inside a webapp. This happen most likely in Tomcat and hot-redeployment stops working after few times out of PermGen memory.
It's a commonly known side effect of JDK logging library, projects should not inherit Level class.
See this discussion and github pull request where I have fixed this problem.
http://stackoverflow.com/a/32412984/185565
https://github.com/jboss-logging/jboss-logging/pull/21
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-5473:
--------------------------------
Steps to Reproduce:
- two servers with non-distributable application (requires FORM authentication, user added) and <single-sign-on/> set up
- create a few requests to both servers, you'll be required to authenticate for the first request
- you should now have at least two sessions with the same SSO context
- invalidate one of those sessions by calling session.invalidate()
- what happens: another request to either of the servers won't require you to authenticate
- what's expected: you should be required to authenticate again (SSO context should be destroyed) - this happens when the application is <distributable/>
> Session.invalidate() does not invalidate SSO context for non-distributable applications
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5473
> URL: https://issues.jboss.org/browse/WFLY-5473
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See "Steps to Reproduce" for detailed description.
> According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
> Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Richard Janík (JIRA)
Richard Janík created WFLY-5473:
-----------------------------------
Summary: Session.invalidate() does not invalidate SSO context for non-distributable applications
Key: WFLY-5473
URL: https://issues.jboss.org/browse/WFLY-5473
Project: WildFly
Issue Type: Bug
Components: Web (Undertow), Clustering
Reporter: Richard Janík
Assignee: Stuart Douglas
Priority: Blocker
See "Steps to Reproduce" for detailed description.
According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFCORE-916) Kerberos authentication into Management Console does not fallback correctly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-916?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-916:
-----------------------------------------
I will have a look and see if we can add some additional validation for the bad configuration, however in general these are not scenarios that fallback is supposed to be used for.
Fallback works by sending two simultaneous challenges to the client, one is SPNEGO and the other is either a HTTP Digest or HTTP Basic challenge - if the web browser is configured to support Kerberos it will use it, if not the browser decides to fallback to Digest / Basic. Fallback is not a server side capability if the server subsequently discovers it is incorrectly configured.
> Kerberos authentication into Management Console does not fallback correctly
> ----------------------------------------------------------------------------
>
> Key: WFCORE-916
> URL: https://issues.jboss.org/browse/WFCORE-916
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Fallback management realm is not taken into account for Kerberos authentication into Management Console. In cases when Kerberos authentication to Management Console is configured also with fallback mechanism (properties, security-domain...) and one of:
> - realm in principal is not set correctly
> - path to keytab is not set correctly
> is set in EAP configuration and when user with valid kerberos ticket tries to access Management Console then fallback is not taken into account and user cant access management console.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-271:
--------------------------------------
Technically this is as a result of a mechanism accidentally getting on the classpath, once we have further integration we will need to cross check some of these scenarios.
> EJB authentication via Kerberos does not work with wildfly-security-api
> -----------------------------------------------------------------------
>
> Key: ELY-271
> URL: https://issues.jboss.org/browse/ELY-271
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.0.0.Alpha3
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Fix For: 1.1.0.Beta1
>
> Attachments: client.zip, server.jar
>
>
> EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
> at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550)
> at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at client.Client.main(Client.java:19)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78)
> ... 18 more
> {noformat}
> Note:
> Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-271:
---------------------------------
Fix Version/s: 1.1.0.Beta1
> EJB authentication via Kerberos does not work with wildfly-security-api
> -----------------------------------------------------------------------
>
> Key: ELY-271
> URL: https://issues.jboss.org/browse/ELY-271
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.0.0.Alpha3
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Fix For: 1.1.0.Beta1
>
> Attachments: client.zip, server.jar
>
>
> EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
> at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550)
> at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at client.Client.main(Client.java:19)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78)
> ... 18 more
> {noformat}
> Note:
> Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-271:
---------------------------------
Priority: Minor (was: Major)
> EJB authentication via Kerberos does not work with wildfly-security-api
> -----------------------------------------------------------------------
>
> Key: ELY-271
> URL: https://issues.jboss.org/browse/ELY-271
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.0.0.Alpha3
> Reporter: Ondrej Lukas
> Priority: Minor
> Fix For: 1.1.0.Beta1
>
> Attachments: client.zip, server.jar
>
>
> EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
> at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550)
> at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at client.Client.main(Client.java:19)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78)
> ... 18 more
> {noformat}
> Note:
> Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-271:
------------------------------------
Assignee: Darran Lofthouse
> EJB authentication via Kerberos does not work with wildfly-security-api
> -----------------------------------------------------------------------
>
> Key: ELY-271
> URL: https://issues.jboss.org/browse/ELY-271
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.0.0.Alpha3
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Fix For: 1.1.0.Beta1
>
> Attachments: client.zip, server.jar
>
>
> EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
> at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550)
> at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at client.Client.main(Client.java:19)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78)
> ... 18 more
> {noformat}
> Note:
> Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months