Federated Service Providers in Keystone¶
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:
regionsshould not be used for indicating remote service a client can burst into.
a client should be able to fetch all required information needed for bursting into remote clouds (for instance
authURLas well as urls specific for a SAML2 authentication workflow.)
Keystone should be enhanced with new set of objects called
/v3/OS-FEDERATION/service_providers/) where a trusted Service Providers
are being configured. Information stored within such object should include
authURL- an url where client can get his token once he has authenticated via SAML2 federated protocol. Example:
a specific url - usually a dedicated url where assertions are being sent. Example:
Service Provider should be identified by a user specified system
unique name, like already existing within Keystone ecosystem
Identity API should be enhanced with 5 new
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.
can burst into
userB can burst into
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
a first class
service provider objects will not be provided.
Keep using regions as remote endpoint where users can burst into, however this would presume users know apriori at least
authURLof the remote services as well federated protocol to be used.
Accept SAML2 Service Provider Metadata file as an input required for creating
Service Providerobjects. This means the user would upload Service Provider Metadata as a request body while creating and updating information about
Service Providers. From the deployer/admin perspective it is a significant easement, especially when lots of Service Providers are going to be configured (100s or more) - admin simply needs to upload auto-generated Metadata file, instead of making up URL-safe
Service Provider. This would however change the way how
Service Providerobjects would be identified. This could be UUID hexadecimal values generated by
Keystoneinstead of user specified
idvalues.For a better
Service Providermanagement HTTP GET call should be enhanced with filters where URL-safe
entityIDwould be specified, for instance
Describe any potential security impact on the system. Some of the items to consider include:
Does this change touch sensitive data such as tokens, keys, or user data?
It changes a Service Catalog but changes the structure in an additive fashion, to not break existing consumers, not the set of data exposed.
Does this change alter the API in a way that may impact security, such as a new way to access sensitive information or a new way to login?
Does this change involve cryptography or hashing?
Does this change require the use of sudo or any elevated privileges?
Does this change involve using or parsing user-provided data? This could be directly at the API level or indirectly such as changes to a cache layer.
Can this change enable a resource exhaustion attack, such as allowing a single API interaction to consume significant server resources? Some examples of this include launching subprocesses for each connection, or entity expansion attacks in XML.
Please specify any changes to notifications. Be that an extra notification, changes to an existing notification, or removing a notification.
Other End User Impact¶
python-keystoneclient would need to be enhanced with operations for
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
No performance impact.
Other Deployer Impact¶
No additional config options, new features would be enabled only after the
federation extension is enabled.
Marek Denis <marek-denis>
Rodrigo Duarte <rodrigods>
- Other contributors:
Service Providerobjects along with relevant APIs
service_providersobject to the Service Catalog
Document implemented changes
All the changes must be documented: * New set of APIs * New structure of the Service Catalog
Etherpad site: https://etherpad.openstack.org/p/keystone2keystone