May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1115: ---------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/791, https://github.com/wildfly-security/wildfly-elytron/pull/799 (was: https://github.com/wildfly-security/wildfly-elytron/pull/791) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta41 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina reopened ELY-1115: ----------------------------- > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta41 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1105) FIPS mode, wildfly-config.xml does not support non-file based keystores (e.g. PKCS11)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1105?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1105: ---------------------------------- Fix Version/s: 1.1.0.Beta41 > FIPS mode, wildfly-config.xml does not support non-file based keystores (e.g. PKCS11) > ------------------------------------------------------------------------------------- > > Key: ELY-1105 > URL: https://issues.jboss.org/browse/ELY-1105 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta38 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta41 > > > File is required during configuring key-store in wildfly-config.xml. This will make problem if user wants use non-file based keystore. > Required file in xsd > {code:xml|title=elytron-1_0.xsd} > <xsd:complexType name="key-store-type"> > <xsd:sequence minOccurs="1" maxOccurs="1"> >  > <xsd:choice minOccurs="1" maxOccurs="1"> > <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/> > </xsd:choice> >  > <xsd:choice minOccurs="0" maxOccurs="1"> > <xsd:element name="key-store-credential" type="key-store-ref-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="key-store-clear-password" type="clear-password-type" minOccurs="1" maxOccurs="1"/> > </xsd:choice> > </xsd:sequence> > <xsd:attribute name="name" type="xsd:string" use="required"/> > <xsd:attribute name="type" type="xsd:string" use="required"/> > <xsd:attribute name="provider" type="xsd:string" use="optional"/> > <xsd:attribute name="wrap-passwords" type="xsd:boolean" use="optional" default="false"/> > </xsd:complexType> > {code} > {code:xml|title=wildfly-config.xml} > <key-stores> > <key-store name="trustsore" type="PKCS11" provider="SunPKCS11-testPkcs"> > <file name="/does/not/exists"/> > <key-store-clear-password password="pass123+"/> > </key-store> > </key-stores> > {code} > Error in server log > {code:title=server.log} > 14:12:58,961 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /wildfly-config-app/authenticationContext: java.lang.RuntimeException: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data > at vfs:/content/wildfly-config-app.war/META-INF/wildfly-config.xml:20:13 > at com.redhat.eap.qe.deployment.servlet.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:119) > at com.redhat.eap.qe.deployment.servlet.WildflyConfigXmlServlet.doGet(WildflyConfigXmlServlet.java:91) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > 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.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > 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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > 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:211) > 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: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data > at vfs:/content/wildfly-config-app.war/META-INF/wildfly-config.xml:20:13 > at org.wildfly.security.auth.client.ElytronXmlParser$AbstractLoadingKeyStoreFactory.get(ElytronXmlParser.java:2337) > at org.wildfly.security.auth.client.ElytronXmlParser$AbstractLoadingKeyStoreFactory.get(ElytronXmlParser.java:2317) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:303) > 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.deployment.servlet.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:116) > ... 41 more > Caused by: java.io.FileNotFoundException: /does/not/exists (No such file or directory) > at java.io.FileInputStream.open0(Native Method) > at java.io.FileInputStream.open(FileInputStream.java:195) > at java.io.FileInputStream.<init>(FileInputStream.java:138) > at java.io.FileInputStream.<init>(FileInputStream.java:93) > at org.wildfly.security.auth.client.ElytronXmlParser$FileLoadingKeyStoreFactory.createStream(ElytronXmlParser.java:2354) > at org.wildfly.security.auth.client.ElytronXmlParser$AbstractLoadingKeyStoreFactory.get(ElytronXmlParser.java:2332) > ... 46 more > {code} > Relevant code > {code:java|title=ElytronXmlParser.java} > public KeyStore get() throws ConfigXMLParseException { > try { > KeyStore keyStore = delegateFactory.get(); > try (InputStream fis = createStream()) { > keyStore.load(fis, passwordFactory == null ? null : passwordFactory.get()); > } > return keyStore; > } catch (GeneralSecurityException | IOException e) { > throw xmlLog.xmlFailedToLoadKeyStoreData(location, e); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8668) Upgrade jboss-jaxws-api_2.2_spec to 2.0.4.Final

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-8668?page=com.atlassian.jira.plugin.... ] Alessio Soldano reassigned WFLY-8668: ------------------------------------- Assignee: Alessio Soldano > Upgrade jboss-jaxws-api_2.2_spec to 2.0.4.Final > ----------------------------------------------- > > Key: WFLY-8668 > URL: https://issues.jboss.org/browse/WFLY-8668 > Project: WildFly > Issue Type: Component Upgrade > Components: EE > Affects Versions: 11.0.0.Alpha1 > Reporter: Ivo Studensky > Assignee: Alessio Soldano > > The upgrade involves JBEE-176 to fix Security Manager related issues. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8669) Upgrade jboss-saaj-api_1.3_spec to 1.0.4.Final

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-8669?page=com.atlassian.jira.plugin.... ] Alessio Soldano reassigned WFLY-8669: ------------------------------------- Assignee: Alessio Soldano > Upgrade jboss-saaj-api_1.3_spec to 1.0.4.Final > ---------------------------------------------- > > Key: WFLY-8669 > URL: https://issues.jboss.org/browse/WFLY-8669 > Project: WildFly > Issue Type: Component Upgrade > Components: EE > Affects Versions: 11.0.0.Alpha1 > Reporter: Ivo Studensky > Assignee: Alessio Soldano > > This upgrade involves JBEE-175 to fix Security Manager related issues. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-175) FactoryFinder requires more privileged blocks if Security Manager is enabled

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBEE-175?page=com.atlassian.jira.plugin.s... ] Alessio Soldano resolved JBEE-175. ---------------------------------- Resolution: Done > FactoryFinder requires more privileged blocks if Security Manager is enabled > ----------------------------------------------------------------------------- > > Key: JBEE-175 > URL: https://issues.jboss.org/browse/JBEE-175 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-saaj-api > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. > Affected version: jboss-saaj-api_1.3_spec-1.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-176) FactoryFinder requires more privileged blocks if Security Manager is enabled

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBEE-176?page=com.atlassian.jira.plugin.s... ] Alessio Soldano resolved JBEE-176. ---------------------------------- Resolution: Done > FactoryFinder requires more privileged blocks if Security Manager is enabled > ---------------------------------------------------------------------------- > > Key: JBEE-176 > URL: https://issues.jboss.org/browse/JBEE-176 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jaxws-api > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. > Affected version: jboss-jaxws-api_2.2_spec-2.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1132) Unable to load passwords from wildfly-config.xml

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1132?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on ELY-1132: --------------------------------------- Thanks will take a look. > Unable to load passwords from wildfly-config.xml > ------------------------------------------------ > > Key: ELY-1132 > URL: https://issues.jboss.org/browse/ELY-1132 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > > I see the following exception, adding use-service-loader-providers does not help > Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear" > at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$47(ElytronXmlParser.java:2009) > ... 46 more > Looks like this should just be hard coded to use the Elytron provider? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-96) Run OpenSCAP on 4.5 Docker Images

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-96: ---------------------------------------- Summary: Run OpenSCAP on 4.5 Docker Images Key: HAWKULARQE-96 URL: https://issues.jboss.org/browse/HAWKULARQE-96 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8709) Upgrade Artemis 1.5.4.jbossorg-004

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8709?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-10767 to WFLY-8709: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8709 (was: JBEAP-10767) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) > Upgrade Artemis 1.5.4.jbossorg-004 > ---------------------------------- > > Key: WFLY-8709 > URL: https://issues.jboss.org/browse/WFLY-8709 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Andy Taylor > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017