September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1346) HTTP Basic auth does not use a IdentityCredentialCallback which prevents the identity from being propagated

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1346?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1346: ------------------------------------- Assignee: Stuart Douglas (was: Darran Lofthouse) > HTTP Basic auth does not use a IdentityCredentialCallback which prevents the identity from being propagated > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1346 > URL: https://issues.jboss.org/browse/ELY-1346 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.1.1.Final, 1.2.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1349) Incorrect doPrivileged usage causes AccessControlException (FilePermission) in Elytron's ServiceLoaderSupplier

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1349?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1349: ---------------------------------- Fix Version/s: 1.1.2.CR1 1.2.0.Beta2 > Incorrect doPrivileged usage causes AccessControlException (FilePermission) in Elytron's ServiceLoaderSupplier > -------------------------------------------------------------------------------------------------------------- > > Key: ELY-1349 > URL: https://issues.jboss.org/browse/ELY-1349 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.1.Final > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.2.CR1, 1.2.0.Beta2 > > > When application server is running with Security Manager then using Elytron API (ElytronXmlParser.parseAuthenticationClientConfiguration()) from deployment leads to AccessControlException. The ServiceLoaderSupplier incorrectly uses doPrivileged, so the FilePermission check during accessing Elytron JAR fails. > Workaround could be adding this FilePermission to each such deployment, but this is neither safe nor practical as the JAR name and location can change (e.g. version upgrade with patches applied). > It seems the problem is caused by passing AccessControlContext as second parameter of {{doPrivileged}} method [1]. {{ServiceLoaderSupplier}} does not require this permission when second paramater is removed from {{doPrivileged}} method. This privileged block has been added as fix of JBEAP-12111 - {{doPrivileged}} call has been added into {{org.wildfly.security.util.ServiceLoaderSupplier}}. > For example this is stacktrace for calling {{ElytronXmlParser.parseAuthenticationClientConfiguration}} method from Servlet in war application: > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/user/jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-1.1.1.Final-redhat-1.jar" "read")" in code source "(vfs:/content/wildfly-config-xml-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wildfly-config-xml-dep.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) > at java.net.URL.openStream(URL.java:1038) > at java.util.ServiceLoader.parse(ServiceLoader.java:304) > at java.util.ServiceLoader.access$200(ServiceLoader.java:185) > at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357) > at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398) > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > at org.wildfly.security.util.ServiceLoaderSupplier.loadServices(ServiceLoaderSupplier.java:73) > at org.wildfly.security.util.ServiceLoaderSupplier.lambda$get$0(ServiceLoaderSupplier.java:58) > at java.security.AccessController.doPrivileged(Native Method) > at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:58) > at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:39) > at org.wildfly.security.auth.client.ElytronXmlParser$DeferredSupplier.get(ElytronXmlParser.java:2433) > at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:115) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$40(ElytronXmlParser.java:2001) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$27(ElytronXmlParser.java:918) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$33(ElytronXmlParser.java:953) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$18(ElytronXmlParser.java:691) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$22(ElytronXmlParser.java:739) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$7(ElytronXmlParser.java:575) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:599) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:299) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:176) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:137) > ... > {code} > [1] https://github.com/wildfly-security/wildfly-elytron/blob/8c033958d78fcb1c... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1352) Simple permission mapper is not simple due to lack of default fallback

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1352?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1352: ---------------------------------- Fix Version/s: 1.1.2.CR1 1.2.0.Beta2 > Simple permission mapper is not simple due to lack of default fallback > ---------------------------------------------------------------------- > > Key: ELY-1352 > URL: https://issues.jboss.org/browse/ELY-1352 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 1.1.2.CR1, 1.2.0.Beta2 > > > Certain common constructs are unnecessarily complicated or effectively impossible for everyday users to configure in the management model (such as "if these principals match, use these permissions, else use these permissions") due to the lack of backend support for a default case in the {{SimplePermissionMapper}}. > Add a way to introduce a {{Mapping}} which matches all principals. The most general way to do this simply is to change the principal set into a principal predicate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1077) Allow AuthenticationConfiguration identity forwarding to populate authorization-id instead of authentication name

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1077?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1077: ---------------------------------- Fix Version/s: 1.1.2.CR1 1.2.0.Beta2 > Allow AuthenticationConfiguration identity forwarding to populate authorization-id instead of authentication name > ----------------------------------------------------------------------------------------------------------------- > > Key: ELY-1077 > URL: https://issues.jboss.org/browse/ELY-1077 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.2.CR1, 1.2.0.Beta2 > > > Sometimes it is useful to run-as the local identity on a peer which does not have access to the local identity credentials. In this case, a trusted identity can be set up on the peer which is authorized to run-as a set of identities from the local system. > In order to support this in AuthenticationConfiguration, a fixed authentication principal and credential set must be used, but the authorization ID would be outflowed from the local security domain instead. > To support this, we need a new method on AuthenticationConfiguration to use a forwarded authorization ID independently from the authentication ID/credentials. > The implementation could retain the single securityDomain field and introduce a bit set that determines whether the forwarded identity is used for authentication, authorization, or both. To avoid comparison issues, the forwarded security domain should be cleared when the bit set is cleared, or otherwise disregarded for the purposes of hashing or comparison in this case. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1356) Release WildFly Elytron 1.2.0.Beta2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1356?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1356. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.2.0.Beta2 > ----------------------------------- > > Key: ELY-1356 > URL: https://issues.jboss.org/browse/ELY-1356 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1355) Release WildFly Elytron 1.1.2.CR1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1355?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1355. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.2.CR1 > --------------------------------- > > Key: ELY-1355 > URL: https://issues.jboss.org/browse/ELY-1355 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.2.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3054) (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3054?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3054: ---------------------------------------------- Another possible source of race that could put the selector in invalide state. > (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop. > -------------------------------------------------------------------------------------- > > Key: WFCORE-3054 > URL: https://issues.jboss.org/browse/WFCORE-3054 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Critical > > *Description of problem:* > Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop. > *Steps to Reproduce:* > # configure https > # loop, more clients in parralel: > #* ./jboss-cli.sh -c ":read-attribute(name=server-state)" -Djavax.net.ssl.trustStore=... -Djavax.net.ssl.trustStorePassword=... > *How reproducible:* > Intermittently > *Actual results:* > Thread dump is attached -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3241) Upgrade WildFly Elytron to 1.1.2.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3241?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved JBEAP-13005 to WFCORE-3241: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3241 (was: JBEAP-13005) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > Upgrade WildFly Elytron to 1.1.2.Final > -------------------------------------- > > Key: WFCORE-3241 > URL: https://issues.jboss.org/browse/WFCORE-3241 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.2.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3241) Upgrade WildFly Elytron to 1.1.2.CR1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3241?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3241: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.1.2.CR1 (was: Upgrade WildFly Elytron to 1.1.2.Final) > Upgrade WildFly Elytron to 1.1.2.CR1 > ------------------------------------ > > Key: WFCORE-3241 > URL: https://issues.jboss.org/browse/WFCORE-3241 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.2.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3241) Upgrade WildFly Elytron to 1.1.2.CR1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3241?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3241: ------------------------------------- Fix Version/s: 3.0.2.Final > Upgrade WildFly Elytron to 1.1.2.CR1 > ------------------------------------ > > Key: WFCORE-3241 > URL: https://issues.jboss.org/browse/WFCORE-3241 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.2.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 September 2017