August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-375) Server-side channel binding can cause mismatches

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-375?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-375: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Server-side channel binding can cause mismatches > ------------------------------------------------ > > Key: ELY-375 > URL: https://issues.jboss.org/browse/ELY-375 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms, Callbacks > Reporter: David Lloyd > Fix For: 1.2.0.Beta3 > > > At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is. > However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error. > SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server. > SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time. > So I propose the following: > # On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data. > # Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types. > # On the SCRAM server, instead of using ChannelBindingCallback to select a binding type *and* acquire the binding data, use this channel binding types callback to acquire the set of available channel bindings within the server factory. > # On the SCRAM server, validate the client's selected binding type against the set of available channel bindings. > # Change the ChannelBindingCallback contract, so that if a binding type name is already provided, the corresponding binding data should be provided (or an exception thrown). If no channel binding type name is given, then the callback continues to function as it does today, where a type is chosen and provided along with its data. > # On the SCRAM server, use the modified ChannelBindingCallback contract to acquire the binding data for a pre-selected channel binding type. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-355) HTTP Authentication Mechanism Testing

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-355?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-355: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > HTTP Authentication Mechanism Testing > ------------------------------------- > > Key: ELY-355 > URL: https://issues.jboss.org/browse/ELY-355 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Testsuite > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta3 > > > We don't want to create a full HTTP server but we should have a sufficient wrapper to test the HTTP authentication framework and test out specific mechanims. > This will leave the Elytron Web project to smoke test integration and not focus on testing the actual mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-341) PEM file format support

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-341: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > PEM file format support > ----------------------- > > Key: ELY-341 > URL: https://issues.jboss.org/browse/ELY-341 > Project: WildFly Elytron > Issue Type: Enhancement > Components: KeyStores > Reporter: David Lloyd > Assignee: Pedro Igor > Fix For: 1.2.0.Beta3 > > > We should add support for PEM formats for formats including (but not limited to): > * X.509 Certificate > * CSRs > * CRLs > * RSA and DSA Public and Private Keys > * PKCS8 format Private Keys > * DH parameters > * ECDSA Public Key > * EC Private Key > * EC Parameters > This API could be consumed by various utilities or by custom credential storage implementations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-659) Make all mechanism implementations final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-659?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-659: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Make all mechanism implementations final > ---------------------------------------- > > Key: ELY-659 > URL: https://issues.jboss.org/browse/ELY-659 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms, HTTP, SASL > Reporter: David Lloyd > Priority: Critical > Fix For: 1.2.0.Beta3 > > > It is very important to make all the mechanism implementations final. Relatedly, they should have no protected members. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-613: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Some nested classes should be considered to be static nested in Elytron > ----------------------------------------------------------------------- > > Key: ELY-613 > URL: https://issues.jboss.org/browse/ELY-613 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Labels: static_analysis > Fix For: 1.2.0.Beta3 > > > There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered: > * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm > * DecoderState from org.wildfly.security.asn1.DERDecoder > * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm > * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm > * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-609: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Labels: static_analysis > Fix For: 1.2.0.Beta3 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-534) Some tests fail with ExceptionInInitializerError with JMockit 1.22 for IBM JDK

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-534?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-534: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Some tests fail with ExceptionInInitializerError with JMockit 1.22 for IBM JDK > ------------------------------------------------------------------------------ > > Key: ELY-534 > URL: https://issues.jboss.org/browse/ELY-534 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta6 > Reporter: Ondrej Lukas > Assignee: Peter Palaga > Priority: Minor > Fix For: 1.2.0.Beta3 > > > Some tests fail with java.lang.ExceptionInInitializerError on IBM JDK. > Stacktrace (for OAuth2SecurityRealmTest): > {code} > java.lang.ExceptionInInitializerError > at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137) > at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126) > at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.configureTokenIntrospectionEndpoint(OAuth2SecurityRealmTest.java:198) > at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.configureReplayTokenIntrospection(OAuth2SecurityRealmTest.java:188) > at org.wildfly.security.auth.realm.oauth2.OAuth2SecurityRealmTest.testBasicActiveToken(OAuth2SecurityRealmTest.java:62) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > 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.IllegalStateException: To run on IBM J9 VM, add <IBM SDK>/lib/tools.jar to the runtime classpath (before jmockit), or use -javaagent:/mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/5fe75d5a/maven-repository/org/jmockit/jmockit/1.22/jmockit-1.22.jar > at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:49) > at mockit.internal.startup.Startup.verifyInitialization(Startup.java:172) > at mockit.MockUp.<clinit>(MockUp.java:94) > ... 27 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 > It seems that this issue can be fixed by adding -{{javaagent:$\{USED_MAVEN_REPO\}/org/jmockit/jmockit/1.22/jmockit-1.22.jar}} as argLine option for Maven Surefire Plugin. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.2.0.Beta3 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-490) Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-490?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-490: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. > ------------------------------------------------------------------------ > > Key: ELY-490 > URL: https://issues.jboss.org/browse/ELY-490 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta3 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-489) Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-489?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-489: --------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta1) > Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages. > ------------------------------------------------------------------------------ > > Key: ELY-489 > URL: https://issues.jboss.org/browse/ELY-489 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta3 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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