Jump to: navigation, search

Keystone/Federation/Blueprint

< Keystone
Revision as of 18:47, 24 September 2012 by Admiyo (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Modular Keystone – Providing Federated Access to Clouds

Guiding Principles

  1. Each cloud service keeps it existing tenants 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 IdPs, validating the various credentials, mapping the attributes into the ones understood by the service etc.)
  2. There can be thousands of IdPs/AAs with millions of different attributes. It would be too complex for CSPs to have to create authz policies based on these. Consequently each CSP has its own limited set of attributes and roles, and only trusts the OG to issue them. It trusts the OG to map between the externally provided attributes and the internally understood ones. The OG is the only known (and trusted) IdP to the CSPs.
  3. Consequently, all IdP/AA 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 OG has a set of trust relationships with a set of external IdPs, ASs and AAs. The OG knows how attributes from these external entities map into the local attributes known by the CSPs. This information must be configurable in OG, 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 IdP which then captures the user’s un/pw. In the current design the simple client is open to such attacks, whereas the intelligent client (AtAg) is not. With the intelligent client, after the user decides which attributes and issuers to use, the AtAg 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 IdP, Simple Client

In this mode of operation, the user is open to phishing attacks from evil CSPs, which redirect the client to a false OG in step 2, and from there to a false IdP in step 11.

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

Single IdP, Intelligent Client

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

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

Mode of Operation with Holder of Key Verification

In both of the single IdP modes the assertions returned by the client to OG are bearer credentials. This means that OG 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 IdP inserts the public key into the assertions. The client can then prove to OG 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 IdP, 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 IdP. In step 13 the IdP includes the public key in the response that it creates for the OG. In step 14 the client signs the message containing the IdP’s response with its private key. This allows OG to prove that the client is the rightful owner of the IdP’s response.
  2. For Single IdP, Intelligent Client, the procedure is the same until step 11 when AtAg creates a new key pair for the user, and includes the public key in the user’s authentication exchange with the IdP. In step 12 the IdP includes the public key in the response that it creates for the OG. In step 13 AtAg passes the new key pair back to the client along with the IdP’s response. In step 14 the client signs the message containing the IdP’s response with its private key. This allows OG to prove that the client is the rightful owner of the IdP’s response.

Mode of Operation using an AS and AA

In this mode of operation the attribute authority uses an external authentication service to authenticate clients who want to retrieve attributes from it. AAs work in the following way. An unknown user contacts the AA for a service, and the AA redirects the user to one of its trusted ASs (or IdPs). The user must already have a relationship with one of these trusted authentication services. The user authenticates to the AS (or IdP) and the AS returns to the AA an authentication assertion containing a persistent ID (PID). From now on, the AA will know this user as PID issued by AS. The user pays the AA for the service and the AA 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 AA, be redirected to the same AS (or IdP), authenticate, and then the AA 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 AA is willing to underwrite the authentication performed by the AS. 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 AS, or a different PID generated by the AA (in which case the AA 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 CSP sends the client its attribute requirements policy (ARP) and the address of the Openstack Gateway to contact.
  3. The client passes the ARP to OG
  4. OG calls the Attribute Mapping Service to convert the ARP into one that contains the external attributes, AAs, ASs and IdPs that may be capable of fulfilling the policy. Note that an AS will only occur in this policy if the OG requires a PID for the user from a trusted AS (and does not trust the AA to issue one). Note that if the ARP is fixed then the mapping can also be fixed.
  5. OG passes the set of external attributes, AAs, ASs and IdPs 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. AtAg asks the user which of his possible attributes (and issuers) he wants to use to access the CSP e.g. he may have several roles, credit cards, email addresses etc. and can choose between them. He may have several IdPs and AAs that can fulfil the attribute requirements of the policy. The user chooses his preferred attributes (and its issuer).
  8. AtAg contacts the Directory service, passing it the name of the user’s chosen AA, to find out the latest contact details (meta information) of it. Note. If AtAg has this information configured into it, then this step can be omitted.
  9. AtAg 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 OG. Note that the intelligent AtAg may have the RIS as a built in service.
  10. AtAg contacts the chosen AA, sending it the binary blob.
  11. The AA asks AtAg to authenticate via its AS, passing it the login URL. The AA may only use one AS, or it may use several in which case it will ask AtAg (i.e. the user) to choose which AS it normally uses.
  12. The user chooses which AS he wants to use
  13. AtAg contacts the AS at its login URL.
  14. AS 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 AS returns the authentication assertion to AtAg containing the PID of the user (as a binary blob)
  16. AtAg passes the assertion to the AA.
  17. The AA validates the assertion, looks up the user in its database and returns the attribute (and possibly authentication) assertion to AtAg
  18. Depending upon OG’s EARP, AtAg may return either the attribute (and authentication) assertion from the AA, or the attribute assertion from the AA and the authentication assertion from AS to the client.
  19. The client passes the response to OG.
  20. From now on it is the same as from step 15 in the single IdP, simple client case.

Mode of Operation with Attribute Aggregation Attribute

aggregation is required when the OG needs attributes from multiple trusted sources and a single IdP is insufficient to verify the identity of the user. Thus multiple IdPs are required (or multiple AAs and an IdP or AS).

With multiple IdPs it would be possible to simply ask the user to authenticate to each IdP 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 IdP/AS and can map between them, or that the user is known by the same PID at each IDP/AS, which is unlikely (unless it is a government issued eID). A crude SSO mechanism is that AtAg could securely store the user’s credentials at each IdP and have one strong master PW to unlock them all. Then AtAg could authenticate directly to each IdP in order to pick up the user’s attributes.

If we have AAs and ASs, if each AA uses/trusts the same AS (or IdP), then the AS can issue PIDs for each AA, and use SSO when each AA redirect the user to it for authentication. In this case the AAs only need to trust the same AS and AtAg can aggregate all the attribute assertions by contacting each AA in turn, and then send the full set to OG.

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

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

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

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

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

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

21. AtAg chooses the AS already in use and contacts the AS at its login URL passing it the existing session cookie. 22. AS sees that the user is currently logged in, so returns the authentication assertion for AA2 (containing the PID of the user) to AtAg

23. AtAg 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 AtAg

25. AtAg returns the complete set of assertions to the client as in step 18 of using an AS and

AA 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 AA issues them. Local attributes are defined by their issuing attribute authority and usually are only valid in the domain or federation in which the AA 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 (AA.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 AA which defines them. For example. No RP would believe an AA who said I was a member of club X, if the AA 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 AA and assert that someone else is a member of club X. But the original assertion of membership came from the AA (or SoA) of club X.)

Globally defined attributes may be issued by many different AAs. So the RP has to specify which AA it trusts to issue which globally defined attributes. If an attribute is very popular there may be hundreds or thousands of AAs 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 AAs 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 AA (the Source of Authority, SoA) and all other AAs are delegated by it. In this case the RP only needs to trust the SoA and then any AA delegated by the SoA is a trusted AA. We can support delegation of authority either by having assertion chains (SoA-> AA) or a central service run by the SoA for checking the validity of an AA (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 IdP that only issues a PID attribute and no other attribute.

AtAg – Intelligent component of the client that is responsible for evaluating the service’s attribute requirements policy, and then contacting the set of IDPs/AAs/ASs as necessary to obtain the identity attributes required to access the service. It is fully controlled by the user. It knows which IDPs 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 IDP 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. Contains the set of identity and attribute authorities, possibly along with the attributes they issue, 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