January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-803) Elytron ExternalSaslServer must finish with null returned from evaluateResponse method

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-803?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev reassigned ELY-803: --------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Elytron ExternalSaslServer must finish with null returned from evaluateResponse method > -------------------------------------------------------------------------------------- > > Key: ELY-803 > URL: https://issues.jboss.org/browse/ELY-803 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Ilia Vassilev > Priority: Critical > > The {{ExternalSaslServer.evaluateResponse}} returns empty byte array instead of null after successful authentication. > [The contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...] says: > {quote} > It is null if the authentication has succeeded and there is no more challenge data to be sent to the client. > {quote} > *Possible fix* > Return null when authentication succeeds. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-800) Elytron ExternalSaslServerFactory.createSaslServer should return null for unsupported policies

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-800?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev reassigned ELY-800: --------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Elytron ExternalSaslServerFactory.createSaslServer should return null for unsupported policies > ---------------------------------------------------------------------------------------------- > > Key: ELY-800 > URL: https://issues.jboss.org/browse/ELY-800 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Ilia Vassilev > > The {{ExternalSaslServerFactory.createSaslServer(String, String, String, Map<String, ?>, CallbackHandler)}} method returns an instance even for properties, for which {{getMechanismNames()}} returns empty array of names. > The {{ExternalSaslServer}} instances should only be created if the mechanism is supported for given properties (configuration). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-774) Memory leak in JBoss CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-774?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-774: ------------------------------------------------ Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1232736|https://bugzilla.redhat.com/show_bug.cgi?id=1232736] from VERIFIED to CLOSED > Memory leak in JBoss CLI > ------------------------ > > Key: WFCORE-774 > URL: https://issues.jboss.org/browse/WFCORE-774 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4 > Reporter: Josef Cacek > Assignee: Tomas Hofman > Fix For: 2.0.0.Alpha8 > > > The JBoss CLI contains a memory leak related to CLI Kerberos authentication. > The {{org.jboss.as.cli.impl.CommandContextImpl}} class calls the {{initJaasConfig()}} in its constructor, > which adds a new {{JaasConfigurationWrapper}} instance to {{javax.security.auth.login.Configuration}}. > It's done for every new {{CommandContext}} instance, so it consumes more and more memory. There is no cleanup for the registered > configurations. > Moreover, the searches for appropriate > login config take more and more time because they have to go through all the wrapped objects. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[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 reassigned ELY-858: --------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > 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 > > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5340: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from VERIFIED to CLOSED > Unable to specify module when specifying custom JACC policy class. > ------------------------------------------------------------------ > > Key: WFLY-5340 > URL: https://issues.jboss.org/browse/WFLY-5340 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.CR1 > > > It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module. > From the JACC specification: - > _For each JRE of a J2EE 1.4 or later version Java EE application server, if the > system property > “javax.security.jacc.policy.provider > ” is defined, > the application server must construct an > instance of the class identified by the > system property, confirm that the > resulting object is an instance of > java.security.Policy, > and set, by calling the > java.security.Policy.setPolicy > method, the resulting object as the > corresponding Policy object u > sed by the JRE. _ > The specification only specifies that the system property identifies the class, it does not specify how. > In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7197) Allow configuration of an Elytron SSLContext in the IIOP subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7197?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-7197: ----------------------------- Fix Version/s: 11.0.0.Alpha1 > Allow configuration of an Elytron SSLContext in the IIOP subsystem > ------------------------------------------------------------------ > > Key: WFLY-7197 > URL: https://issues.jboss.org/browse/WFLY-7197 > Project: WildFly > Issue Type: Sub-task > Components: IIOP > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > > Currently the IIOP subsystem defines an attribute that references a JSSE security domain to obtain the key and trust managers used by the SSLSocketFactory to build an SSLContext instance. > With Elytron we now have a new capability that exposes SSLContext instances and we should be able to use that in the IIOP subsystem. A new attribute must be added to allow for the specification of the Elytron SSLContext that should be used. The SSLSocketFactory will still support the old JSSE-based configuration but will be able to make use of Elytron's centralized SSL configuration to obtain an SSLContext. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7198) Add support for Elytron SecurityDomain in IIOP-enabled EJBs

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7198?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-7198: ----------------------------- Fix Version/s: 11.0.0.Alpha1 > Add support for Elytron SecurityDomain in IIOP-enabled EJBs > ----------------------------------------------------------- > > Key: WFLY-7198 > URL: https://issues.jboss.org/browse/WFLY-7198 > Project: WildFly > Issue Type: Sub-task > Components: EJB, IIOP > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > > With https://issues.jboss.org/browse/WFLY-5689 we now have a way to map security domains as defined within deployment descriptors to Elytron security domains in the EJB3 subsystem. This means that IIOP-enabled beans should make use of the Elytron security framework to authenticate and authorize incoming requests if such a mapping exists for the EJB application. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5452) Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5452?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5452: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1268222|https://bugzilla.redhat.com/show_bug.cgi?id=1268222] from VERIFIED to CLOSED > Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5452 > URL: https://issues.jboss.org/browse/WFLY-5452 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.CR2 > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > Fix For: 10.0.0.CR4 > > > Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4464) JDBC driver module-slot is not persisted in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4464?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4464: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1213642|https://bugzilla.redhat.com/show_bug.cgi?id=1213642] from VERIFIED to CLOSED > JDBC driver module-slot is not persisted in domain mode > ------------------------------------------------------- > > Key: WFLY-4464 > URL: https://issues.jboss.org/browse/WFLY-4464 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.2.0.Final > Reporter: Lin Gao > Assignee: Lin Gao > Fix For: 9.0.0.CR1 > > > The module-slot of jdbc-driver is NOT persisted in domain mode, but it is persisted in standalone mode. > After debugging, I found that the performRuntime() method of JdbcDriverAdd.java is not called in domain mode, but is called in standalone mode. > For more information about the issue, please refer to the thread: https://developer.jboss.org/thread/253654 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2204) Phase definitions for wildfly-nosql subsystems

by Scott Marlow (JIRA)

Scott Marlow created WFCORE-2204: ------------------------------------ Summary: Phase definitions for wildfly-nosql subsystems Key: WFCORE-2204 URL: https://issues.jboss.org/browse/WFCORE-2204 Project: WildFly Core Issue Type: Task Components: Server Reporter: Scott Marlow Assignee: Scott Marlow Priority: Minor Fix For: 3.0.0.Alpha20 The following constants are needed by the DUPs in the [wildfly-nosql|https://github.com/wildfly/wildfly-nosql/] project. Currently, we are hacking the constants. Phase.PARSE_NEO4J_DRIVER Phase.DEPENDENCIES_NEO4J_DRIVER Phase.PARSE_ORIENT_DRIVER Phase.DEPENDENCIES_ORIENT_DRIVER Phase.PARSE_CASSANDRA_DRIVER Phase.DEPENDENCIES_CASSANDRA_DRIVER Phase.PARSE_MONGO_DRIVER Phase.DEPENDENCIES_MONGO_DRIVER -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2017