Jump to: navigation, search

Difference between revisions of "Keystone/Federation/Blueprint"

Line 21: Line 21:
  
 
The swimlanes that pictorially show this protocol flow are available here [[attachment:SwimlaneSimpleClient.pdf]]
 
The swimlanes that pictorially show this protocol flow are available here [[attachment:SwimlaneSimpleClient.pdf]]
 +
 +
0.    The user types in the command to the client
  
 
# The client contacts the Cloud Service to request a service
 
# The client contacts the Cloud Service to request a service

Revision as of 20:08, 1 November 2012

Modular Keystone

Providing Federated Access to Clouds

Version: 1.1 Author: David W Chadwick Date: 1 November 2012

<<TableOfContents()>>

Guiding Principles

  1. Each cloud service keeps it existing tenants/projects and roles for authz, and passes the bulk of the work off to the OpenStack Gateway 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.)
  2. There can be thousands of Identity Providers/Attribute Authoritys with millions of different attributes. It would be too complex for Cloud Service Providers 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 the Openstack Gateway to issue them. It trusts the Openstack Gateway to map between the externally provided attributes and the internally understood ones. The Openstack Gateway 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.
  3. 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).
  4. The Openstack Gateway has a set of trust relationships with a set of external Identity Providers, Authentication Services and Attribute Authoritys. The Attribute Mapper of the Openstack Gateway knows how attributes from these external entities map into the local attributes known by the Cloud Service Providers. This information must be configurable in AM, e.g. through policies or config files.
  5. 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 on 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.
  6. The user knows which cloud service he wishes to use, so this is his first port of call. It is not some external TTP (such as Keystone in the existing system). The user should not need to know about some external TTP.

Single Identity Provider, Simple Client

In this mode of operation, the user has a simple client and trusts the CSP to behave correctly. A single IdP authenticates the user and provides all the user's authorisation attributes to OG.

The downside of a simple client is that it is open to phishing attacks from evil CSPs, which redirect the client to a false Openstack Gateway in step 2, and from there to a false Identity Provider in step 11.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 swimlanes that pictorially show this protocol flow are available here attachment:SwimlaneSimpleClient.pdf

0. The user types in the command to the client

  1. The client contacts the Cloud Service to request a service
  2. The Cloud Service Provider sends the client its attribute requirements policy (ARP) and the URL of the Openstack Gateway to contact to resolve this policy. The ARP contains the set of attributes (tenants/roles), issued by the Openstack Gateway, which are needed for the requested service. Note, this allows a Cloud Service Provider to dynamically set its policy for each requested service. If the policy is fixed it may be configured into the Openstack Gateway at initialisation and omitted from the protocol.
  3. The client resolves the Openstack Gateway’s name in the DNS, gets the IP address of Openstack Gateway, and passes the ARP to Openstack Gateway’s URL.
  4. 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. Note that if the ARP is fixed then the mapping can also be fixed
  5. Openstack Gateway sends the set of Identity Providers to the client in response to message 2.
  6. The user chooses which Identity Provider he wishes to use
  7. The client returns the chosen Identity Provider to Openstack Gateway.
  8. Openstack Gateway performs a directory lookup on this Identity Provider, and obtains its metadata
  9. Openstack Gateway then calls the Request Issuing Service to create an authentication and attribute request in the appropriate format for the chosen Identity Provider.
  10. Openstack Gateway returns the Identity Provider request as a binary blob to the client, along with the address of the Identity Provider
  11. The client passes the request to the Identity Provider
  12. 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).
  13. Having identified the user, the Identity Provider returns the authentication and attribute assertion to the client (as a binary blob)
  14. The client passes the Identity Provider’s response to Openstack Gateway.
  15. Openstack Gateway calls the Credential Validation Service to validate the Identity Provider’s response and returns the valid attributes to Openstack Gateway
  16. Openstack Gateway calls the Attribute Mapping Service to obtain the local set of attributes that are equivalent to the Identity Provider provided set.
  17. Openstack Gateway calls the Token Issuing Service to obtain an unscoped token for the user
  18. Openstack Gateway returns the unscoped token to the user, along with a list of tenants
  19. The user choses which tenant he wishes to use
  20. The client passes the unscoped token and tenant to Openstack Gateway
  21. Openstack Gateway calls the TVS to validate the unscoped token
  22. Openstack Gateway then calls the TIS to issue a scoped token for the user
  23. Openstack Gateway returns the scoped token and list of services at which this can be used to the client. (Note the latter is not needed since the user has already spoken to the Cloud Service Provider in step 1, but it is there for backwards compatibility.)
  24. The client contacts the Cloud Service Provider with the scoped token, requesting the service
  25. The Cloud Service Provider passes the scoped token to Openstack Gateway for validation
  26. Openstack Gateway contacts the TVS to validate the token and gets the response
  27. Openstack Gateway sends the reply to the Cloud Service Provider
  28. The Cloud Service Provider asks the PDP is the user is authorised for this request
  29. The Cloud Service Provider sends the response to the client
  30. The client makes additional requests to the Cloud Service Provider using the same scoped token, goto 25.

Single Identity Provider, Intelligent Client

This mode protects the client from phishing attacks since the intelligent client decides for itself how to contact the user’s Identity Provider

  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 and Identity Providers that may be capable of fulfilling the policy.
  5. Openstack Gateway passes the set of external attributes 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 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.
  8. 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.
  9. 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.
  10. Attribute Aggregator contacts the chosen Identity Provider, sending it the binary blob.
  11. 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).
  12. Having identified the user, the Identity Provider returns the authentication and attribute assertion to Attribute Aggregator (as a binary blob)
  13. Attribute Aggregator passes this response to the client
  14. The client passes the assertion to Openstack Gateway.
  15. Same as Single Identity Provider, Simple Client from now onwards

Mode of Operation with Holder of Key Verification

In both of the single Identity Provider modes the assertions returned by the client to Openstack Gateway are bearer credentials. This means that Openstack Gateway cannot be certain that the credentials belong to the client that is presenting them. 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 Openstack Gateway that it has the private key that corresponds to the public key in the assertions, and therefore that the assertions belong to it. The protocol steps are the same as before, but the protocol messages are different as stated below.

  1. For Single Identity Provider, Simple Client, the procedure is the same until step 12 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 13 the Identity Provider includes the public key in the response that it creates for the Openstack Gateway. 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.
  2. 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

In this mode of operation the attribute authority uses an external authentication service to authenticate clients who want to retrieve attributes from it. Attribute Authoritys 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@Authentication Service). 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.

  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 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 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 Authoritys 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 redirect the user to it for authentication. In this case the Attribute Authoritys 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 to 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 Authoritys 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 (Authentication Service or Identity Provider). 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 Authoritys are contacted. The protocol flow then resumes as in step 18 of using an Authentication Service and Attribute Authority.

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 ones 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/Service Catalog. Contains the set of identity and attribute authorities and cloud service providers, possibly along with the attributes they issue or require, and the information needed to contact them (so called meta data). Typical requests might be, given the name of an attribute, return the set of authorities who issue it, or given the name of an authority, return sufficient information to allow an authentication and/or attribute request to be formulated to its service. (Note that current federations provide the latter service by passing metadata between themselves.)

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

OpenStack Gateway (OG) – the entity which each of the Cloud Services contacts in order to authenticate and authorise the user. It is a proxy IDP and proxy PDP. (Currently the role played by Keystone)

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

TVS – Token Validation Service. Validates the tokens given to OG by the Cloud Service Providers

MSc Dissertation

An MSc dissertation describing the first prototype implementation can be downloaded from attachment:MSc Dissertation.docx. 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