Keystone/Federation/Blueprint

= Federated Keystone = Providing Federated Access to OpenStack Clouds

Version: 1.3           Author: David W Chadwick                  Date: 12 April 2013

Overview
The overall idea is that Keystone will no longer be the only identity service for OpenStack services, but instead, there will be a wide range of identity services distributed around the Internet, called Identity Providers (IdPs). The advantages of using external identity providers are numerous, and include:


 * there is no longer any need to provision user entries in Keystone, since the user entries already exist in the IdP's databases.
 * there is no need to build additional authentication mechanisms into Keystone, since the IdPs take care of authenticating their own users using whichever technologies they deem to be appropriate. So multiple authentication technologies are already in use.
 * there is no need to support users who forget their passwords. The IdPs already do this.
 * multiple collaborating organisations can quickly share the same cloud services by each one using their own local IdP to authenticate their users.
 * it provides single sign on to the user, who can use the same set of credentials with his IdP to access many different services on the Internet.

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

 * 1) 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.).
 * 2) 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.
 * 3) 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).
 * 4) 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.
 * 5) 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.
 * 6) 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?
 * 7) 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).
 * 8) 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
 * 9) 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
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.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 SwinLane Simple Client


 * 1) The user launches his federated client
 * 2) The client contacts federated Keystone (FK)
 * 3) FK retrieves the set of trusted Identity Providers from the directory service (enhanced service catalog)
 * 4) FK sends the set of Identity Providers to the client in response to message 2.
 * 5) The user chooses which Identity Provider he wishes to use
 * 6) The client returns the chosen Identity Provider to FK.
 * 7) FK performs a directory lookup on this Identity Provider, and obtains its metadata
 * 8) FK then calls the Request Issuing Service to create an authentication and attribute request in the appropriate format for the chosen Identity Provider.
 * 9) FK returns the Identity Provider request message to the client, along with the address of the Identity Provider
 * 10) The client passes the request to the Identity Provider (either directly or via Keystone, both mechanisms are supported).
 * 11) 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).
 * 12) The client passes the Identity Provider’s response to FK.
 * 13) FK calls the protocol dependent Credential Validation Service (CVS) to validate the Identity Provider’s response.
 * 14) The CVS calls the Directory to obtain the meta data of the IdP
 * 15) The CVS returns the user's ID, set of identity attributes, and validity time to FK.
 * 16) 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?
 * 17) FK calls the Attribute Mapping Service to obtain the local set of attributes that are equivalent to the IdP provided identity attributes
 * 18) FK adds these attributes to the temporary user entry
 * 19) FK calls the Token Service (TS) to obtain an unscoped token for the user
 * 20) FK returns the unscoped token to the user, along with a list of tenants/projects available to the user
 * 21) The user choses which tenant/project he wishes to use
 * 22) The client passes the unscoped token and tenant/project to FK
 * 23) FK calls the token service (TS) to validate the unscoped token and issue a scoped token for the user
 * 24) FK returns the scoped token and list of cloud services at which this can be used to the client.
 * 25) The client contacts the Cloud Service Provider with the scoped token, requesting the service
 * 26) The Cloud Service Provider passes the scoped token to FK for validation
 * 27) FK contacts the TS to validate the token and gets the response
 * 28) FK sends the reply to the Cloud Service Provider
 * 29) The Cloud Service Provider asks the PDP is the user is authorised for this request
 * 30) The Cloud Service Provider sends the response to the client
 * 31) The client makes additional requests to the Cloud Service Provider using the same scoped token, goto 25.

Implementation Status
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

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

A public demo is available here http://sec.cs.kent.ac.uk/demos Choose demo number 8.

The Keystone V3 implementation implements the following blueprints
 * Adding IdPs to an enhanced Keystone Service Catalog adding-idps-to-service-catalog
 * Mapping attributes from Identity Providers to internal OpenStack attributes role-mapping-service-keystone
 * Distributed Administration of the Attribute Mapping function mapping-distributed-admin
 * Federating multiple Keystone services together Delegation of Keystone Servers
 * Handling ACLs that use UserIDs in Federated Keystone acls-userids-federation
 * Temporary User Creation in Federated Keystone temp-user-creation

