[JBoss JIRA] (WFLY-12291) SaslException: Authentication failed when XA Recovery tries to call remote server
by Flavia Rainone (Jira)
Flavia Rainone created WFLY-12291:
-------------------------------------
Summary: SaslException: Authentication failed when XA Recovery tries to call remote server
Key: WFLY-12291
URL: https://issues.jboss.org/browse/WFLY-12291
Project: WildFly
Issue Type: Bug
Components: Remoting
Reporter: Flavia Rainone
Assignee: Flavia Rainone
This is caused by how the current AuthenticationContext is captured when wildfly-transaction-client tries to do transaction recovery. It essentially calls ElytronXmlParser.parseAuthenticationClientConfiguration(), which calls org.wildfly.client.config.ClientConfiguration#getInstance(), which only looks for wildfly-config in various locations.
Also see DefaultAuthenticationContextProvider
{code}
13:30:06,851 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.2.GA (WildFly Core 6.0.14.Final-redhat-00001) started in 3798ms - Started 308 of 528 services (319 services are lazy, passive or on-demand)
13:30:46,524 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:201)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:203)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:199)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:622)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:214)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:159)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:444)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
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:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:587)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:553)
at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:82)
at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:55)
at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:499)
at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:445)
at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:52)
at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
... 8 more
13:31:16,537 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:726)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:507)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:258)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-11504) Some hibernate tests fail with security on IBM Java 8: HHH000142
by Gail Badner (Jira)
[ https://issues.jboss.org/browse/WFLY-11504?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-11504:
------------------------------------
[~okotek], I believe this was fixed in 5.3.10. Can this be resolved?
> Some hibernate tests fail with security on IBM Java 8: HHH000142
> ----------------------------------------------------------------
>
> Key: WFLY-11504
> URL: https://issues.jboss.org/browse/WFLY-11504
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Affects Versions: 16.0.0.Beta1
> Environment: IBM Java 8, build 8.0.5.25 or 8.0.5.26
> Reporter: Ondrej Kotek
> Assignee: Gail Badner
> Priority: Major
> Attachments: org.jboss.as.test.integration.jpa.hibernate.entitytest.EntityTestCase-output.txt
>
>
> Seven hibernate tests fail with security on IBM Java 8, for example:
> {noformat}
> org.hibernate.HibernateException: HHH000142: Bytecode enhancement failed: org.jboss.as.test.integration.jpa.hibernate.Employee
> {noformat}
> Affected test cases:
> * {{org.jboss.as.test.integration.jpa.hibernate.entitytest.EntityTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverOnetoManyJoinColumnTest}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.basicenverstest.BasicEnversTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.basicselectiveenverstest.BasicSelectiveEnversTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.implementvalidityauditstrategytest.ImplementValidityAuditStrategyTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.validityauditstrategyoninheritancetest.ValidityAuditStrategyonInheritanceTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.sessionfactorytest.SessionFactoryTestCase}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.
by David Guthrie (Jira)
[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ]
David Guthrie commented on ELY-1525:
------------------------------------
This solution is focused on Keycloak.
> When SSO is enabled, multipart form and form enconding stop working.
> --------------------------------------------------------------------
>
> Key: ELY-1525
> URL: https://issues.jboss.org/browse/ELY-1525
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.6.Final, 1.2.1.Final
> Reporter: Estevão Freitas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.10.0.CR4
>
> Attachments: 0001-ELY-1525-Initialize-FormParserFactory-with-FormEncod.patch, ely-1515-reproducer.zip
>
>
> I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ".
> I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On .
> When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working.
> If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1687:
----------------------------
Fix Version/s: 1.10.0.CR4
(was: 1.10.0.CR3)
> Initial WildFly Elytron Performance Enhancments
> -----------------------------------------------
>
> Key: ELY-1687
> URL: https://issues.jboss.org/browse/ELY-1687
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.7.0.CR2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.10.0.CR4
>
> Attachments: BASIC_Auth_Load.jmx, Flight.tgz
>
>
> Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
> After that we will perform the initial metric test again and close the issue.
> A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
> The first test is to test HTTP Basic authentication backed by WildFly Elytron.
> * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
> Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
> h2. Initial Issues
> h3. WildFlyElytronProvider Locking
> Total block time 8.393s via calls to java.security.Provider.getServices();
> Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
> h3. Memory 2.42G of char[]
> e.g.
> {noformat}
> void java.nio.HeapCharBuffer.<init>(int, int) 13037
> CharBuffer java.nio.CharBuffer.allocate(int) 9148
> CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
> CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
> {noformat}
> Is there any option to re-use these as they can be cleared instead of leaving to GC.
> HeapByteBuffer and HeapCharBuffer are also quite prominent.
> h3. Memory 1.78G of Callback[]
> Using the CallbackHandler API the use of the array is inevitable.
> * Could we extend the API to avoid the array?
> * Could we re-use the array? Could consider null termination.
> {noformat}
> boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
> {noformat}
> h3. Memory 1.41G of HttpAuthenticator$Builder
> {noformat}
> HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
> boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
> {noformat}
> Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
> h3. Memory 1.3G of SecurityContextImpl
> {noformat}
> SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
> SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
> {noformat}
> Also instances of HttpAuthenticator
> {noformat}
> HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
> {noformat}
> And instances of HttpAuthenticator$AuthenticationExchange.
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
> {noformat}
> As with HttpAuthenticator$Builder is there any way to consider re-use?
> h3. Memory 1.21G of java.util.ArrayList
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
> {noformat}
> Can check the use and see if an alternative is possible.
> _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
> _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
> https://issues.jboss.org/browse/ELY-1689
> h3. Memory ServerAuthenticationContext States
> Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
> Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
> h3. Memory SecurityIdentity
> As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
> {noformat}
> SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
> ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
> {noformat}
> h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
> These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
> Could a static Base64 conversion clean up a lot of this?
> h1. Done
> h3. Method Profiling - new HttpString
> A lot of time spend creating new HttpString (Package is no3 in the top list)
> {noformat}
> void io.undertow.util.HttpString.<init>(String) 4
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
> {noformat}
> Could we re-use the HttpString for common header types?
> Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
> h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
> {noformat}
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
> {noformat}
> This test did not use forms at all, is this something that can be delayed until we know it is needed?
> _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
> https://issues.jboss.org/browse/ELYWEB-27
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years