[JBoss JIRA] (WFCORE-2545) Principal with null name causes hidden NPE for chained-principal-transformer
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2545?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2545.
--------------------------------------
Fix Version/s: 3.0.0.Beta29
Resolution: Done
> Principal with null name causes hidden NPE for chained-principal-transformer
> ----------------------------------------------------------------------------
>
> Key: WFCORE-2545
> URL: https://issues.jboss.org/browse/WFCORE-2545
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Beta29
>
>
> In case when Principal with null name is used in {{chain}} of {{org.wildfly.extension.elytron.capabilities.PrincipalTransformer}} then this method throw NullPointerException which is hidden to user due to JBEAP-9625.
> This issue can be simply reproduced by using regex-validating-principal-transformer and user which does not match given pattern. Then Principal name is set to null which results to following NPE:
> {code}
> java.lang.NullPointerException:
> java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> java.util.regex.Matcher.reset(Matcher.java:309)
> java.util.regex.Matcher.<init>(Matcher.java:229)
> java.util.regex.Pattern.matcher(Pattern.java:1093)
> org.wildfly.security.auth.util.RegexNameRewriter.rewriteName(RegexNameRewriter.java:55)
> org.wildfly.security.auth.server.NameRewriter.lambda$asPrincipalRewriter$1(NameRewriter.java:63)
> org.wildfly.extension.elytron.capabilities.PrincipalTransformer.lambda$chain$1(PrincipalTransformer.java:64)
> ...
> {code}
> Since there is no related documentation or javadoc it is also possible that issue is rather in regex-validating-principal-transformer which could set Principal to null instead of Principal name to null. It must be clarified by engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2615.
--------------------------------------
Fix Version/s: 3.0.0.Beta29
Resolution: Out of Date
This area of configuration has been revisited.
> Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2615
> URL: https://issues.jboss.org/browse/WFCORE-2615
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
> Attachments: dep.war, wireshark.pcapng
>
>
> In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
> See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
> This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
> We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2662) Elytron caching-realm backed by ldap-realm should avoid hitting LDAP for a cache hit
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2662?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2662.
--------------------------------------
Fix Version/s: 3.0.0.Beta29
Resolution: Done
> Elytron caching-realm backed by ldap-realm should avoid hitting LDAP for a cache hit
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2662
> URL: https://issues.jboss.org/browse/WFCORE-2662
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta14
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: caching, ldap, ldap-realm, security-realm
> Fix For: 3.0.0.Beta29
>
>
> Elytron {{caching-realm}} backed by {{ldap-realm}} provides caching for identity objects but not for related credentials and attributes. This is currently due to design of {{ldap-realm}} (like in case of {{filesystem-realm}}, see JBEAP-8628).
> Credentials and attributes should not be loaded from LDAP for a cache hit.
> Blocks EAP7-542 Elytron Caching Support. Note: caching of credentials is not a requirement, but may be reconsidered and become an enhancement to overall performance, see analysis document of the RFE. However, {{jdbc-realm}} is designed to enable caching of credentials. To be consistent, the {{ldap-realm}} should also enable caching of credentials.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2689) Elytron, unable to use elytron ssl-context in server to host controller communication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2689?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2689.
--------------------------------------
Resolution: Rejected
Rejecting as the server -> host SSL configuration requires special handling.
> Elytron, unable to use elytron ssl-context in server to host controller communication
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2689
> URL: https://issues.jboss.org/browse/WFCORE-2689
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap7.1-rfe-blocker
>
> In legacy there is possible to configure ssl context for the connection from the application server back to it's host controller in domain mode. This legacy configuration was added based on JBEAP-2514.
> I don't see Elytron alternative, such it would be possible to configure Elytron client ssl context.
> I have verified it is still possible to successfully configure domain mode in FIPS mode mixing 2 approaches:
> * Elytron for controller to controller communication
> * Legacy for server to controller communication.
> {code:title=wildfly-config_5_0.xsd}
> <xs:complexType name="serverType">
> <xs:all>
> <xs:element name="paths" type="specified-pathsType" minOccurs="0" maxOccurs="1" />
> <xs:element name="interfaces" type="specified-interfacesType" minOccurs="0"/>
> <xs:element name="socket-bindings" type="server-socket-bindingsType" minOccurs="0"/>
> <!--<xs:element name="loggers" type="loggersType" minOccurs="0"/>-->
> <xs:element name="system-properties" type="properties-with-boottime" minOccurs="0"/>
> <xs:element name="jvm" minOccurs="0" type="serverJvmType"/>
> <xs:element name="ssl" minOccurs="0" type="server-sslType">
> <xs:annotation>
> <xs:documentation>
> Configuration of the SSLContext used for the connection from the application server back to it's host controller.
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> </xs:all>
> <xs:attribute name="name" type="xs:string" use="required"/>
> <xs:attribute name="group" type="xs:string" use="required"/>
> <xs:attribute name="auto-start" type="xs:boolean" default="true"/>
> <xs:attribute name="update-auto-start-with-server-status" type="xs:boolean" default="false">
> <xs:annotation>
> <xs:documentation>
> Iif the server last status (STARTED or STOPPED) is to be used to define the value of auto-start.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:complexType>
> {code}
> I found issue now as:
> * RFE was switched into Verificaiton TODO in DR16
> * There existed and still exists couple of related issues (JBEAP-8147, JBEAP-10060, JBEAP-9630) which hint this area is not working properly, so focus was on another areas.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2746:
-------------------------------------
Fix Version/s: 4.0.0.Alpha1
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> -org.jboss.as.test.integration.security.credentialreference [2]-
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2724) Attribute protocol in authentication-configuration of Elytron subsystem is not used
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2724?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2724.
--------------------------------------
Fix Version/s: 3.0.0.Beta29
Resolution: Done
> Attribute protocol in authentication-configuration of Elytron subsystem is not used
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2724
> URL: https://issues.jboss.org/browse/WFCORE-2724
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
>
> When authentication-configuration in Elytron subsystem uses attribute {{protocol}} then value of this attribute is not used for outgoing connection. Attributes {{host}} and {{port}} are used correctly.
> Following authentication-configuration of Elytron subsystem should use URL {{remote+http://localhost:9990}} for outgoing connection, but protocol {{remote+http}} from {{protocol}} is not used:
> {code}
> <authentication-configuration name="authConfig" authentication-name="admin" protocol="remote+http" host="localhost" port="9990">
> <credential-reference clear-text="pass@123"/>
> </authentication-configuration>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2931) Regression in DR19, Elytron unable to authenticate with kerberos using jboss-cli
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2931?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2931.
--------------------------------------
Fix Version/s: 3.0.0.Beta29
Resolution: Done
> Regression in DR19, Elytron unable to authenticate with kerberos using jboss-cli
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2931
> URL: https://issues.jboss.org/browse/WFCORE-2931
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
>
> Trying to connect with jboss-cli to server using kerberos leads to error
> {code}
> 14:41:22,654 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) Client selected security layer AUTH, with maxBuffer of 65536
> 14:41:22,655 TRACE [org.jboss.remoting.remote.server] (management task-7) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05123: [GSSAPI] No security layer selected but message length received
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateMessage(GssapiServer.java:245)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateResponse(GssapiServer.java:121)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:470)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:902)
> 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)
> {code}
> Error message is little bit confusing as previous log message claims AUTH security layer is selected.
> Looking into code does not reveal meaning to me neither.
> {code:java|title=GssapiServer.java}
> log.tracef("Client selected security layer %s, with maxBuffer of %d", selectedQop, maxBuffer);
> if (relaxComplianceChecks == false && selectedQop == QOP.AUTH && maxBuffer != 0) {
> throw log.mechNoSecurityLayerButLengthReceived(getMechanismName()).toSaslException();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3003) Elytron subsystem fails to boot if SecurityProvider cannot be loaded.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3003?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-3003:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Elytron subsystem fails to boot if SecurityProvider cannot be loaded.
> ---------------------------------------------------------------------
>
> Key: WFCORE-3003
> URL: https://issues.jboss.org/browse/WFCORE-3003
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomaz Cerar
>
> Trying to run secmgr testsuite under JDK9 results in
> {noformat}
> Caused by: java.util.ServiceConfigurationError: java.security.Provider: Provider com.sun.deploy.security.MozillaJSSProvider could not be instantiated
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581)
> at java.base/java.util.ServiceLoader.access$100(ServiceLoader.java:390)
> at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:799)
> at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721)
> at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1389)
> at java.base/java.lang.Iterable.forEach(Iterable.java:74)
> at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:201)
> at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:158)
> at org.wildfly.extension.elytron//org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> {noformat}
> and server doesn't start.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months