Single Identity Provider, Intelligent Client
''NOTE. There is currently no plan to implement the Intelligent Client, so the following should be regarded as an approximate outline only, and it may contain errors.''

This mode protects the client from phishing attacks by evil Keystones and other services since the intelligent client decides for itself how to contact the user’s Identity Provider. It therefore cannot be redirected to an evil CSP. The swimlane diagram for the Intelligent Client can be found here attachment:SwimlaneIntelClient.pdf


 * 1) The user types in his request to the client
 * 2) The user contacts the Cloud Service to request a service
 * 3) The Cloud Service Provider sends the client its attribute requirements policy (ARP) and the address of the Openstack Gateway to contact.
 * 4) The client passes the ARP to Openstack Gateway
 * 5) Openstack Gateway calls the Attribute Mapping Service to convert the ARP into one that contains the external attributes and Identity Providers that may be capable of fulfilling the policy.
 * 6) Openstack Gateway passes the set of external attributes and Identity Providers back to the client as an External Attributes Requirements Policy (EARP).
 * 7) The client passes the policy to its intelligent Attribute Aggregation component (AtAg) which filters the policy against the user’s attributes.
 * 8) Attribute Aggregator asks the user which of his possible attributes and Identity Providers he wants to use to access the Cloud Service Provider e.g. he may have several roles, credit cards, email addresses etc. and can choose between them. He may have several Identity Providers that can fulfil the policy. The user chooses his preferred Identity Provider and attributes.
 * 9) Attribute Aggregator contacts the Directory service, passing it the name of the user’s chosen Identity Provider, to find out the latest contact details (meta information) of it. Note. If Attribute Aggregator has this information configured into it, then this step can be omitted.
 * 10) Attribute Aggregator contacts the Request Issuing Service (RIS) to obtain a properly formatted Authn request in the correct protocol. It is returned a binary blob (the Identity Provider authentication and attribute request message). The attribute request contains the mapped set of attributes required by the cloud service. Note that the intelligent Attribute Aggregator may have the RIS as a built in service.
 * 11) Attribute Aggregator contacts the chosen Identity Provider, sending it the binary blob.
 * 12) The Identity Provider authenticates the user 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).
 * 13) Having identified the user, the Identity Provider returns the authentication and attribute assertion to Attribute Aggregator (as a binary blob)
 * 14) Attribute Aggregator passes this response to the client
 * 15) The client passes the assertion to Openstack Gateway.
 * 16) Same as Single Identity Provider, Simple Client from now onwards

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.

Note that the whole token model and structure that Keystone currently uses needs enhancing to overcome its current multiple limitations (replayable, copyable, escalation of privileges etc.) but this is outside the scope of the current blueprint.
 * For Single Identity Provider, Simple Client, the procedure is the same until step 11 when the client creates a new key pair for the user and includes the public key in the authentication exchange with the Identity Provider. In step 12 the Identity Provider includes the public key in the response that it creates for federated Keystone. In step 13 the client signs the message containing the Identity Provider’s response. This allows federated Keystone to prove, in step 14, that the client is the rightful owner of the Identity Provider’s response. In step 18 Keystone's token issuing service inserts the user's public key into the token, and in step 21 the client signs the request message to Keystone, which validates it in step 22. This process is repeated again in steps 23 to 27, so that now the cloud service provider can validate that the client is the rightful owner of the token.


 * Note that this text has not been corrected. For Single Identity Provider, Intelligent Client, the procedure is the same until step 11 when Attribute Aggregator creates a new key pair for the user, and includes the public key in the user’s authentication exchange with the Identity Provider. In step 12 the Identity Provider includes the public key in the response that it creates for the Openstack Gateway. In step 13 Attribute Aggregator passes the new key pair back to the client along with the Identity Provider’s response. In step 14 the client signs the message containing the Identity Provider’s response with its private key. This allows Openstack Gateway to prove that the client is the rightful owner of the Identity Provider’s response.

