[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1115:
----------------------------------
Fix Version/s: 1.1.0.Beta42
(was: 1.1.0.Beta41)
> 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.Beta42
>
>
> 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)
9 years
[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.Beta42
(was: 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.Beta42
>
>
> 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">
> <!-- Access source type -->
> <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>
> <!-- Protection parameter -->
> <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)
9 years
[JBoss JIRA] (ELY-983) WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-983?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-983:
--------------------------------------
Please don't re-open community issues - just clone a new issue if follow up changes are required.
> WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods
> -------------------------------------------------------------------------------------------------
>
> Key: ELY-983
> URL: https://issues.jboss.org/browse/ELY-983
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta37
>
>
> The description of {{MECHANISM_QUERY_ALL}} filtering property says:
> {quote}
> This flag is only effective on calls to SaslServerFactory.getMechanismNames(Map) or SaslClientFactory.getMechanismNames(Map) for Elytron-provided SASL factories.
> {quote}
> It's not true for EXTERNAL SASL mechanism factories, where it's taken into account also in {{createSaslServer/Client}} methods.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years