We have had the ability for keystone to use a federated identity provider since the Icehouse release. This is done using Apache modules like mod_shib or mod_auth_mellon. Unfortunately they have some key limitations:
This works fine for small clouds where a single IdP is configured at bootstrap time, but falls down in a larger cloud where those IdPs may be a little more dynamic.
The following things would be changed in keystone:
There are a couple of alternatives:
Do nothing, but this doesn’t make anyone happy.
Fix mod_shib/mod_auth_mellon to be more dynamic.
It is certainly possible for a C expert to make the modules reload their configuration more dynamically. It’s having APIs to manage the config that makes this much more difficult. keystone would need to write the XML config files and distribute then to all keystone nodes.
This code will be managing the negotiation between keystone and the IdP. There is certainly an impact if we get it wrong. In the worst case we are opening a new attack vector.
We are also making use of the pysaml2 library to do the heavy lifting. There is extra onus on us to make sure that code is correct and have a good process for dealing with security issues.
We will be using x509 certificates to validate and sign SAML documents. Those certificates will need to be managed and rotated by the operator. (This is no different for operators that are currently using an Apache module for federation.)
We may possibly have notifications for some IdP interactions. Nothing concrete yet.
End users should not be able to tell that we are providing the federation bits. It will all be transparent to them.
This should have no direct significant performance impact. Signing/verifying documents may block a process a little longer, but that shouldn’t impact keystone all that much.