Mode of Operation using an Authentication Service and Attribute Authority
''NOTE. There is currently no plan to implement a separate Authentication Service and Attribute Authority, so the following should be regarded as an approximate outline only, and it may contain errors.''

In this mode of operation the attribute authority uses an external authentication service to authenticate clients who want to retrieve attributes from it. Attribute Authorities work in the following way. An unknown user contacts the Attribute Authority for a service, and the Attribute Authority redirects the user to one of its trusted Authentication Services (or Identity Providers). The user must already have a relationship with one of these trusted authentication services. The user authenticates to the Authentication Service (or Identity Provider) and the Authentication Service returns to the Attribute Authority an authentication assertion containing a persistent ID (PID). From now on, the Attribute Authority will know this user as PID issued by Authentication Service. The user pays the Attribute Authority for the service and the Attribute Authority issues the user with an attribute, which it stores permanently in its database along with the user’s ID (PID@AS). Whenever the user wishes to retrieve its attribute, it must contact the Attribute Authority, be redirected to the same Authentication Service (or Identity Provider), authenticate, and then the Attribute Authority can validate the identity of the user (PID@AS) and issue it with an attribute assertion, or possibly with an authentication and attribute assertion (depending upon whether the Attribute Authority is willing to underwrite the authentication performed by the Authentication Service. Clearly it is to some extent, otherwise it would not issue the attribute assertion. See also Appendix 1). The user ID in the attribute (and authentication) assertion may be a random ID, the same PID as that issued by the Authentication Service, or a different PID generated by the Attribute Authority (in which case the Attribute Authority will need to keep the PID mappings). The user should be able to choose which type of ID it requires in the attribute assertion.

The swimlanes for this protocol flow can be found here attachment:SwimlaneAA+AS.pdf


 * 1) The user contacts the Cloud Service to request a service
 * 2) The Cloud Service Provider sends the client its attribute requirements policy (ARP) and the address of the Openstack Gateway to contact.
 * 3) The client passes the ARP to Openstack Gateway
 * 4) Openstack Gateway calls the Attribute Mapping Service to convert the ARP into one that contains the external attributes, Attribute Authoritys, Authentication Services and Identity Providers that may be capable of fulfilling the policy. Note that an Authentication Service will only occur in this policy if the Openstack Gateway requires a PID for the user from a trusted Authentication Service (and does not trust the Attribute Authority to issue one). Note that if the ARP is fixed then the mapping can also be fixed.
 * 5) Openstack Gateway passes the set of external attributes, Attribute Authoritys, Authentication Services and Identity Providers back to the client as an External Attributes Requirements Policy (EARP).
 * 6) The client passes the policy to its intelligent Attribute Aggregation component (AtAg) which filters the policy against the user’s attributes.
 * 7) Attribute Aggregator asks the user which of his possible attributes (and issuers) he wants to use to access the Cloud Service Provider e.g. he may have several roles, credit cards, email addresses etc. and can choose between them. He may have several Identity Providers and Attribute Authoritys that can fulfil the attribute requirements of the policy. The user chooses his preferred attributes (and its issuer).
 * 8) Attribute Aggregator contacts the Directory service, passing it the name of the user’s chosen Attribute Authority, to find out the latest contact details (meta information) of it. Note. If Attribute Aggregator has this information configured into it, then this step can be omitted.
 * 9) Attribute Aggregator contacts the Request Issuing Service (RIS) to obtain a properly formatted Attribute request in the correct protocol. It is returned a binary blob (the attribute request message). The attribute request contains the set of attributes required by Openstack Gateway. Note that the intelligent Attribute Aggregator may have the RIS as a built in service.
 * 10) Attribute Aggregator contacts the chosen Attribute Authority, sending it the binary blob.
 * 11) The Attribute Authority asks Attribute Aggregator to authenticate via its Authentication Service, passing it the login URL. The Attribute Authority may only use one Authentication Service, or it may use several in which case it will ask Attribute Aggregator (i.e. the user) to choose which Authentication Service it normally uses.
 * 12) The user chooses which Authentication Service he wants to use
 * 13) Attribute Aggregator contacts the Authentication Service at its login URL.
 * 14) Authentication Service authenticates the user 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).
 * 15) Having identified and authenticated the user, the Authentication Service returns the authentication assertion to Attribute Aggregator containing the PID of the user (as a binary blob)
 * 16) Attribute Aggregator passes the assertion to the Attribute Authority.
 * 17) The Attribute Authority validates the assertion, looks up the user in its database and returns the attribute (and possibly authentication) assertion to Attribute Aggregator
 * 18) Depending upon Openstack Gateway’s EARP, Attribute Aggregator may return either the attribute (and authentication) assertion from the Attribute Authority, or the attribute assertion from the Attribute Authority and the authentication assertion from Authentication Service to the client.
 * 19) The client passes the response to Openstack Gateway.
 * 20) From now on it is the same as from step 15 in the single Identity Provider, simple client case.

