[JBoss JIRA] (WFLY-11501) DynamicJaspiTestCase fails with security manager
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-11501?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFLY-11501:
------------------------------------
Fix Version/s: 9.x.x TBD
> DynamicJaspiTestCase fails with security manager
> ------------------------------------------------
>
> Key: WFLY-11501
> URL: https://issues.jboss.org/browse/WFLY-11501
> Project: WildFly
> Issue Type: Bug
> Components: Security, Test Suite
> Affects Versions: 16.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 9.x.x TBD
>
>
> {{org.wildfly.test.integration.elytron.jaspi.DynamicJaspiTestCase#testCalls}} fails with security manager due to missing permissions:
> {noformat}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ConfiguredJaspiTestCase/: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "getFactory")" in code source "(vfs:/content/ConfiguredJaspiTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ConfiguredJaspiTestCase.war" from Service Module Loader")
> at org.wildfly.security.elytron-private@1.7.0.Final//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.elytron-private@1.7.0.Final//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at javax.security.auth.message.api@1.0.2.Final//javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:210)
> at org.wildfly.security.elytron-private@1.7.0.Final//org.wildfly.security.auth.jaspi.JaspiConfigurationBuilder.register(JaspiConfigurationBuilder.java:106)
> at deployment.ConfiguredJaspiTestCase.war//org.wildfly.test.integration.elytron.jaspi.JaspiTestServlet.doGet(JaspiTestServlet.java:62)
> at javax.servlet.api@1.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> at javax.servlet.api@1.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.security.elytron-web.undertow-server@1.3.0.Final//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68)
> at org.wildfly.security.elytron-private@1.7.0.Final//org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:103)
> at org.wildfly.security.elytron-private@1.7.0.Final//org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:161)
> at org.wildfly.security.elytron-private@1.7.0.Final//org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:73)
> at org.wildfly.security.elytron-web.undertow-server@1.3.0.Final//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at org.wildfly.security.elytron-web.undertow-server-servlet@1.3.0.Final//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
> at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@16.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@16.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@16.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow@16.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow@16.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow@16.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.core@2.0.15.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.core@2.0.15.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3308) Use separate capability for cacheable security realms
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3308?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3308:
------------------------------------------
As an enhancement a priority of Major makes more sense, this also has zero votes.
> Use separate capability for cacheable security realms
> -----------------------------------------------------
>
> Key: WFCORE-3308
> URL: https://issues.jboss.org/browse/WFCORE-3308
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 3.0.3.Final
> Reporter: Darran Lofthouse
> Priority: Major
>
> This would eliminate the need for a runtime type check which can abort services starting which actually could be quite late.
> One issue however is realms already have a separate capability to represent if they are modifiable so this could lead to more permutations of custom and custom modifiable realms - this may be fine but worth double checking.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3308) Use separate capability for cacheable security realms
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3308?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3308:
-------------------------------------
Priority: Major (was: Critical)
> Use separate capability for cacheable security realms
> -----------------------------------------------------
>
> Key: WFCORE-3308
> URL: https://issues.jboss.org/browse/WFCORE-3308
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 3.0.3.Final
> Reporter: Darran Lofthouse
> Priority: Major
>
> This would eliminate the need for a runtime type check which can abort services starting which actually could be quite late.
> One issue however is realms already have a separate capability to represent if they are modifiable so this could lead to more permutations of custom and custom modifiable realms - this may be fine but worth double checking.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3075) KeyStore password as default KeyManager password
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3075?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3075:
------------------------------------------
As an enhancement doesn't need to be higher than major, presently zero votes for this.
> KeyStore password as default KeyManager password
> ------------------------------------------------
>
> Key: WFCORE-3075
> URL: https://issues.jboss.org/browse/WFCORE-3075
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Jan Kalina
> Priority: Major
> Labels: keymanager, keystore, trustmanager
>
> In Elytron, there is keystore password (key-store resource) and key password (key-managers resource) required.
> However in theory there could be cases, where no password can be intended
> - key-store resource for truststore purposes (reading truststore) (but in legacy is password required)
> - PKCS12 can be created without key password (but keystore password in legacy is required)
> - you can create JKS programatically without keystore password
> - *in legacy key password is optional (which mean keystore password is used)*
> From discussion: We can make the password optional on the KeyManager so if no password is specified on the KeyManager we assume it is the one from the KeyStore.
> Created analysis document for this: https://developer.jboss.org/wiki/AnalysisDesign-KeyStorePasswordAsDefault...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3075) KeyStore password as default KeyManager password
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3075?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3075:
-------------------------------------
Priority: Major (was: Critical)
> KeyStore password as default KeyManager password
> ------------------------------------------------
>
> Key: WFCORE-3075
> URL: https://issues.jboss.org/browse/WFCORE-3075
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Jan Kalina
> Priority: Major
> Labels: keymanager, keystore, trustmanager
>
> In Elytron, there is keystore password (key-store resource) and key password (key-managers resource) required.
> However in theory there could be cases, where no password can be intended
> - key-store resource for truststore purposes (reading truststore) (but in legacy is password required)
> - PKCS12 can be created without key password (but keystore password in legacy is required)
> - you can create JKS programatically without keystore password
> - *in legacy key password is optional (which mean keystore password is used)*
> From discussion: We can make the password optional on the KeyManager so if no password is specified on the KeyManager we assume it is the one from the KeyStore.
> Created analysis document for this: https://developer.jboss.org/wiki/AnalysisDesign-KeyStorePasswordAsDefault...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-1598:
-----------------------------------
Fix Version/s: 16.0.0.Beta1
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 16.0.0.Beta1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-1598:
--------------------------------------
Assignee: Farah Juma
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 16.0.0.Beta1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3947:
------------------------------------------
[~mmazanek] if you have a duplicate issue already just resolve this one as a duplicate and link the two.
> Support SSL Certificate revocation using OCSP
> ---------------------------------------------
>
> Key: WFCORE-3947
> URL: https://issues.jboss.org/browse/WFCORE-3947
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Affects Versions: 6.0.0.Alpha2
> Reporter: Jan Kalina
> Assignee: Martin Mazanek
> Priority: Critical
> Fix For: 8.0.0.Beta2
>
>
> - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP.
> (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-3402) Encoding set in constructor not taking effect
by Barnabás Kurucz (Jira)
[ https://issues.jboss.org/browse/DROOLS-3402?page=com.atlassian.jira.plugi... ]
Barnabás Kurucz reopened DROOLS-3402:
-------------------------------------
Hi, thanks for having a look at this. After some further investigation it looks the issue can be reproduced only when the default system encoding is set to CP-1252.
Since the system default was CP-1252, the JVM was running with that encoding and the KIE Resource also had used this encoding, even though I set UTF-8 in its conctructor.
Once I changed the system default to UTF-8, the special characters (ä, etc.) were shown correctly. Could you have another look?
> Encoding set in constructor not taking effect
> ---------------------------------------------
>
> Key: DROOLS-3402
> URL: https://issues.jboss.org/browse/DROOLS-3402
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.13.0.Final
> Reporter: Barnabás Kurucz
> Assignee: Mario Fusco
> Priority: Major
>
> In my drl file, I'm using German characters such as Umlauts or ß. Thus, I am setting the encoding to UTF-8 with the overloaded constructor when creating the Resource for the Kie File System. However, after firing the rules on the inserted Fact Drools does not seem to apply the specified encoding. I insert the fact, and if the condition is true to that fact it should modify the Action1 (String) attribute of the fact to "Rückfrage" and return the modified fact. However, when I look at the retrieved bean's Action1 attribute I am seeing "Rückfrage" instead of "Rückfrage". I tried both UTF-8 and ISO-8859-1 encoding. Any ideas what's wrong?
> Drools 7.13
> *KieSessionGenerator*:
> public KieSessionGenerator() {
> KieServices kieServices = KieServices.Factory.get();
> KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
> kieFileSystem.write(ResourceFactory.newClassPathResource(drlFile, "UTF-8"));
> KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
> kieBuilder.buildAll();
> KieModule kieModule = kieBuilder.getKieModule();
> KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
> kieSession = kieContainer.newKieSession();
> }
> *Snippet from DRL:*
> rule "813"
> when
> $bean : Bean(longDesc == "Infektion")
> then
> $bean.setAction1("Rückfrage");
> end
> *Inserting the fact:*
> public Bean lookupBean(Bean bean) {
> kieSessionGenerator.getKieSession().insert(bean);
> kieSessionGenerator.getKieSession().fireAllRules();
> return bean;
> }
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months