August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-370) Cryptographic signature evidence type

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-370?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-370: ------------------------------------ Assignee: (was: David Lloyd) > Cryptographic signature evidence type > ------------------------------------- > > Key: ELY-370 > URL: https://issues.jboss.org/browse/ELY-370 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Priority: Minor > > Add a cryptographic signature evidence type, which should be verifiable by all key- and certificate-based credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1159) Windows delimiter '\' cannot be used in any path in Elytron client configuration file

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1159?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1159: ------------------------------------- Assignee: (was: Darran Lofthouse) > Windows delimiter '\' cannot be used in any path in Elytron client configuration file > ------------------------------------------------------------------------------------- > > Key: ELY-1159 > URL: https://issues.jboss.org/browse/ELY-1159 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Priority: Critical > > When Elytron client configuration file includes some path (e.g. for keystore) with Windows delimiter '\' then this path cannot be parsed. When Windows delimiter '\' is replaced by linux delimiter '/' then resource on given path can be loaded correctly. That means it is user experience issue since common Windows path cannot be used in Elytron client configuration file, but wokraround (using '/') is simple. > None of following types of path work: > {code} > C:\some\path\to\client.truststore > C:\\some\\path\\to\\client.truststore > {code} > Following type of path works on Windows correctly: > {code} > C:/some/path/to/client.truststore > {code} > Following exception is thrown when '\' is used in Elytron client configuration file (the same exception is thrown when '\' is escaped in path): > {code} > org.wildfly.client.config.ConfigXMLParseException: CONF0020: Failed to parse expression value of attribute "name" > at vfs:/W:/workspace/eap-7x-security-elytron-testsuite-windows/f43f9016/tests-security/elytron/content/wildfly-config-xml-dep.war/META-INF/wildfly-config.xml:18:1 > at org.wildfly.client.config.ConfigurationXMLStreamReader.getExpressionAttributeValue(ConfigurationXMLStreamReader.java:685) > at org.wildfly.client.config.ConfigurationXMLStreamReader.getAttributeValueResolved(ConfigurationXMLStreamReader.java:330) > at org.wildfly.security.auth.client.ElytronXmlParser.parseNameType(ElytronXmlParser.java:1697) > at org.wildfly.security.auth.client.ElytronXmlParser.parseNameType(ElytronXmlParser.java:1680) > at org.wildfly.security.auth.client.ElytronXmlParser.parseKeyStoreType(ElytronXmlParser.java:1225) > at org.wildfly.security.auth.client.ElytronXmlParser.parseKeyStoresType(ElytronXmlParser.java:1113) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:279) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141) > at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:116) > ... 41 more > Caused by: java.lang.IllegalArgumentException: COM00009: Invalid expression syntax at position 2 > W:\workspace\eap-7x-security-elytron-testsuite-windows\f43f9016\tests-security\elytron\target\client.keystore > ^ > at org.wildfly.common.expression.Expression.invalidExpressionSyntax(Expression.java:654) > at org.wildfly.common.expression.Expression.parseString(Expression.java:610) > at org.wildfly.common.expression.Expression.compile(Expression.java:203) > at org.wildfly.common.expression.Expression.compile(Expression.java:183) > at org.wildfly.client.config.ConfigurationXMLStreamReader.getExpressionAttributeValue(ConfigurationXMLStreamReader.java:683) > ... 50 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-873) AuthenticationClient testing without jboss-modules

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-873?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-873: ------------------------------------ Assignee: (was: Darran Lofthouse) > AuthenticationClient testing without jboss-modules > -------------------------------------------------- > > Key: ELY-873 > URL: https://issues.jboss.org/browse/ELY-873 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Testsuite > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > Keeping AuthenticationClient usable without a dependency on JBoss Modules is the kind of thing that will be easy to break. > We should probably have a matrix of tests verifying AuthenticationClient anyway, we should then repeat the tests without JBoss Modules on the ClassPath. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-798) FIPS cipher suite security level in not used

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-798?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-798: ------------------------------------ Assignee: (was: Darran Lofthouse) > FIPS cipher suite security level in not used > -------------------------------------------- > > Key: ELY-798 > URL: https://issues.jboss.org/browse/ELY-798 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta16 > Reporter: Ondrej Kotek > > There is defined FIPS cipher suite security level name [1,2], but there are no cipher suites with such level [1]. Do we expect some cipher suites with such level to be added? Or {{(fips value == true) => FIPS security level}}? > There is also preparation for matching FIPS cipher suites [4], which is not used. {{CipherSuiteSelector}} [5,6] could offer _FIPS_ keyword to enable users to set FIPS cipher suites easily. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > [2] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > [4] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > [5] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > [6] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-293) Add file based auth to http management interface

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-293: ------------------------------------ Assignee: (was: Darran Lofthouse) > Add file based auth to http management interface > ------------------------------------------------ > > Key: ELY-293 > URL: https://issues.jboss.org/browse/ELY-293 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Max Rydahl Andersen > Fix For: 2.0.0.Alpha1 > > > usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-478) Some tests fail with AttachNotSupportedException for IBM JDK

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-478?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-478: ------------------------------------ Assignee: (was: Darran Lofthouse) > Some tests fail with AttachNotSupportedException for IBM JDK > ------------------------------------------------------------ > > Key: ELY-478 > URL: https://issues.jboss.org/browse/ELY-478 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta4 > Reporter: Ondrej Lukas > Priority: Minor > > Some tests fail with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded on IBM JDK > Stack trace of exception: > {code} > java.lang.ExceptionInInitializerError > at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137) > at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:88) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) > at java.lang.reflect.Constructor.newInstance(Constructor.java:436) > at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) > at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) > at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) > at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) > at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) > at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded > at mockit.internal.startup.AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(AgentLoader.java:82) > at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:47) > at mockit.internal.startup.AgentInitialization.loadAgentFromLocalJarFile(AgentInitialization.java:27) > at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:208) > at mockit.integration.junit4.JMockit.<clinit>(JMockit.java:21) > ... 17 more > Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded > at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106) > at mockit.internal.startup.AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(AgentLoader.java:72) > ... 21 more > {code} > This is probably only test issue. > Affected tests: > org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest > org.wildfly.security.sasl.digest.CompatibilityClientTest > org.wildfly.security.sasl.digest.CompatibilityServerTest > org.wildfly.security.sasl.entity.EntityTest > org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest > org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest > org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest > org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest > org.wildfly.security.sasl.otp.OTPTest > org.wildfly.security.sasl.scram.ScramClientCompatibilityTest > org.wildfly.security.sasl.scram.ScramServerCompatibilityTest -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-876) Support for PKCS12 KeyStore format in KeyStoreCredentialStore

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-876?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-876: ------------------------------------ Assignee: (was: Peter Skopek) > Support for PKCS12 KeyStore format in KeyStoreCredentialStore > ------------------------------------------------------------- > > Key: ELY-876 > URL: https://issues.jboss.org/browse/ELY-876 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store > Affects Versions: 1.1.0.Beta20 > Reporter: Zoran Regvart > Priority: Minor > > Support for {{PKCS12}} KeyStore in format in SunJCE provider requires that the algorithm id is one of the known OIDs registered with one of the security providers. Using an unknown OID results in {{java.security.NoSuchAlgorithmException}}. > It seems fitting that the algorithm id of {{SecretKey}} stored in the underlying KeyStore would be PKCS#7 data ({{1.2.840.113549.1.7.1}}). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1301) Pem.parsePemX509Certificate() hangs on IBM JDK

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1301?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1301: ------------------------------------- Assignee: (was: Darran Lofthouse) > Pem.parsePemX509Certificate() hangs on IBM JDK > ---------------------------------------------- > > Key: ELY-1301 > URL: https://issues.jboss.org/browse/ELY-1301 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Peter Palaga > > Add a test like this to `PemTest`: > {code} > @Test > public void testParsePemX509CertificateCacert() throws Exception { > URL url = PemTest.class.getResource("/ca/cacert.pem"); > byte[] bytes = Files.readAllBytes(Paths.get(url.toURI())); > assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes))); > } > {code} > Run the test with IBM JDK > {code} > export JAVA_HOME=path/to/ibm/java8 > > $JAVA_HOME/bin/java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR3_20160915_0912_B318796 > JIT - tr.r14.java.green_20160818_122998 > GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS > J9CL - 20160915_318796) > JCL - 20160914_01 based on Oracle jdk8u101-b13 > mvn clean test -Dtest=PemTest#testParsePemX509CertificateCacert > {code} > Expected: The test should pass on IBM JDK just as it passes on Oracle/OpenJDK > Actual: The test hangs on IBM JDK -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-306) Centralize Digest logic

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-306?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-306: ------------------------------------ Assignee: (was: Darran Lofthouse) > Centralize Digest logic > ----------------------- > > Key: ELY-306 > URL: https://issues.jboss.org/browse/ELY-306 > Project: WildFly Elytron > Issue Type: Sub-task > Components: API / SPI, Authentication Mechanisms, HTTP, SASL > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-151) Ability to supply additional information during credential acquisition

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-151?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-151: ------------------------------------ Assignee: (was: Darran Lofthouse) > Ability to supply additional information during credential acquisition > ---------------------------------------------------------------------- > > Key: ELY-151 > URL: https://issues.jboss.org/browse/ELY-151 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, Passwords > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > I think this is the final known gap in our credential acquisition and validation API/SPI. > There are a couple of specifications that also allow for additional information to be used when obtaining a representation of a users credential, the most obvious being the session based variant of digest authentication where a nonce and cnonce are also incorporated. > A second variant with two different modes of operation would be the realm associated with the digest credential, currently we assume it is tightly associated with the storage representation of the credential but it could also be the case that the mech is requesting it for a specific realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 August 2017