Mode of Operation with Attribute Aggregation
''NOTE. There is currently no plan to implement attribute aggregation, so the following should be regarded as an approximate outline only, and it may contain errors.''

Attribute aggregation is required when the Openstack Gateway needs attributes from multiple trusted sources and a single Identity Provider is insufficient to verify the identity of the user. Thus multiple Identity Providers are required (or multiple Attribute Authoritys and an Identity Provider or Authentication Service).

With multiple Identity Providers it would be possible to simply ask the user to authenticate to each Identity Provider separately in order to pick up each set of attributes. Multiple authentication exchanges are inconvenient to the user, so the mechanism should be able to support SSO. However, SSO requires that some component stores the PIDs of the user at each Identity Provider/Authentication Service and can map between them, or that the user is known by the same PID at each Identity Provider/Authentication Service, which is unlikely (unless it is a government issued eID). A crude SSO mechanism is that the Attribute Aggregator could securely store the user’s credentials at each Identity Provider and have one strong master PW to unlock them all. Then Attribute Aggregator could authenticate directly to each Identity Provider in order to pick up the user’s attributes.

If we have Attribute Authorities and Authentication Services, if each Attribute Authority uses/trusts the same Authentication Service (or Identity Provider), then the Authentication Service can issue PIDs for each Attribute Authority, and use SSO when each Attribute Authority redirects the user to it for authentication. In this case the Attribute Authorities only need to trust the same Authentication Service and Attribute Aggregator can aggregate all the attribute assertions by contacting each Attribute Authority in turn, and then send the full set of attributes to the Openstack Gateway.

It is also possible for Identity Providers to mutually trust each other and allow SSO between themselves. This can work as follows. The user authenticates to one Identity Provider, which asks the user if he wants to federate his identity with another Identity Provider. If the user agrees, Identity Provider1 (acting as an SP) redirects the user to Identity Provider2, whereupon the user authenticates and Identity Provider2 returns the user’s PID2 to Identity Provider1. From now on the user can pick up his attributes from Identity Provider1 by being authenticated by Identity Provider2. The user goes to Identity Provider1, is redirected by Identity Provider1 to Identity Provider2, where he authenticates, his PID2 is sent to Identity Provider1, whereupon his attributes are returned to him. If all the Identity Providers federate with and trust Identity Provider2, it can hold the set of PIDs for this user, and the user can use Identity Provider2 for SSO. Attribute Aggregator can collect attribute assertions from each Identity Provider in turn to give to Openstack Gateway, and the user only needs to authenticate once (to Identity Provider2).

