March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2393) Elytron expects certificate in PEM format as user input

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2393?page=com.atlassian.jira.plugi... ] Pedro Igor updated WFCORE-2393: ------------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly-core/pull/66, https://github.com/wildfly-security-incubator/wildfly-core/pull/100 (was: https://github.com/wildfly-security-incubator/wildfly-core/pull/66) > Elytron expects certificate in PEM format as user input > ------------------------------------------------------- > > Key: WFCORE-2393 > URL: https://issues.jboss.org/browse/WFCORE-2393 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Pedro Igor > Labels: user_experience > Fix For: 3.0.0.Beta9 > > > In {{/token-realm/public-key}} attribute there is certificate in PEM format expected, which I consider to be user un-friendly. > I wonder couldn't that be accomplished by leveraging key-store/trust-manager capability? > {code} > "public-key" => { > "type" => STRING, > "description" => "A public key in PEM Format. During validation, if a public key is provided, signature will be verified based on the key you provided here.", > "expressions-allowed" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3289) Intermittent failures in PassworkMaskingTestCase

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3289?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-3289. ----------------------------- Resolution: Out of Date > Intermittent failures in PassworkMaskingTestCase > ------------------------------------------------ > > Key: WFLY-3289 > URL: https://issues.jboss.org/browse/WFLY-3289 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Affects Versions: 8.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Peter Skopek > > PasswordMaskingTestCase fails intermittently. See, for example, http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=14404&buildTyp... > The log shows this: > 05:55:56,496 ERROR [org.jboss.as.arquillian.container.ServerSetupObserver] (main) Setup task failed during setup. Offending class 'org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingTestCase$PasswordMaskingTestCaseSetup@4b584d': java.lang.RuntimeException: Problem creating VaultSession: > at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:168) > at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:180) > at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:188) > at org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingTestCase$PasswordMaskingTestCaseSetup.setup(PasswordMaskingTestCase.java:91) > at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:116) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > . . . > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.Exception: Exception encountered: > at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:173) > at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:191) > at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:166) > ... 103 more > Caused by: org.jboss.security.vault.SecurityVaultException: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) > at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:170) > ... 105 more > Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:750) > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676) > at com.sun.crypto.provider.PBECipherCore.doFinal(PBECipherCore.java:422) > at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(PBEWithMD5AndDESCipher.java:316) > at javax.crypto.Cipher.doFinal(Cipher.java:2087) > at org.jboss.security.plugins.PBEUtils.decode(PBEUtils.java:72) > at org.jboss.security.plugins.PBEUtils.decode64(PBEUtils.java:81) > at org.picketbox.plugins.vault.PicketBoxSecurityVault.decode(PicketBoxSecurityVault.java:362) > at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:339) > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) > ... 106 more > Per discussion at http://lists.jboss.org/pipermail/wildfly-dev/2014-April/002064.html I am going to @Ignore this test and it is subject to being removed 3 weeks after 8.1.0.Final if not corrected. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-37) Server Group Deployment

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plu... ] Prachi Yadav commented on HAWKULARQE-37: ---------------------------------------- Working on Automation Test > Server Group Deployment > ----------------------- > > Key: HAWKULARQE-37 > URL: https://issues.jboss.org/browse/HAWKULARQE-37 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.... ] Tomas Hofman reopened WFLY-8032: -------------------------------- Assignee: Tomas Hofman (was: Stefano Maestri) Reopening due to regression: https://issues.jboss.org/browse/JBEAP-9730?focusedCommentId=13382943&page... > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8032 > URL: https://issues.jboss.org/browse/WFLY-8032 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1033) CS tool, Usage of --help option with other options must display help rather than error message..

by Hynek Švábek (JIRA)

