Keystone/Federation/Blueprint - Revision history

Mboorshtein: /* Single Identity Provider, Simple Client */

2013-12-09T02:27:32Z

‎Single Identity Provider, Simple Client

Mboorshtein: /* Guiding Principles */

2013-12-09T02:21:05Z

‎Guiding Principles

David Chadwick: /* Single Identity Provider, Simple Client */

2013-04-12T08:33:14Z

‎Single Identity Provider, Simple Client

David Chadwick: /* Glossary */

2013-04-12T08:23:47Z

‎Glossary

David Chadwick: /* Mode of Operation with Holder of Key Verification */

2013-04-12T08:16:36Z

‎Mode of Operation with Holder of Key Verification

David Chadwick: /* Single Identity Provider, Simple Client */

2013-04-12T08:14:39Z

‎Single Identity Provider, Simple Client

David Chadwick: /* Overview */

2013-04-12T07:32:23Z

‎Overview

David Chadwick: /* Federated Keystone */

2013-04-11T22:51:09Z

‎Federated Keystone

David Chadwick: /* Guiding Principles */

2013-04-11T22:49:13Z

‎Guiding Principles

Kwss: /* Implementation Status */

2013-02-25T12:02:21Z

‎Implementation Status

@@ Line 32: / Line 32: @@
 In this mode of operation, the user has a simple client and trusts Federated Keystone (FK) to behave correctly. A single IdP authenticates the user and provides all the user's authorisation attributes to FK.