If the user has not federated all his Attribute Authorities and Identity Providers to a single authentication service (Authentication Service or Identity Provider) then SSO is not possible without additional support from Attribute Aggregator. We can use Attribute Aggregator to hold the PID mappings as follows. Attribute Aggregator has its own key pair, certified by a CA trusted by the federation Identity Providers. Attribute Aggregator initially acts as an SP to each Identity Provider and asks the Identity Provider to authenticate the user. The user authenticates to the Identity Provider, which returns the user’s PID to Attribute Aggregator. Attribute Aggregator can subsequently mutually authenticate with the Identity Provider using its key pair, and ask to pick up the user’s attributes by quoting the relevant PID. Providing the Identity Provider is happy to release the user’s attributes at any time to the Attribute Aggregator SP, this will work. If however, the Identity Provider wants proof that the user is currently logged in to the SP, then Attribute Aggregator can give the Identity Provider the current authentication assertion issued to the user by the current Authentication Service. Providing the Identity Provider trusts this Authentication Service it should be prepared to return the user’s attributes to Attribute Aggregator. Alternatively, Attribute Aggregator could securely store the user’s authentication credentials at each Identity Provider and have one strong master PW to unlock them all. Then Attribute Aggregator could authenticate directly to each Identity Provider in order to pick up the user’s attributes.

In the flow below we assume that the user has federated all his attribute issuers (Attribute Authoritys and Identity Providers) with a single authentication service (AS). The protocol flow is the same as that in using an Authentication Service and Attribute Authority, up to step 17, after which one or more additional Attribute Authorities are contacted. The protocol flow then resumes as in step 18 of using an Authentication Service and Attribute Authority.

The swimlanes for this protocol flow is available here attachment:SwimlaneAttAgg.pdf

18. Attribute Aggregator contacts RIS asking for an attribute request for AA2 and is returned the binary message.

19. Attribute Aggregator passes the message to AA2 asking for the user’s attributes

20. The Attribute Authority asks Attribute Aggregator to authenticate via its Authentication Service, passing it the login URL. The Attribute Authority may only use one Authentication Service, or it may use several in which case it will ask Attribute Aggregator (i.e. the user) to choose which Authentication Service it normally uses.

21. Attribute Aggregator chooses the Authentication Service already in use and contacts the Authentication Service at its login URL passing it the existing session cookie.

22. Authentication Service sees that the user is currently logged in, so returns the authentication assertion for AA2 (containing the PID of the user) to Attribute Aggregator

23. Attribute Aggregator forwards the authentication assertion to AA2

24. AA2 validates the assertion, looks up the user in its database and returns the attribute (and possibly authentication) assertion to Attribute Aggregator

25. Attribute Aggregator returns the complete set of assertions to the client as in step 18 of using an Authentication Service and Attribute Authority

Appendix 1. Attribute Assertions vs Authentication Assertions
Once we progress towards an attribute based authorisation infrastructure, the difference between attribute and authentication assertions should disappear. The former is a more generic assertion than the latter. Authn assertions only contain an ID attribute (which may be a public key) plus details of how strongly the user was authenticated. Attribute assertions may contain any attribute (including an ID attribute or public key) and should contain details of how strongly the user was authenticated in order to obtain the attribute assertion. Thus we should be able to dispense with authentication assertions and only have attribute assertions, providing of course each attribute assertion contains details of how strongly the user was authenticated in order to obtain it.

Appendix 2. Attributes vs Attribute Authorities
Attributes may be globally defined, e.g. visa attributes, or locally defined e.g. member of club X. Globally defined attributes are often specified in international standards and may be used in several different domains and federations. Their syntax and semantics are fixed, regardless of which Attribute Authority issues them. Local attributes are defined by their issuing attribute authority and usually are only valid in the domain or federation in which the Attribute Authority is a member. For locally identifiable attributes the attribute authority (issuer) must be globally identifiable (in the federation). The attribute then becomes globally identifiable through hierarchical naming (Attribute Authority.attribute).

Trust in an attribute assertion is always decided by the relying party. However, relying parties would normally only trust local attributes that are issued by the Attribute Authority which defines them. For example. No RP would believe an Attribute Authority who said I was a member of club X, if the Attribute Authority for club X was not prepared to assert this. (Note that with delegation of authority this is slightly different, because a member of club X may also act as an Attribute Authority and assert that someone else is a member of club X. But the original assertion of membership came from the Attribute Authority (or SoA) of club X.)

