May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem

by Nikoleta Žiaková (JIRA)

Nikoleta Žiaková created WFCORE-3891: ---------------------------------------- Summary: Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem Key: WFCORE-3891 URL: https://issues.jboss.org/browse/WFCORE-3891 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: Nikoleta Žiaková Assignee: James Perkins When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails: {code} /[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log}) {"outcome" => "success"} [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"", "rolled-back" => true } {code} Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails: {code} [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add {"outcome" => "success"} [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log}) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"", "rolled-back" => true } {code} The same scenario works for e.g. {{pattern-formatter}}: {code} /[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log}) {"outcome" => "success"} [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add {"outcome" => "success"} {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1500) Coverity, Infinite Loop in FactoryCredentialSource

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1500?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1500: ----------------------------------- PR is merged already for couple of months > Coverity, Infinite Loop in FactoryCredentialSource > -------------------------------------------------- > > Key: ELY-1500 > URL: https://issues.jboss.org/browse/ELY-1500 > Project: WildFly Elytron > Issue Type: Bug > Components: Credentials > Affects Versions: 1.2.0.Beta12 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.4.0.CR1 > > > Effectivelly Elytron contains infinite recursion implemented. > {code:java|title=FactoryCredentialSource.java} > @Override > public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException { > return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED; > } > {code} > [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46596... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1440?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1440: ---------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.jboss.org/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.4.0.CR1 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1427) Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1427?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1427: ---------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK. > -------------------------------------------------------------------------------------------------------- > > Key: ELY-1427 > URL: https://issues.jboss.org/browse/ELY-1427 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Priority: Critical > Fix For: 1.4.0.CR1 > > > Credential store type PKCS12 works fine when using OracleJDK and OpenJDK. > Problem occurs when we use IBM JDK, add-alias works fine for first time, but for add-alias for second time with same alias name we expect message about duplicity rather than current error message about SecretKeyFactory not availability. > {code} > "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot acquire a credential from the credential store->Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available->1.2.840.113549.1.7.1 SecretKeyFactory not available'", > {code} > *NOTE* > I met same problem with Oracle JDK 1.8 u66, with u144 is everythink ok. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1425) Add support for JASPIC / JSR-196

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1425?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1425: ---------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > Add support for JASPIC / JSR-196 > -------------------------------- > > Key: ELY-1425 > URL: https://issues.jboss.org/browse/ELY-1425 > Project: WildFly Elytron > Issue Type: Feature Request > Components: EE, HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.4.0.CR1 > > > This is an overall tracking task for changes required to WildFly Elytron to support JASPIC. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1409) Update HTTP authentication mechanism API to support re-use of response handlers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1409?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1409: ---------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > Update HTTP authentication mechanism API to support re-use of response handlers > ------------------------------------------------------------------------------- > > Key: ELY-1409 > URL: https://issues.jboss.org/browse/ELY-1409 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.4.0.CR1 > > > At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request. > Making the scopes available should allow for state to be transferred on the request scope. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1332) NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1332?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1332: ---------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload > -------------------------------------------------------------------------------- > > Key: ELY-1332 > URL: https://issues.jboss.org/browse/ELY-1332 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Priority: Blocker > Fix For: 1.4.0.CR1 > > > When a SunPKCS11 provider is defined in Elytron subsystem on the top of NSS keystore (e.g. a FIPS one), then the server reload fails with "ProviderException: Secmod module already configured". > The server.log contains: > {noformat} > 08:12:56,073 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.providers.nss: org.jboss.msc.service.StartException in service org.wildfly.security.providers.nss: java.lang.reflect.InvocationTargetException > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:224) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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:748) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:190) > ... 7 more > Caused by: java.security.ProviderException: Secmod module already configured > at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:276) > at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107) > ... 12 more > .. > 08:12:56,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("provider-loader" => "nss") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.nss" => "java.lang.reflect.InvocationTargetException > Caused by: java.lang.reflect.InvocationTargetException > Caused by: java.security.ProviderException: Secmod module already configured"}} > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1239) Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1239?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1239: ---------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type. > -------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1239 > URL: https://issues.jboss.org/browse/ELY-1239 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client, Credential Store > Reporter: Hynek Švábek > Assignee: Peter Skopek > Priority: Blocker > Fix For: 1.4.0.CR1 > > > Elytron client, elytron-1_0.xsd, *protection-parameter-credentials* is incorrectly defined as client-credentials-type [1]. > For *protection-parameter-credentials* is valid only credential-store-reference element: > {code} > <xsd:element name="credential-store-reference" type="credential-store-reference-type"/> > {code} > But now is *protection-parameter-credentials* defined as type *client-credentials-type* [1] which can have these values: > {code} > <xsd:complexType name="client-credentials-type"> > <xsd:choice minOccurs="0" maxOccurs="unbounded"> > <xsd:element name="key-store-reference" type="key-store-ref-type"/> > <xsd:element name="credential-store-reference" type="credential-store-reference-type"/> > <xsd:element name="clear-password" type="clear-password-type"/> > <xsd:element name="hashed-password" type="hashed-password-type"/> > <xsd:element name="crypt-password" type="crypt-password-type"/> > <xsd:element name="key-pair" type="key-pair-type"/> > <xsd:element name="certificate" type="certificate-type"/> > <xsd:element name="public-key-pem" type="xsd:string"/> > <xsd:element name="bearer-token" type="bearer-token-type"/> > <xsd:element name="oauth2-bearer-token" type="oauth2-bearer-token-type"/> > </xsd:choice> > </xsd:complexType> > {code} > Please keep on mind that changes must be done accordingly in ElytronXMLParser too. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta47/src... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.4.0.CR1 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-787) SASL mechanisms are not IANA registered and specifications are not provided

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-787?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-787: --------------------------------- Fix Version/s: 1.4.0.CR1 (was: 1.3.3.Final) > SASL mechanisms are not IANA registered and specifications are not provided > --------------------------------------------------------------------------- > > Key: ELY-787 > URL: https://issues.jboss.org/browse/ELY-787 > Project: WildFly Elytron > Issue Type: Task > Reporter: Josef Cacek > Priority: Critical > Labels: sasl > Fix For: 1.4.0.CR1 > > > Elytron comes with set of SASL mechanisms (as requested by EAP7-530), but they don't fit SASL requirements. > New mechanisms has to be registered by IANA as requested by [SASL RFC 4422 section 5|https://tools.ietf.org/html/rfc4422#section-5] and Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] contracts. > Current list of mechanisms provided by Elytron, which are not IANA registered: > * DIGEST-SHA > * DIGEST-SHA-256 > * DIGEST-SHA-512 > * JBOSS-LOCAL-USER > *Suggestion for improvement:* > Provide specifications for the new mechanisms and register the names by IANA (see [section 7 in RFC-4422|https://tools.ietf.org/html/rfc4422#section-7]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 May 2018