This session will include the following subject(s):
Future Enhancements to Keystone Federation Support:
In IceHouse we created a first draft of Federation support for Keystone, in this session, we would like stakeholder feedback in the following areas: How can we improving the mapping function? as it is currently limited to groups and user. Can we remove the dependency of requiring an unscoped token? Can we support projects and domains in mapping assertions? Is there another federation protocol that we would like to support?
(Session proposed by Steve Martinelli)
Federation within a private cloud:
For large private clouds (e.g. many geographical dispersed regions), we don't currently have a federated solution. Out of the box, the standard deployment would be a central keystone, with other endpoints in the regions. Alternatively, some companies create their own pseudo-federation by placing a keystone in each regain and doing DB replication (with throttles depending on which table you are talking about).
What is really required is to have some kind of "keystone trusting", so that a token issued by one keystone would be accepted by another within the private cloud. This is different to the Public Cloud Federation model, where it is acceptable to re-authenicate (with a SAML assertion) as you hit each new OpenStack cloud.
