This specification describes main steps required for reworking Keystone2Keystone federation shipped in Juno release to improve user experience and avoid breaking Keystone’s architecture.
Keystone2Keystone federation delivered in Juno is currently marked as experimental and happens to miss few important points. Remote services are marked as regions in the Service Catalog, however they cannot be accessed with a token issued by local Identity Service. Apart from that not all required URLs are specified, forcing client to know them apriori. Therefore there is a need for re-architecting few aspects:
Keystone should be enhanced with new set of objects called Service Provider (/v3/OS-FEDERATION/service_providers/) where a trusted Service Providers are being configured. Information stored within such object should include information like:
Each Service Provider should be identified by a user specified system unique name, like already existing within Keystone ecosystem Identity Providers. Identity API should be enhanced with 5 new Service Provider operations:
Apart from that, Service Catalog should be extended with a new entry - service_providers. Users willing to burst into remote clouds would query that entry in the Service Catalog. Optionally, proper filtering of the Service Providers on a per user basis could be added (e.g. userA can burst into cloud1 and cloud2 whereas userB can burst into cloud2 and cloud3. Those constraints should be reflected in the Service Catalog proposed for each of the users).
As Keystone2Keystone federation was marked as experimental in the Juno release, a script/procedure for migrating service providers configured as regions to a first class service provider objects will not be provided.
Describe any potential security impact on the system. Some of the items to consider include:
It changes a Service Catalog but changes the structure in an additive fashion, to not break existing consumers, not the set of data exposed.
Please specify any changes to notifications. Be that an extra notification, changes to an existing notification, or removing a notification.
python-keystoneclient would need to be enhanced with operations for managing Service Provider objects, correctly interpret new structure of the Service Catalog , list all the remote clouds/services a user can burst into and reuse existing federated authentication plugins for the authentication process.
No performance impact.
No additional config options, new features would be enabled only after the federation extension is enabled.
All the changes must be documented: * New set of APIs * New structure of the Service Catalog
Etherpad site: https://etherpad.openstack.org/p/keystone2keystone