-The downside of a simple client is that it is open to phishing attacks from evil Keystones, which redirect the client to a false IdP in step 10.However, the phishing can be nullified if the IdP uses a zero proof authentication mechanism, since in this case no secrets will be revealed by the simple client. Alternatively, a different protocol flow could be used in which the user contacts the IdP first and is then redirected by the IdP to Keystone (but this requires modification of the IdPs) or by using an intelligent client ([[AtAg]]) that knows how to contact the user's IdP itself.
+The downside of a simple client is that it is open to phishing attacks from evil Keystones, which redirect the client to a false IdP in step 10.However, the phishing can be nullified if the IdP uses a zero proof authentication mechanism, since in this case no secrets will be revealed by the simple client. Alternatively, a different protocol flow could be used in which the user contacts the IdP first and is then redirected by the IdP to Keystone (but this requires modification of the IdPs) or by using an intelligent client ([[AtAg]]) that knows how to contact the user's IdP itself.''Also, the use of a signed authnrequest will eliminate this scenario because the identity provider will reject the request if its not properly signed.''
 The swimlanes that pictorially show this protocol flow are available from dropbox [https://dl.dropboxusercontent.com/u/44986510/SwimlaneV3.pdf SwinLane Simple Client]
@@ Line 51: / Line 51: @@
 # The CVS calls the Directory to obtain the meta data of the IdP
 # The CVS returns the user's ID, set of identity attributes, and validity time to FK.
-# FK calls the Temporary User Management module which creates (or updates) the temporary entry for the user, and deletes any expired entries.
+# FK calls the Temporary User Management module which creates (or updates) the temporary entry for the user, and deletes any expired entries. ''What if instead of simply creating a temporary object we syncronize data.  This way the changes get updated but the account is available 'offline' for reporting?''
 # FK calls the Attribute Mapping Service to obtain the local set of attributes that are equivalent to the IdP provided identity attributes
 # FK adds these attributes to the temporary user entry

@@ Line 24: / Line 24: @@
 # Federated Keystone has a set of trust relationships with a defined set of external Identity Providers, Authentication Services and Attribute Authorities. The Keystone administrator enters these trusted entities into (an enhanced) Keystone Service Catalog.
 # The Attribute Mapper of Federated Keystone knows how attributes from these external trusted IdPs entities map into the local authz attributes known by the Cloud Service Providers. This information may be dynamically configured into Keystone by the Keystone administrator, or he may delegate this task to trusted administrators from the Identity Providers (see Blueprint https://blueprints.launchpad.net/keystone/+spec/mapping-distributed-admin). These mappings in effect create "virtual user entries" in Keystone.
-# Since external Identity Providers hold all the identity details of the users in their own databases, there is little point in Keystone duplicating this information. Consequently there is no longer any requirement to add users to Keystone's database. Instead, when a federated user contacts Keystone, a temporary entry is automatically created for him by the federation software, and this is only valid for the duration of the user's IdP generated token. When the entry times out, the entry is automatically deleted by the federation software. The temporary entry is a concrete instantiation of the virtual entry specified by the attribute mappings.
+# Since external Identity Providers hold all the identity details of the users in their own databases, there is little point in Keystone duplicating this information. Consequently there is no longer any requirement to add users to Keystone's database. Instead, when a federated user contacts Keystone, a temporary entry is automatically created for him by the federation software, and this is only valid for the duration of the user's IdP generated token. When the entry times out, the entry is automatically deleted by the federation software. The temporary entry is a concrete instantiation of the virtual entry specified by the attribute mappings.''What about audit trails and reporting?  If the user's data is removed once the session ends how do you report on user actions?''
 # A consequence of the above is that if Cloud Service Providers use Keystone generated User IDs in their access control lists, they should now ensure that the user's IdP issues a suitable unique ID that the federation software can convert into a concrete User ID that will be persistent across different sessions and will be same across the multiple temporary entries that will be created for the user (it could for example be an email address or the PID created by SAML IdPs).
-# Most existing authentication systems rely on usernames and passwords. We have to live with that. Consequently all existing federated authn systems are open to phishing attacks, whereby an evil SP redirects the user to a fake Identity Provider which then captures the user’s un/pw. In the current design the simple client is open to such attacks, whereas the intelligent client (Attribute Aggregator) is not. With the intelligent client, after the user decides which attributes and issuers to use, the Attribute Aggregator performs a directory lookup in the enhanced service catalog to find the issuer in order to obtain its metadata and make a direct request to it. In this case the user cannot be re-directed to a fake issuer by an evil SP and have his password stolen.
+# Most existing authentication systems rely on usernames and passwords. We have to live with that. Consequently all existing federated authn systems are open to phishing attacks, whereby an evil SP redirects the user to a fake Identity Provider which then captures the user’s un/pw. In the current design the simple client is open to such attacks, whereas the intelligent client (Attribute Aggregator) is not. With the intelligent client, after the user decides which attributes and issuers to use, the Attribute Aggregator performs a directory lookup in the enhanced service catalog to find the issuer in order to obtain its metadata and make a direct request to it. In this case the user cannot be re-directed to a fake issuer by an evil SP and have his password stolen.  ''Not sure this is really true.  While its not often used, SAML2 does define ways to specify what kind of authentication is required through the AuthnContextClassRef.  Especially in federal, this could be used to require kerberos or PIV/Certificate authentication.  The federation SP should be configurable to force a particular option.  Whether or not an IdP follows this standard can't be enforced by technology but there are audit services (such as those offered by Kantara) for certifying identity providers''
-# The user knows which cloud service he wishes to use, so ideally this should be his first port of call (and not Keystone or some external IdP). But given that the existing mode of operation is to contact Keystone first, then we keep this in the first implementation.
+# The user knows which cloud service he wishes to use, so ideally this should be his first port of call (and not Keystone or some external IdP). But given that the existing mode of operation is to contact Keystone first, then we keep this in the first implementation.''Good call.  Whenever I have a customer tell me users don't bookmark, they then complain bookmarks don't work...''
 == Single Identity Provider, Simple Client ==

@@ Line 34: / Line 34: @@
 The downside of a simple client is that it is open to phishing attacks from evil Keystones, which redirect the client to a false IdP in step 10.However, the phishing can be nullified if the IdP uses a zero proof authentication mechanism, since in this case no secrets will be revealed by the simple client. Alternatively, a different protocol flow could be used in which the user contacts the IdP first and is then redirected by the IdP to Keystone (but this requires modification of the IdPs) or by using an intelligent client ([[AtAg]]) that knows how to contact the user's IdP itself.
-The swimlanes that pictorially show this protocol flow are available from dropbox [http://dl.dropbox.com/u/44986510/SwinLaneSimpleClient.pdf SwinLane Simple Client]
+The swimlanes that pictorially show this protocol flow are available from dropbox [https://dl.dropboxusercontent.com/u/44986510/SwimlaneV3.pdf SwinLane Simple Client]
 # The user launches his federated client

@@ Line 214: / Line 214: @@
 FK – Federated Keystone. An enhanced version of Keystone which can federate with external Identity Providers. It is a proxy IDP, in that it is seen to be an IdP by the CSPs, but a service provider by the external IdPs.
 RIS  – Request Issuing Service. Given the output of the directory service,  issues the federated authentication and attribute request in the  appropriate protocol. There may be one RIS per federation protocol that  is supported.
-TIS – Token Issuing Service. Provides tokens to OG for it to give to the user/client
+TS – Token Service. This is the existing Keystone service that creates and validates scoped and unscoped tokens.
-TVS – Token Validation Service. Validates the tokens given to OG by the Cloud Service Providers
+TUM - Temporary User Management. This is the FK service that creates and deletes temporary entries for federated users.
 == MSc Dissertation ==
 An MSc dissertation describing the first prototype implementation can be downloaded from [http://dl.dropbox.com/u/44986510/Yanndissertation.pdf MSc Dissertation]. Please note that the current implementation is already an enhancement of this, and has started to remove many of the limitations of the original implementation. Nevertheless the disseration provides useful backgroung reading to implementors

← Older revision		Revision as of 08:16, 12 April 2013
Line 110:		Line 110:

	== Mode of Operation with Holder of Key Verification ==		== Mode of Operation with Holder of Key Verification ==
		+	''NOTE. There is currently no plan to implement Holder of Key, so the following should be regarded as an approximate outline only, and it may contain errors.''
		+
	In both of the single Identity Provider modes the assertions returned by the client to federated Keystone are bearer credentials. Furthermore the tokens (scoped and unscoped) produced by Keystone are also bearer credentials. This means that federated Keystone cannot be certain that the credentials produced by the IdP actually belong to the client that is presenting them. Furthermore, the cloud service providers cannot be sure that the token presented by the user actually belongs to the user. Using holder of key verification, the client creates a new key pair for each session, and the Identity Provider inserts the public key into the assertions. The client can then prove to federated Keystone (by signing a message) that it has the private key that corresponds to the public key in the assertions, and therefore that the assertions belong to it. Similarly the client can prove to the cloud services that the token belongs to it, by signing a message to the cloud service. The protocol steps are the same as before, but the protocol messages are different as stated below.		In both of the single Identity Provider modes the assertions returned by the client to federated Keystone are bearer credentials. Furthermore the tokens (scoped and unscoped) produced by Keystone are also bearer credentials. This means that federated Keystone cannot be certain that the credentials produced by the IdP actually belong to the client that is presenting them. Furthermore, the cloud service providers cannot be sure that the token presented by the user actually belongs to the user. Using holder of key verification, the client creates a new key pair for each session, and the Identity Provider inserts the public key into the assertions. The client can then prove to federated Keystone (by signing a message) that it has the private key that corresponds to the public key in the assertions, and therefore that the assertions belong to it. Similarly the client can prove to the cloud services that the token belongs to it, by signing a message to the cloud service. The protocol steps are the same as before, but the protocol messages are different as stated below.

@@ Line 32: / Line 32: @@
 In this mode of operation, the user has a simple client and trusts Federated Keystone (FK) to behave correctly. A single IdP authenticates the user and provides all the user's authorisation attributes to FK.
-The downside of a simple client is that it is open to phishing attacks from evil Keystones, which redirect the client to a false IdP in step 10.However, the phishing can be nullified if the IdP uses a zero proof authentication mechanism, since in this case no secrets will be revealed by the simple client. Alternatively the intelligent client ([[AtAg]]) can be used.
+The downside of a simple client is that it is open to phishing attacks from evil Keystones, which redirect the client to a false IdP in step 10.However, the phishing can be nullified if the IdP uses a zero proof authentication mechanism, since in this case no secrets will be revealed by the simple client. Alternatively, a different protocol flow could be used in which the user contacts the IdP first and is then redirected by the IdP to Keystone (but this requires modification of the IdPs) or by using an intelligent client ([[AtAg]]) that knows how to contact the user's IdP itself.
 The swimlanes that pictorially show this protocol flow are available from dropbox [http://dl.dropbox.com/u/44986510/SwinLaneSimpleClient.pdf SwinLane Simple Client]
@@ Line 45: / Line 45: @@
 # FK then calls the Request Issuing Service to create an authentication and attribute request in the appropriate format for the chosen Identity Provider.
 # FK returns the Identity Provider request message to the client, along with the address of the Identity Provider
-# The client passes the request to the Identity Provider
+# The client passes the request to the Identity Provider (either directly or via Keystone, both mechanisms are supported).
 # The Identity Provider asks the user to authenticate by its chosen method (out of scope of this proposal). It could be PKI based, Kerberos based, simple UN/PW, or OTP etc. How strongly the user is authenticated is reflected in the Level of Assurance (LoA) that is returned in the response (providing the protocol supports this).
 # The client passes the Identity Provider’s response to FK.
-# FK calls the Credential Validation Service (CVS) to validate the Identity Provider’s response
+# FK calls the protocol dependent Credential Validation Service (CVS) to validate the Identity Provider’s response.
-# The CVS calls the directory service to get the IdP's meta data in order to validate the response
+# The CVS calls the Directory to obtain the meta data of the IdP
-# The CVS returns the user's valid attributes to FK
+# The CVS returns the user's ID, set of identity attributes, and validity time to FK.
-# FK calls the Attribute Mapping Service to obtain the local set of attributes that are equivalent to the Identity Provider provided set.
+# FK calls the Temporary User Management module which creates (or updates) the temporary entry for the user, and deletes any expired entries.
-# FK calls the Token Issuing Service (TIS) to obtain an unscoped token for the user
+# FK calls the Attribute Mapping Service to obtain the local set of attributes that are equivalent to the IdP provided identity attributes
 # FK returns the unscoped token to the user, along with a list of tenants/projects available to the user
 # The user choses which tenant/project he wishes to use
 # The client passes the unscoped token and tenant/project to FK
-# FK calls the token validation service (TVS) to validate the unscoped token
+# FK calls the token service (TS) to validate the unscoped token and issue a scoped token for the user
 # FK returns the scoped token and list of cloud services at which this can be used to the client.
 # The client contacts the Cloud Service Provider with the scoped token, requesting the service
 # The Cloud Service Provider passes the scoped token to FK for validation
-# FK contacts the TVS to validate the token and gets the response
+# FK contacts the TS to validate the token and gets the response
 # FK sends the reply to the Cloud Service Provider
 # The Cloud Service Provider asks the PDP is the user is authorised for this request
@@ Line 75: / Line 75: @@
 Until Grizzly is officially released, the Keystone V3 implementation is only available directly from the authors at the University of Kent. Please email them to get your copy
 The Keystone V3 implementation implements the following blueprints
@@ Line 81: / Line 84: @@
 * Distributed Administration of the Attribute Mapping function [https://blueprints.launchpad.net/keystone/+spec/mapping-distributed-admin mapping-distributed-admin]
 * Federating multiple Keystone services together [https://wiki.openstack.org/wiki/Keystone/Delegation Delegation of Keystone Servers]
 == Single Identity Provider, Intelligent Client ==

← Older revision		Revision as of 07:32, 12 April 2013
Line 16:		Line 16:


−	The way it works is this. The user contacts Federated Keystone, which presents the user with the list of trusted IdPs. The user chooses his IdP from this list, and his client is redirected to it. The user then directly authenticates with his own IdP. Assuming the authentication is successful, the IdP returns an authentication and authorisation token to Keystone, which validates it, then swaps it for the normal unscoped and scoped Keystone tokens which allow the user to access the OpenStack services.	+	The way it works is this. The user contacts Federated Keystone, which presents the user with the list of trusted IdPs. The user chooses his IdP from this list, and his client is redirected to it. The user then directly authenticates with his own IdP. Assuming the authentication is successful, the IdP returns an authentication and authorisation token to Keystone (via the client), which validates it, then swaps it for the normal unscoped and scoped Keystone tokens which allow the user to access the OpenStack services. In this way, the OpenStack services are unaware of federation and cannot tell the difference between a federated or local user.

	== Guiding Principles ==		== Guiding Principles ==

@@ Line 3: / Line 3: @@
 Providing Federated Access to OpenStack Clouds
-Version: 1.2            Author: David W Chadwick                  Date: 22 February 2013
+Version: 1.3            Author: David W Chadwick                  Date: 12 April 2013
 __TOC__

@@ Line 19: / Line 19: @@
 == Guiding Principles ==
-# Each cloud service keeps it existing tenants/projects and roles for authz, and passes the bulk of the work off to Federated Keystone to do the heavy lifting (i.e. interacting with the Identity Providers, validating the various credentials, mapping the attributes into the ones understood by the service etc.).
+# Each cloud service keeps it existing tenants/projects and roles for authz, and passes the bulk of the work off to Federated Keystone to do the heavy lifting (i.e. interacting with the Identity Providers (IdPs), validating the various credentials, mapping the attributes into the ones understood by the service etc.).
-# There can be thousands of Identity Providers/Attribute Authoritys with millions of different attributes. It would be too complex for Cloud Service Providers (CSPs) to have to create authz policies based on these. Consequently each Cloud Service Provider has its own limited set of attributes and roles, and only trusts Keystone to issue them. It trusts Keystone to map between the externally provided attributes and the internally understood ones. (In fact the CSPs are unaware of whether Keystone is federated or not.) Federated Keystone is the only known (and trusted) Identity Provider to the Cloud Service Providers. In the non-federated world the architecture degenerates to the current Keystone implementation.
+# There can be thousands of Identity Providers/Attribute Authorities with millions of different attributes. It would be too complex for Cloud Service Providers (CSPs) to have to create authz policies based on these. Consequently each Cloud Service Provider has its own limited set of authz attributes (currently roles, projects and domains), and only trusts Keystone to issue them. It trusts Keystone to map between the externally provided attributes and the internally understood ones. (In fact the CSPs are unaware of whether Keystone is federated or not, or whether the users were authenticated by Keystone or some external IdP.) Federated Keystone is the only known (and trusted) Identity Provider to the Cloud Service Providers. In the non-federated world the federated architecture degenerates to the current Keystone implementation.
-# Consequently, all Identity Provider/Attribute Authority issued attributes/roles must be globally identifiable, either via their unique name/type (e.g. a URN) or via the name of their issuer (DNS name) and their local name (see Appendix 2).
+# Consequently, all Identity Provider/Attribute Authority issued attributes/roles must be identifiable throughout the federation, either via their unique name/type (e.g. a URN) or via the name of their issuer (DNS name) and their local name (see Appendix 2).
-# Federated Keystone has a set of trust relationships with a set of external Identity Providers, Authentication Services and Attribute Authoritys. The Keystone administrator enters these trusted entities into (an enhanced) Keystone Service Catalog. The Attribute Mapper of Federated Keystone knows how attributes from these external entities map into the local attributes known by the Cloud Service Providers. This information may be configured into the Keystone administrator, or he may delegate this task to trusted administrators from the Identity Providers (see Blueprint https://blueprints.launchpad.net/keystone/+spec/mapping-distributed-admin).
+# Federated Keystone has a set of trust relationships with a defined set of external Identity Providers, Authentication Services and Attribute Authorities. The Keystone administrator enters these trusted entities into (an enhanced) Keystone Service Catalog.
-# Since external Identity Providers hold all the identity details of the users in their own databases, there is little point in Keystone duplicating this information. Consequently there is no longer any requirement to add users to Keystone's database. Instead, when a federated user contacts Keystone, a temporary entry is automatically created for him by the federation software, and this is only valid for the duration of the user's IdP generated token. When the entry times out, the entry is automatically deleted by the federation software. A consequence of this is that Cloud Service Providers should no longer use Keystone generated User IDs in their access control lists, but instead should use a persistent identity attribute of the user, such as his email address or the PID created by SAML IdPs.
+# The Attribute Mapper of Federated Keystone knows how attributes from these external trusted IdPs entities map into the local authz attributes known by the Cloud Service Providers. This information may be dynamically configured into Keystone by the Keystone administrator, or he may delegate this task to trusted administrators from the Identity Providers (see Blueprint https://blueprints.launchpad.net/keystone/+spec/mapping-distributed-admin). These mappings in effect create "virtual user entries" in Keystone.
 # Most existing authentication systems rely on usernames and passwords. We have to live with that. Consequently all existing federated authn systems are open to phishing attacks, whereby an evil SP redirects the user to a fake Identity Provider which then captures the user’s un/pw. In the current design the simple client is open to such attacks, whereas the intelligent client (Attribute Aggregator) is not. With the intelligent client, after the user decides which attributes and issuers to use, the Attribute Aggregator performs a directory lookup in the enhanced service catalog to find the issuer in order to obtain its metadata and make a direct request to it. In this case the user cannot be re-directed to a fake issuer by an evil SP and have his password stolen.
 # The user knows which cloud service he wishes to use, so ideally this should be his first port of call (and not Keystone or some external IdP). But given that the existing mode of operation is to contact Keystone first, then we keep this in the first implementation.

@@ Line 69: / Line 69: @@
 The simple client mode has now been fully implemented for both the Keystone V2 and V3 APIs, and several existing OpenStack clients have been enhanced to support federated access to Keystone. More enhanced clients are expected to follow in due course.
-The Keystone V2 implementation is available from here [insert GIT URL HERE]
+The Keystone V2 implementation is available from [https://github.com/kwss/keystone.git here]
 Until Grizzly is officially released, the Keystone V3 implementation is only available directly from the authors at the University of Kent. Please email them to get your copy