[JBoss JIRA] (ELY-273) Expose RealmIdentity.getAttributes()
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-273?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on ELY-273:
--------------------------------
Verified that this is still necessary. The timeout info that’s needed in order to prevent multiple simultaneous authentication sessions for the OTP SASL mechanism is currently stored using a {{RealmIdentity}} attribute. Thus, the {{RealmIdentity#getAttributes}} method is needed to access this attribute for a given identity.
> Expose RealmIdentity.getAttributes()
> ------------------------------------
>
> Key: ELY-273
> URL: https://issues.jboss.org/browse/ELY-273
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 1.1.0.Beta6
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-535) Make use of realm events to handle password updates and resets for the OTP SASL mechanism
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-535?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on ELY-535:
--------------------------------
For handling OTP credential updates, my initial thought was that we’d be able to eliminate the {{CredentialUpdateCallback}} and just make use of a {{RealmAuthenticationEvent}} to update an OTP credential once authentication has completed. However, there doesn’t seem to be a good way for {{ServerAuthenticationContext}} to keep track of the actual credential that was used in an authentication in order to pass it to a {{RealmAuthenticationEvent}}. Thus, it seems to make more sense to add support for a new event that indicates a credential change for a realm identity and then handle a {{CredentialUpdateCallback}} by handling this new event.
> Make use of realm events to handle password updates and resets for the OTP SASL mechanism
> -----------------------------------------------------------------------------------------
>
> Key: ELY-535
> URL: https://issues.jboss.org/browse/ELY-535
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. The OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though).
> PR #277 [adds handling|https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/...] for a {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}. This is used to handle both the OTP sequence reset case as well as the non-reset case. Instead of manipulating the realm identity directly in the SAC callback handler, we should be able to make use of [realm events|https://github.com/wildfly-security/wildfly-elytron/pull/295] so that the realm itself can handle OTP updates and resets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-555) Adjust MechanismConfiguration to reference a single SecurityFactory<Credential>
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-555:
------------------------------------
Summary: Adjust MechanismConfiguration to reference a single SecurityFactory<Credential>
Key: ELY-555
URL: https://issues.jboss.org/browse/ELY-555
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
This configuration is already mechanism specific, ELY-554 will also make it server specific - by which point a reference to a single Factory will be sufficient.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6527) Cannot lookup RemoteConnectionFactory using https-remoting
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-6527?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-6527:
-------------------------------------
It is not possible, we are already behind our deadlines. I have migrated all remote ejb and jms code to using servlet interfaces. That seems to be the ONLY thing in WildFly that handles mutual 2 way SSL.
> Cannot lookup RemoteConnectionFactory using https-remoting
> ----------------------------------------------------------
>
> Key: WFLY-6527
> URL: https://issues.jboss.org/browse/WFLY-6527
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.0.0.Final
> Environment: RedHat Linux, Java 1.8
> Reporter: George Turner
> Assignee: David Lloyd
>
> I have successfully configured the system for two way ssl. I can connect to a topic from a standalone client, but I cannot connect with the same code from an EJB client using the following:
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> ctx = new InitialContext(props);
> ConnectionFactory cf = (ConnectionFactory) ctx.lookup("jms/RemoteConnectionFactory");
> It seems to "attach" the stateless bean to the first remote instance and then the second remote instance lookup fails. I have tried using the EJBClientContext properties (as used for EJB lookups) but no help. There is VERY little documentation about using https-remoting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-554) Server specific MechanismConfiguration
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-554:
------------------------------------
Summary: Server specific MechanismConfiguration
Key: ELY-554
URL: https://issues.jboss.org/browse/ELY-554
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
In addition to having a default MechanismConfiguration per mechanism we will also have server specific configurations.
We will also have a new ServerNameCallback callback for the mechanism to specify the server name - this will cause the ServerAuthenticationContext to swap out the current MechanismConfiguration with the server specific configuration.
MechanismConfiguration selection by server name will fall back to the default MechanismConfiguration if no server specific configuration is found.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf reopened WFLY-6561:
---------------------------------
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-6192:
-------------------------------------
It would need the following fix (see \[1\]) in order to let the deployment invoke {{JAXBContext.newInstance}} without explicit additional permissions. But then there is another security exception for {{unmarshaller.unmarshal}} invocation \[2\], see the stacktrace below, and I don't think we want to call \[3\] inside of {{doPrivileged}}.
I still believe the use-case from JAXBUsageServlet is fine with those two additional perms proposed in my PR.
\[1\] https://github.com/jboss/jboss-jaxb-api_spec/pull/4/commits/a2fe3493f06c9...
\[2\] https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
\[3\] https://github.com/jboss/jboss-jaxb-api_spec/blob/master/src/main/java/ja...
{noformat}
2016-05-31 15:13:07,890 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.Class.checkMemberAccess(Class.java:2348)
at java.lang.Class.getDeclaredConstructor(Class.java:2177)
at com.sun.xml.bind.v2.ClassFactory.create0(ClassFactory.java:104)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.createInstance(ClassBeanInfoImpl.java:285)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.createInstance(UnmarshallingContext.java:701)
at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.startElement(StructureLoader.java:186)
at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:60)
at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$IntercepterLoader.startElement(ElementBeanInfoImpl.java:253)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:576)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:555)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:168)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:283)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:733)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:258)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:229)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:136)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:183)
at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:181)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:178)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
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)
{noformat}
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (SECURITY-934) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-934?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-934.
---------------------------------------
Resolution: Done
> RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
> ---------------------------------------------------------------------------------------------
>
> Key: SECURITY-934
> URL: https://issues.jboss.org/browse/SECURITY-934
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Reporter: Hynek Švábek
> Assignee: Romain Pelisse
>
> There will be needless LDAP calls if we use AdvancedLdap login module.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
> It can be performance problem.
> Same problem was in LdapExt login module.
> You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
> https://issues.jboss.org/browse/SECURITY-891
> Example from Wireshark for 2 groups:
> {code}
> * searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
> * searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
> * searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
> * searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
> {code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6662) Statement.cancel() is not invoked until the statement is completed
by lorenzo benvenuti (JIRA)
[ https://issues.jboss.org/browse/WFLY-6662?page=com.atlassian.jira.plugin.... ]
lorenzo benvenuti updated WFLY-6662:
------------------------------------
Description:
Hi,
in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
{code:java}
public void cancel() throws SQLException
{
if (doLocking)
lock();
try
{
/* ... */
{code}
It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
Thank you,
lorenzo
was:
Hi,
in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
{code:java}
public void More ...cancel() throws SQLException
{
if (doLocking)
lock();
try
{
/* ... */
{code}
It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
Thank you,
lorenzo
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: WFLY-6662
> URL: https://issues.jboss.org/browse/WFLY-6662
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 9.0.2.Final
> Reporter: lorenzo benvenuti
> Assignee: Jesper Pedersen
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6662) Statement.cancel() is not invoked until the statement is completed
by lorenzo benvenuti (JIRA)
lorenzo benvenuti created WFLY-6662:
---------------------------------------
Summary: Statement.cancel() is not invoked until the statement is completed
Key: WFLY-6662
URL: https://issues.jboss.org/browse/WFLY-6662
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 9.0.2.Final
Reporter: lorenzo benvenuti
Assignee: Jesper Pedersen
Hi,
in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
{code:java}
public void More ...cancel() throws SQLException
{
if (doLocking)
lock();
try
{
/* ... */
{code}
It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
Thank you,
lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months