Globally defined attributes may be issued by many different Attribute Authoritys. So the RP has to specify which Attribute Authority it trusts to issue which globally defined attributes. If an attribute is very popular there may be hundreds or thousands of Attribute Authoritys which issue it, e.g. role. The Visa attribute is one such attribute which is issued by hundreds of banks (as plastic credit cards). However, in the Visa case, it supports delegation of authority and there is only one Source of Authority for the Visa attribute. Relying parties have a central service they can contact to ask if the issuer and attribute assertion (credit card) is valid or not. So they do not need to specify who they trust to issue this attribute, they simply specify that they accept this attribute, regardless of who issued it, because they have a trusted server for checking if the issuer (and the assertion) is genuine or not. Note that in the case of Visa these are long lived assertions, so a means of revocation checking is essential. In this case the revocation checking process serves to check if the issuer is trusted as well as if the assertion is still valid. When we use short lived assertions the situation is different, since there is no revocation checking mechanism. It is deemed to be not needed since a valid assertion will never be revoked. But we still have the issue of knowing whether the issuer is genuine or not. Simply checking the digital signature is not enough, since anyone can get a valid PKC from Verisign and with this can sign anything. Consequently anyone can issue a short lived Visa attribute assertion. So how does the relying party know if this is a valid issuer or not, given that there is no revocation checking mechanism? One solution is for the RP to keep a list of trusted Attribute Authoritys for each globally defined attribute. But this potentially has a scalability problem. Delegation of authority is the way of solving the scalability issue. In this case we have one root Attribute Authority (the Source of Authority, SoA) and all other Attribute Authoritys are delegated by it. In this case the RP only needs to trust the SoA and then any Attribute Authority delegated by the SoA is a trusted Attribute Authority. We can support delegation of authority either by having assertion chains (SoA-> Attribute Authority) or a central service run by the SoA for checking the validity of an Attribute Authority (as in the Visa case).

Glossary
AA – Attribute Authority. An authoritative source of user attributes E.g. a bank can provide a credit card attribute, a university a degree  attribute, an employer the role attribute etc.

AM – Attribute Mapper. Maps from externally provided attributes into the equivalent internal attributes (roles/projects etc) used by cloud services, or vice versa.

ARP – Attribute Requirements Policy. Created by a service provider to inform the user which attributes, from which trusted authorities, and to  which level of assurance, are needed in order to access the service

AS – Authentication Service. Is able to authenticate a user and issue an (authentication) assertion containing a unique persistent identifier  (PID) for each user. May or may not know who the user actually is in the physical world – this is specified in the Level of Assurance of the  issued assertion - but can determine that it is the same virtual user  every time. One can consider an AS to be an Identity Provider that only issues a PID attribute and no other attribute.

AtAg – Attribute Aggregator, an intelligent component of the client that is responsible for  evaluating the service’s attribute requirements policy, and then  contacting the set of Identity Providers/AAs/ASs as necessary to obtain the identity  attributes required to access the service. It is fully controlled by the user. It knows which Identity Providers and AAs hold which attributes for this user. It also holds user self-asserted attributes. It may also know how to authenticate the user to each Identity Provider and AA/AS.

Authz – Authorisation Service. Given an authz request “can a user with these identity attributes access this resource” typically returns granted or  denied

Client – the basic software necessary for interfacing to the cloud on behalf of the user. Could be a standard browser or command line client.

Cloud Service Provider 1…n (CSPs) – these are the cloud service providers that are using the OpenStack Gateway to provide is identity and access management functionality

CVS – Credential Validation Service. Given an authentication and/or attribute assertion will return the set of valid identity attributes. Is driven by a credential validation policy

Dir – Directory Service (enhanced Keystone Service Catalog). Contains the set of identity and attribute authorities and cloud service providers and the  information needed to contact them (so called meta data).

IdP – Identity Provider. A combination of an Authentication Service and Attribute Authority. Can issue authentication and attribute assertions.

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.

Neg - Negotiation Module. An optional protocol specific federation protocol negotiation module. This is needed by the IETF Abfab protocol suite but not by the OASIS SAML protocol.

PDP - Policy Decision Point. The service which evaluates the authorisation policy and says if the user should be granted access or not.

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.

TS – Token Service. This is the existing Keystone service that creates and validates scoped and unscoped tokens.

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 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