Tripleo Heat Templates allow the deployer to customize the controller deployment by setting values in the controllerExtraConfig section of the stack configuration. However, Quickstart already makes use of this in the file /tmp/deploy_env.yaml, so if you want to continue to customize, you need to work with this file.

What I did is ran quickstart once, through to completion, to make sure everything worked, then tore down the overcloud like this:

. ./stackrc
heat stack-delete overcloud

Now, I want to set a bunch of config values in the /etc/keystone.conf files distributed to the controllers.

1. Modify deploy-overcloud.sh so that the deploy-env.yaml file is not in tmp, but rather in stack, so I can keep track of it. Ideally, this file would be kept in a local git repo under revision control.
2. Remove the lines from deploy-overcloud.sh that generate the /tmp/deploy-env.yml file. This is not strictly needed, but it keeps you from accidentally losing changes if you edit the wrong file. OTOH, being able to regenerate the vanilla version of this file is useful, so maybe just comment out the generation code.
3. Edit /home/stack/deploy_env.yaml appropriately.

My version of overcloud-deploy.sh

#!/bin/bash

# Simple overcloud deploy script

set -eux

# Source in undercloud credentials.
source /home/stack/stackrc

# Wait until there are hypervisors available.
while true; do
    count=$(openstack hypervisor stats show -c count -f value)
    if [ $count -gt 0 ]; then
        break
    fi
done

deploy_status=0

# Deploy the overcloud!
openstack overcloud deploy --debug --templates --libvirt-type qemu --control-flavor oooq_control --compute-flavor oooq_compute --ceph-storage-flavor oooq_ceph --timeout 90 -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e $HOME/network-environment.yaml --control-scale 3 --neutron-network-type vxlan --neutron-tunnel-types vxlan -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml --ntp-server pool.ntp.org -e /home/stack/deploy_env.yaml   "$@"|| deploy_status=1

# We don't always get a useful error code from the openstack deploy command,
# so check `heat stack-list` for a CREATE_FAILED status.
if heat stack-list | grep -q 'CREATE_FAILED'; then
    deploy_status=1

    for failed in $(heat resource-list \
        --nested-depth 5 overcloud | grep FAILED |
        grep 'StructuredDeployment ' | cut -d '|' -f3)
    do heat deployment-show $failed > failed_deployment_$failed.log
    done
fi

exit $deploy_status

/home/stack/deploy_env.yaml

parameter_defaults:
  controllerExtraConfig:
    keystone::using_domain_config: true
    keystone::config::keystone_config:
      identity/domain_configurations_from_database:
        value: true
      auth/methods:
        value: external,password,token,oauth1,saml2
      federation/trusted_dashboard:
        value: https://openstack.young-dell-t1700.test/dashboard/auth/websso/
      federation/sso_callback_template:
        value: /etc/keystone/sso_callback_template.html
      federation/remote_id_attribute:
        value: MELLON_IDP

    # In releases before Mitaka, HeatWorkers doesn't modify
    # num_engine_workers, so handle via heat::config 
    heat::config::heat_config:
      DEFAULT/num_engine_workers:
        value: 1
    heat::api_cloudwatch::enabled: false
    heat::api_cfn::enabled: false
  HeatWorkers: 1
  CeilometerWorkers: 1
  CinderWorkers: 1
  GlanceWorkers: 1
  KeystoneWorkers: 1
  NeutronWorkers: 1
  NovaWorkers: 1
  SwiftWorkers: 1

Once you deploy, you can see what Heat records for those values with:

openstack stack show overcloud -f json | jq '.parameters["controllerExtraConfig"] '
"{u'heat::api_cfn::enabled': False, u'heat::config::heat_config': {u'DEFAULT/num_engine_workers': {u'value': 1}}, u'keystone::config::keystone_config': {u'federation/sso_callback_template': {u'value': u'/etc/keystone/sso_callback_template.html'}, u'identity/domain_configurations_from_database': {u'value': True}, u'auth/methods': {u'value': u'external,password,token,oauth1,saml2'}, u'federation/trusted_dashboard': {u'value': u'https://openstack.young-dell-t1700.test/dashboard/auth/websso/'}, u'federation/remote_id_attribute': {u'value': u'MELLON_IDP'}}, u'keystone::using_domain_config': True, u'heat::api_cloudwatch::enabled': False}"

SSH in to the controller node and you can check the section of the keystone conf file.

[federation]

#
# From keystone
#

# Entrypoint for the federation backend driver in the keystone.federation
# namespace. (string value)
#driver = sql

# Value to be used when filtering assertion parameters from the environment.
# (string value)
#assertion_prefix =

# Value to be used to obtain the entity ID of the Identity Provider from the
# environment (e.g. if using the mod_shib plugin this value is `Shib-Identity-
# Provider`). (string value)
#remote_id_attribute = 
remote_id_attribute = MELLON_IDP

# A domain name that is reserved to allow federated ephemeral users to have a
# domain concept. Note that an admin will not be able to create a domain with
# this name or update an existing domain to this name. You are not advised to
# change this value unless you really have to. (string value)
#federated_domain_name = Federated

# A list of trusted dashboard hosts. Before accepting a Single Sign-On request
# to return a token, the origin host must be a member of the trusted_dashboard
# list. This configuration option may be repeated for multiple values. For
# example: trusted_dashboard=http://acme.com/auth/websso
# trusted_dashboard=http://beta.com/auth/websso (multi valued)
trusted_dashboard=https://openstack.young-dell-t1700.test/dashboard/auth/websso/
#trusted_dashboard =

# Location of Single Sign-On callback handler, will return a token to a trusted
# dashboard host. (string value)
#sso_callback_template = /etc/keystone/sso_callback_template.html
sso_callback_template = /etc/keystone/sso_callback_template.html