Hynek Švábek created ELY-1033: --------------------------------- Summary: CS tool, Usage of --help option with other options must display help rather than error message.. Key: ELY-1033 URL: https://issues.jboss.org/browse/ELY-1033 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek Švábek Assignee: Darran Lofthouse Help option have to have priority over other options. When I use --help option with other options I want to see help rather than error message.. {code} [hsvabek@dhcp-10-40-5-145 bin]$ java -jar wildfly-elytron-tool.jar mask --help -i 230 -s 12345678 -x secret_password The option 'x' was specified but an option from this group has already been selected: 'h' {code} Same for *credential-store* command. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8453) Rename WildFly Elytron Subsystem to wildfly-elytron-integration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8453?page=com.atlassian.jira.plugin.... ] Darran Lofthouse moved WFCORE-2580 to WFLY-8453: ------------------------------------------------ Project: WildFly (was: WildFly Core) Key: WFLY-8453 (was: WFCORE-2580) Component/s: Security (was: Security) Fix Version/s: 11.0.0.Alpha1 (was: 3.0.0.Beta12) > Rename WildFly Elytron Subsystem to wildfly-elytron-integration > --------------------------------------------------------------- > > Key: WFLY-8453 > URL: https://issues.jboss.org/browse/WFLY-8453 > Project: WildFly > Issue Type: Task > Components: Security > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2580) Rename WildFly Elytron Subsystem to wildfly-elytron-integration

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2580: ---------------------------------------- Summary: Rename WildFly Elytron Subsystem to wildfly-elytron-integration Key: WFCORE-2580 URL: https://issues.jboss.org/browse/WFCORE-2580 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2579) Rename WildFly Elytron Subsystem to wildfly-elytron-integration

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2579: ---------------------------------------- Summary: Rename WildFly Elytron Subsystem to wildfly-elytron-integration Key: WFCORE-2579 URL: https://issues.jboss.org/browse/WFCORE-2579 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8452) Management Interfaces stopping before server fully shutdown

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8452?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-8452. ----------------------------- Assignee: Stuart Douglas (was: Jason Greene) Resolution: Rejected This is not a regression in any way, it is a graceful shutdown in action. For your case, you should probably suspend server first and then shut it down. {{:suspend(timeout=<some-timeout>)}} this way server will just finish serving all in-flight requests but stop accepting new ones. after that you can shutdown the server. you could also try with {{:shutdown(timeout=<some-timeout>)}} but I don't know on top of my head if that would work in your scenario. > Management Interfaces stopping before server fully shutdown > ----------------------------------------------------------- > > Key: WFLY-8452 > URL: https://issues.jboss.org/browse/WFLY-8452 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.1.0.Final > Reporter: John Farrelly > Assignee: Stuart Douglas > > In our product, we use jboss-cli.sh to monitor if WildFly is running ({{jboss-cli.sh -c --controller=${JBOSS_HOST}:${JBOSS_MANAGEMENT_PORT} "read-attribute server-state"}}). We've been using this mechanism to determine if JBoss/WildFly is running since JBoss 7.1.1.Final. > What we are seeing in WildFly 10.1.0.Final is that WildFly shuts down the native interface before it has closed all other services. This means that some long-running business logic thread in WildFly can stop it from shutting down, but the native interface has already stopped, making it seem that WildFly has stopped. > I can see that other services (such as undertow) stay up until the long running business logic thread has completed. This is a regression from JBoss AS 7.1.1, where the management interfaces would not stop while long running business logic was still executing. > Here's the management section of my standalone.xml: > {code:xml} > <management> > <security-realms> > <security-realm name="ManagementRealm"> > <authentication> > <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> > </authentication> > </security-realm> > <security-realm name="ApplicationRealm"> > <authentication> > <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> > </authentication> > </security-realm> > </security-realms> > <management-interfaces> > <native-interface security-realm="ManagementRealm"> > <socket-binding native="management-native"/> > </native-interface> > <http-interface security-realm="ManagementRealm"> > <socket-binding http="management-http"/> > </http-interface> > </management-interfaces> > </management> > {code} > > We use {{jboss-cli.sh}} to issue the shutdown command: > {code} > jboss-cli.sh -c --controller=${JBOSS_HOST}:${JBOSS_MANAGEMENT_PORT} --command=":shutdown" > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.s... ] Pedro Igor commented on ELY-1030: --------------------------------- I'm OK with this change. > Move TokenSecurityRealm to org.wildfly.security.auth.realm package > ------------------------------------------------------------------ > > Key: ELY-1030 > URL: https://issues.jboss.org/browse/ELY-1030 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta34 > > > The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017