Bug 1080069 - (6.4.0) JSSE configuration in security domain is not persisted
Summary: (6.4.0) JSSE configuration in security domain is not persisted
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CLI
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: DR1
: EAP 6.4.0
Assignee: Alexey Loubyansky
QA Contact: Petr Kremensky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-24 15:48 UTC by Josef Cacek
Modified: 2019-08-19 12:44 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 900810 0 high CLOSED CLONE - adding JSSE to a security domain with the CLI does not persist 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker WFLY-3492 0 Major Resolved JSSE configuration in security domain wrongly acceptes empty parameters 2014-09-11 12:33:54 UTC

Internal Links: 900810

Description Josef Cacek 2014-03-24 15:48:36 UTC
When adding a jsse configuration in security domain through CLI, it's not persisted correctly.

Steps to reproduce:
* Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
/subsystem=security/security-domain=trust-domain:add
/subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
reload
* check standalone.xml, where should be sth. like
<security-domain name="trust-domain">
	<jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
</security-domain>

But there is:
<security-domain name="trust-domain">
	<jsse/>
</security-domain>

Comment 1 Josef Cacek 2014-03-24 15:56:35 UTC
I had a mistake in the second command, it should be:
/subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks}) 

Then it works.

Nevertheless it's probably still a bug, when the original command returns:
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Comment 2 Tomaz Cerar 2014-03-24 16:24:49 UTC
Only thing we can do here is improve validation for truststore & keystore attributes.

Comment 3 Chao Wang 2014-06-17 02:14:37 UTC
pull request https://github.com/jbossas/jboss-eap/pull/1465

Comment 4 JBoss JIRA Server 2014-09-02 11:58:25 UTC
Kabir Khan <kabir.khan> updated the status of jira WFLY-3492 to Reopened

Comment 5 Kabir Khan 2014-09-02 12:00:56 UTC
I closed https://github.com/jbossas/jboss-eap/pull/1465, as per the discussion on https://issues.jboss.org/browse/WFLY-3492. It is a CLI issue, assigning to Alexey

Comment 7 Alexey Loubyansky 2014-09-09 15:26:38 UTC
The PR is https://github.com/jbossas/jboss-eap/pull/1663

Comment 8 Kabir Khan 2014-09-10 15:52:27 UTC
As discussed on WFLY-3492 this is not an issue in the security subsystem, it is rather how jboss cli is parsing complex parameters


The usage of '=>' in truststore=>{...} is wrong
/subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks}) 

This ends up with truststore having a value of ">".


The correct syntax is to use '=', i.e. truststore={...}

Alexey's patch tightens up the validation to only allow the usage of '='/

Comment 9 JBoss JIRA Server 2014-09-11 12:33:55 UTC
Alexey Loubyansky <alex> updated the status of jira WFLY-3492 to Resolved

Comment 10 Petr Kremensky 2014-09-19 07:18:06 UTC
Verified on EAP 6.4.0.DR1.1, command from description won't pass the validation now.


Note You need to log in before you can comment on or make changes to this bug.