[JBoss JIRA] (ELY-858) Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-858?page=com.atlassian.jira.plugin.sy... ]
Ilia Vassilev updated ELY-858:
------------------------------
Fix Version/s: 1.1.0.Beta26
> Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
> ---------------------------------------------------------------------------
>
> Key: ELY-858
> URL: https://issues.jboss.org/browse/ELY-858
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Fix For: 1.1.0.Beta26
>
>
> In case when attribute {{identity-mapping.search-base-dn}} from Elytron ldap-realm is missing in configuration then calling ldap-realm during authentication causes NullPointerException.
> Following exception is thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:976)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:605)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:548)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:516)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1785)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:656)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:854)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:778)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:895)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:726)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 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.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 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)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.naming.InitialContext.getURLScheme(InitialContext.java:160)
> at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:128)
> at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:106)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:319)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:945)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1444) KieSession to implement java.lang.AutoCloseable
by tech meshter (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugi... ]
tech meshter commented on DROOLS-1444:
--------------------------------------
I attached an artificial example using java.io.StringWriter (which is Autcloseable) ( [^AutocloseableSample.java] ).
In one method (desiredState) I take advantage of autocloseable feature and the syntax is pretty compact.
In another class, the autocloseable is not being used and I end up not even being able to compile the code.
Of course, the example is again artificial, just to make the point.
My actual scenario is that:
- I use drools in a Java 8 multi-user (it is a webapp) scenario
- I create one KieSession every time an user invokes that specific scenario and I want to release the resources by calling the "dispose" method.
- Inserting the objects in the KieSession using lambdas is pretty elegant (at least in my case).
Generally, the drools documentation emphasizes the need for the developer to call the "dispose" method once he is done with the KieSession (assuming he created it using a new* method on the KieBase). I see this no different that invoking close on input streams or database result sets...
Now, the AutoCloseable has been introduced in Java 7. If the intention is to keep the binaries compatible with 1.6 or below, then please forget about all this...
> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
> Key: DROOLS-1444
> URL: https://issues.jboss.org/browse/DROOLS-1444
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: tech meshter
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1444) KieSession to implement java.lang.AutoCloseable
by tech meshter (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugi... ]
tech meshter updated DROOLS-1444:
---------------------------------
Attachment: AutocloseableSample.java
> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
> Key: DROOLS-1444
> URL: https://issues.jboss.org/browse/DROOLS-1444
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: tech meshter
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-954) Coverity static analysis, Dereference null return value, OAuth2CredentialSource (Elytron)
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-954?page=com.atlassian.jira.plugin.sy... ]
Ilia Vassilev updated ELY-954:
------------------------------
Fix Version/s: 1.1.0.Beta26
> Coverity static analysis, Dereference null return value, OAuth2CredentialSource (Elytron)
> -----------------------------------------------------------------------------------------
>
> Key: ELY-954
> URL: https://issues.jboss.org/browse/ELY-954
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 1.1.0.Beta26
>
>
> Coverity found possible dereferencing of null value returned from {{resolveSSLContext()}} in {{openConnection()}}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=95640...
> {code:java|title=OAuth2CredentialSource.java}
> private SSLContext resolveSSLContext() {
> if (!isHttps(tokenEndpointUri)) {
> return null;
> }
> return sslContextSupplier == null ? null : sslContextSupplier.get();
> }
> private HttpURLConnection openConnection() throws IOException {
> log.debugf("Opening connection to [%s]", tokenEndpointUri);
> HttpURLConnection connection = (HttpURLConnection) tokenEndpointUri.openConnection();
> if (isHttps(tokenEndpointUri)) {
> HttpsURLConnection https = (HttpsURLConnection) connection;
> https.setSSLSocketFactory(resolveSSLContext().getSocketFactory());
> if (hostnameVerifierSupplier != null) {
> https.setHostnameVerifier(checkNotNullParam("hostnameVerifier", hostnameVerifierSupplier.get()));
> }
> }
> return connection;
> }
> {code}
> NPE could probably happen if {{oauth2-introspection}} is configured with no {{client-ssl-context}} and https {{introspection-url}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-946) Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-946?page=com.atlassian.jira.plugin.sy... ]
Ilia Vassilev updated ELY-946:
------------------------------
Fix Version/s: 1.1.0.Beta25
> Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
> -------------------------------------------------------------------------------------
>
> Key: ELY-946
> URL: https://issues.jboss.org/browse/ELY-946
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 1.1.0.Beta25
>
>
> Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=95638...
> See detailed description of possible problem in [1]
> If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails
> {code}
> byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain();
> assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4));
> {code}
> If I change decodeByteOrderedInteger implementation according to [1], all tests passes.
> {code}
> result |= (buf[offset + i] & 0xff);
> {code}
> [1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE
> Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-673) Empty result of password search in Elytron ldap-realm causes NPE
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-673?page=com.atlassian.jira.plugin.sy... ]
Ilia Vassilev updated ELY-673:
------------------------------
Fix Version/s: 1.1.0.Beta12
> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
> Key: ELY-673
> URL: https://issues.jboss.org/browse/ELY-673
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Fix For: 1.1.0.Beta12
>
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 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:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 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)
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb147...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8161) JDR Subsystem destroys password related system properties
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8161:
--------------------------------------
Assignee: Brad Maxwell (was: Brian Stansberry)
> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
> Key: WFLY-8161
> URL: https://issues.jboss.org/browse/WFLY-8161
> Project: WildFly
> Issue Type: Bug
> Components: JDR
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Brad Maxwell
> Priority: Critical
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string <Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/...
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "<Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months