The Newton Summit is behind us, and we have six months to prepare for the next release in both upstream OpenStack and RDO. Here is my attempt to build a prioritized list of the large tasks I want to tackle in this release.

1. Federation:  We need to test RDO against Several identity providers (IdP), to include Shibboleth, Keycloak, and Ipsilon.  In order to do this, we need a way to install a test version of the IdP in a virtual machine along-side the undercloud in a Tripleo deploy.  Since it looks like instack and tripleo-quickstart are converging, I’ll probably close this task out with quickstart.  The undercloud setup of quickstart assumes only a single machine (non-ha) and I want to make that set up a second, so the machine is visible to both the outside world and the overcloud.  I already have Ansible roles for deploying Keycloak and Ipsilon in the Rippowam repo that should be easily extensible to Shibboleth as well.
2. Tripleo LDAP Configuration:  Continuing on the track of configuration identity from Tripleo, we want to be able to automate the steps to integrate LDAP into a Keystone server managed by Tripleo.  Like the Federation steps above and the policy work below, the m,ain effort here is making sure that configuration changes can be preserved across redeploys and will be properly synchronized in an HA deployment.
   1. A prerequisite for domain specific backens is that the deploy uses the V3 Keystone API everywhere. We need to test and confirm that this is the case, and fix any places where that has not been done.
3. FreeIPA:  There is much of Tripleo that cannot be secured without an identity provider.  Most essential is to have a sound PKI strategy, but beyond that, we need a way to secure both the undercloud and the overcloud VMs, provide identity for each of them, and set proper access controls.  While FreeIPA will not be required for use with Tripleo, it will be possible to make use of a FreeIPA server. To ensure that it is trivial to make a FreeIPA server available for deployers that want one, the additional VM described above can be used to install the FreeIPA server.  The LDAP configuration above can make use of the LDAP backend, or a deploy  can use Federation via SSSD and Kerberos.
4. Token Revocation: Convert the Keystone revocation events code to use a linear search in the list instead of the current Tree code.  While the Tree code was an interesting approach, it proved to be both too complex for most developers to understand, and not to perform too well.  In addition, the current code performs revocation for many events such a s project deactivation and user deletion which are better checked in the objects themselves during token validation.  Removing these redundant rules should make the revocation test go very fast, and they will be performed implicitly during re-population of Fernet tokens anyway.
5. Fernet Tokens:  While UUID tokens will not be going away this release, there seems to be little reason to make them the default provider, when we really want people to move to Fernet.  There are  still a few issues with test that were not run when Fernet was not the default, including some time related issues that I hope will be flushed out with the simplification of the revocation code listed above.  Fernet will be the default for Tripleo, if not for Keystone itself.
6. Oslo messaging identities:  Before we can write ACLs on what service can speak to what, we need to be able to identify the senders and receivers on the queues and topics.  We can do this with no impact to performance by creating a Rabbit user for each service, and one rabbit user for each hypervisor.  This will need to be done for both Devstack and Tripleo.
7. Policy Customization:  There are several reasons why we are not distributing policy files from the Keystone server.  However, deployers still need to modify policy files, and to do so in a non-surprising way.  I discussed this with the Tripleo team, and the consensus seems to be that we can deploy the policy files as “deployment artifacts” which is, essentially, a tarball with the files inside in their end-locations; e.g. /etc/keystone/policy.json for Keystone.  We should be able to describe a full cycle that applies to all of the deployment tools, not just Tripleo.  While this deserves its own post, the skeleton is:
   1. harvesting the initial policy files from the controller nodes,
   2. packing up the policy archive
   3. storing it where the orchestration engine can find it,
   4. The operator fetching it from the store
   5. operator customization and testing
   6. storing the updated archive
   7. Redeploy of the overcloud with the new policy
8. Close Bug 968696:  We made some progress on this at the summit.  The most interesting aspect will be a hack that adds “is_admin_project=True” to all tokens that are requesting the “admin” role IFF the admin project is not set in the Keystone configuration.  This will allow the services to update policy files such that, when the configuration option is set, the “admin” role will be properly scoped.  Adding this option to Keystone will allow us to submit changes to all of the other service policy files.

I am supervising a couple other efforts.

1. Unified Delegation:  Right now, the only way a non-admin user can delegate a role to another user is via trust.  But most users should not have to execute trusts in order to perform mundane operations.  Unified delegation is a way to extend the redelegation properties of trusts to the basic role assignment process.  The work for this has been well underway for a couple releases, and we should be able to finish it up in Newton.  This work is mostly being done by Alexander Makarov.
   1. Allow a user to be able to explicitly request a single role in a token.  This will be useful for limiting exposure.  For example, a user with an Admin role will be able to request a token with only the Member role on it when talking to a third party application.
2. Python3 LDAP:  The big thing keeping Keystone from being run on Python3 is the LDAP library. python-ldap is Python 2 only, and the maintainer does not plan on making it python3 compatible.  The original plan was to use ldap3, a pure python implementation of an LDAP client, but the protocol is complex enough that we are looking instead to use a fork of python-ldap call pyldap instead.  However, since so much of the ldap3 work is already done, we might end up having both implementations in parallel and testing.  The ldap3 based code is much cleaner, but that cleanup could be applied to pyldap as well. This work is being done by Kristi Nikolla and Roxana Gherle.
3. Federation Shadow Users:  There is a long standing pain point that administrators must work with userids but only know usernames.  This problem is worse in Federation, where the users might not even have userids yet, as they have never authenticated.  During the design summit, we came up with a plan for a handful of new APIs.  All of these APIs would have the input values for a mapping in the payload, delivered as a dictionary.  Ron De Rose.
   1. Query the results of a mapping call
   2. Check to see if a Federated user is in the shadow table
   3. Initialize an entry in the Shadow user table

There are a couple efforts that other members of my team are working on that are complementary to the the above list.

1. TLS Everwhere.   Juan Antonio Osorio Robles and Rob Crittenden.
   1. Network configuration for
      1. HTTPS between each server
      2. TLS enabled fort the message broker
      3. TLS/LDAPS for LDAP
      4. TLS to the Database
   2. Establishing Certmonger as the tool to provider certificates
   3. Setting up a Selfsigniong approach for Devstack
   4. Allowing for multiple CAs for deployments
      1. Dogtag/FreeIPA
      2. Anchor
2. Autoregistration of VMs with an Identity provider. Rob Crittenden.  This one has proven to be an contentious issue, as the hooks inside Nova that we were depending on to implement it got deprecated….due to team members submitting bug reports.  Discussions at the summit are pointing at an approach based on modifing the metadata server.  Michael Still has an idea he is writing up for a general purpose mechanism.