November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7046) domain-elytron.xml doesn't predefine ManagementDomain

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7046?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7046. ------------------------------------ Resolution: Rejected As described on my last comment - in domain mode the management domain lives in the host.xml > domain-elytron.xml doesn't predefine ManagementDomain > ----------------------------------------------------- > > Key: WFLY-7046 > URL: https://issues.jboss.org/browse/WFLY-7046 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > When I compare domain-elytron.xml to standalone-elytron.xml there is missing ManagementDomain configured in all 4 profiles. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7091. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Rejected Marking as rejected as the relationships in use here are driven by the Java SE APIs. > Not able to configure list of key/trust managers on elytron ssl context. > ------------------------------------------------------------------------ > > Key: WFLY-7091 > URL: https://issues.jboss.org/browse/WFLY-7091 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed. > XSD documentation > * key-managers - Reference to the KeyManagers to be used by this SSLContext. > * trust-managers - Reference to the TrustManagers to be used by this SSLContext. > Model description: > {noformat} > "key-managers" => { > "type" => STRING, > "description" => "Reference to the key managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.key-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "trust-managers" => { > "type" => STRING, > "description" => "Reference to the trust managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.trust-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7042) Elytron Test Coverage

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7042?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7042: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron Test Coverage > --------------------- > > Key: WFLY-7042 > URL: https://issues.jboss.org/browse/WFLY-7042 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Blocker > Labels: elytron_testing > Fix For: 11.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7041) Add testing for Web -> EJB Identity Propagation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7041?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7041: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Add testing for Web -> EJB Identity Propagation > ----------------------------------------------- > > Key: WFLY-7041 > URL: https://issues.jboss.org/browse/WFLY-7041 > Project: WildFly > Issue Type: Task > Components: EJB, Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Labels: elytron_testing > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1731) Exception generated from command "connection-info" with embedded server

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1731?page=com.atlassian.jira.plugi... ] Ingo Weiss commented on WFCORE-1731: ------------------------------------ Now both, WildFly master and EAP 7.x branches show only: {code} [standalone@embedded /] connection-info Exception for connection-info: java.lang.NullPointerException {code} > Exception generated from command "connection-info" with embedded server > ----------------------------------------------------------------------- > > Key: WFCORE-1731 > URL: https://issues.jboss.org/browse/WFCORE-1731 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management, Security > Affects Versions: 3.0.0.Alpha5 > Environment: JBoss Admin Command-line Interface > JBOSS_HOME: C:\dev\jboss-eap-7.0.1 > JBoss AS release: 2.1.6.Final-redhat-1 "Kenny" > JBoss AS product: JBoss EAP 7.0.1.GA > JAVA_HOME: c:\java\jdk1.8.0_45 > java.version: 1.8.0_45 > java.vm.vendor: Oracle Corporation > java.vm.version: 25.45-b02 > os.name: Windows 7 > os.version: 6.1 > Reporter: Petr Kremensky > Assignee: Ingo Weiss > Priority: Minor > > I started the embedded server and tried to obtain the connection information. An exception occurred: > {code} > [standalone@embedded /] connection-info > 13:14:59,095 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 32) WFLYCTL0013: Operation ("whoami") failed - address: ([]): java.lang.IllegalArgumentException: newValue is null > at org.jboss.dmr.ModelNode.set(ModelNode.java:499) > at org.jboss.as.domain.management.security.WhoAmIOperation.execute(WhoAmIOperation.java:95) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649) > at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63) > at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59) > at org.jboss.as.cli.handlers.ConnectionInfoHandler.doHandle(ConnectionInfoHandler.java:74) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776) > at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799) > at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:412) > at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53) > 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) > WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null > Failed to handle 'connection-info': java.lang.NullPointerException > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6452) Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-6452. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Out of Date Application server security is migrating to WildFly Elytron > Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6452 > URL: https://issues.jboss.org/browse/WFLY-6452 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Juan AMAT > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4. > What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average. > In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM. > With wildfly it was 95+%. > Threads dumps showed a lot of threads in the JAAS Login Module. > We are using org.jboss.security.auth.spi.DatabaseServerLoginModule. > This was strange because all the users were already authenticated. > It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4. > The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients. > The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication. > We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker). > But this is just a workaround IMO. > Why is 'isValid' called on every request in Wildfly? > On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default' -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6238) Upgrade to JBoss Negotiation 3.0.1.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6238?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-6238. ------------------------------------ Resolution: Out of Date > Upgrade to JBoss Negotiation 3.0.1.Final > ---------------------------------------- > > Key: WFLY-6238 > URL: https://issues.jboss.org/browse/WFLY-6238 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5719) Using Kerberos as login module results in LoginException: unable to find LoginModule class

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5719?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-5719. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Out of Date Application server security is migrating to WildFly Elytron > Using Kerberos as login module results in LoginException: unable to find LoginModule class > ------------------------------------------------------------------------------------------ > > Key: WFLY-5719 > URL: https://issues.jboss.org/browse/WFLY-5719 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.2.Final, 10.0.0.CR4 > Environment: Windows Server 2012 R2, Java 8 update 40 > Reporter: Brett Prucha > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > When using <login-module code="Kerberos" flag="required">, the following exception is thrown: > javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.negotiation.KerberosLoginModule > When replacing the login module with the one provided by the JVM: > <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required"> > no exception is thrown and authentication works as expected. > The Kerberos login module works in Wildfly 8.2.0. It appears the class loading or something similar has changed in 9.x onwards to cause this to stop working. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5063) Confusing authorization behavior in undertow/ejb3

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5063?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-5063. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Out of Date Application server security is migrating to WildFly Elytron > Confusing authorization behavior in undertow/ejb3 > ------------------------------------------------- > > Key: WFLY-5063 > URL: https://issues.jboss.org/browse/WFLY-5063 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Reporter: Michał Zegan > Assignee: Jason Greene > Fix For: 11.0.0.Alpha1 > > > I believe that the behavior of web and ejb authorization is confusing, and at the same time it is undocumented. > Here it is: > 1. There are authorization settings in security domains that specify policy modules to use. > 2. In case of web authorization with undertow, security domains are not used by default unless this is enabled in jboss-web.xml, but even though this is the case, if you change a default module to jacc, undertow switches to jacc authorization even though it normally does not use security domains. > 3. If jboss authorization is enabled in jboss-web.xml, then the default authorization module does nothing but you still get normal authz behavior as per servlet spec... But if you would set authorization policy to jacc, I believe it would cause jacc checks to be performed twice in case of successful auth, once because of security domain settings, once inside undertow... > 4. At the same time EJB container uses authorization modules in security domains as the only authorization mechanism and in this case the default module really implements authorization decisions. > 5. And, as the last point, in addition to the possibility to using jacc module or xacml module to authorize ejbs (and servlets), you can probably do the same with changing a delegate in the default delegating authz module. > It is possible I forgot something or that I am wrong, but...... That seems extremely complex to actually understand, and some things here seem to be redundant. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4761) Unchecked exceptions in login modules are eaten by Picketbox

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-4761?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-4761. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Out of Date Application server security is migrating to WildFly Elytron > Unchecked exceptions in login modules are eaten by Picketbox > ------------------------------------------------------------ > > Key: WFLY-4761 > URL: https://issues.jboss.org/browse/WFLY-4761 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.2.0.Final > Reporter: Matěj Liszka > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > In one of ABB software projects, during development of a custom login module (extending org.jboss.security.auth.spi.DatabaseServerLoginModule) I was not able to trace any errors in the log while the module apparently failed to execute its code. After debugging the Picketbox library (it is picketbox-infinispan-4.0.21.Final.jar) I found out that unchecked exceptions in the login module are eaten by return statement from finally blocks of calling methods. This happened in case of runtime errors in method initialize as well as in case of unsatisfied module dependencies (missing dependencies in module.xml). The workaround (which could be also the bug fix for this problem) was to modify org.jboss.security.authentication.JBossCachedAuthenticationManager by catching runtime errors in the second part of implementation of defaultLogin method and by rethrowing them wrapped as LoginException. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 November 2016