IAM in Service Catalog
Status: draft for discussion
It is common for processes running on server systems to act as clients to other servers to perform actions "on behalf of" some user or other process. Standard authentication systems do not support an "on behalf of" concept. The absence of a standard approach to this function leads to a haphazard set of approaches that often have policy and security failures. A standard method (or set of methods) to handle common cases should meet certain requirements. Several existing technologies illustrate the design choices.
Authentication may be defined as a means for a service, acting as a relying party, to establish a security context for an operation or set of operations based on evidence supplied by a client, the party requesting the operation(s). In ordinary client/server authentication, a user directly controls a client process (e.g. an email client on a PC), and has some credential material (e.g. username and password, certificate and private key) that can be used within an application protocol (e.g. IMAP) to make requests to a service (e.g. an IMAP server). The service receives the evidence (e.g. username+password, cert+signed messages) via the protocol, verifies it, and if good establishes a security context identifying this application operation (or session) as being associated with that user. The service uses that context for authorization, i.e. to determine whether it will perform requested operations (e.g. reading a particular mailbox). People managing resources on services, including ordinary users in some cases, state service authorization policies in terms of these user-based contexts (e.g. adding a user to an access control list for a mailbox).
In some cases the client is not a human end-user but a process. For example a process may access protected person information in a directory service in order to populate a local person database. Such a process will have people or organizations identified as being responsible for it, but typically will authenticate to services with its own credential (e.g. "department X person data application"), using the same authentication methods available to human users. In this case the authorization policy at the service would include references to processes in addition to or instead of human users.
As computing grows in sophistication and universal access, it is more common to find 3-tier, or more generally multi-tier, access scenarios. Reliance on web browsers is a strong factor, as web-based applications often replace traditional client programs.
In a typical 3-tier scenario, a user uses a web browser to access a web-based application on a server (e.g. a mail program such as WebPine). The user authenticates to the application server in the usual client/server way, establishing a security context for its operations on that application. The web application, now acting as an intermediate (a general term for the middle tier), must access another service, the backend service (e.g. the IMAP service), to perform the same kind of operations the user might have done using a traditional 2-tier client (e.g. accessing a human user's mailbox).
The "3-tier problem" is: how does the intermediate service authenticate to the backend service? The answer to this question has many implications for authentication methods and policy, user interaction, authorization policy, application protocols, and more. It is also the case that there will be many different answers for different situations. Consider a few example solutions in the webmail case.
In approach (A), the intermediate simply authenticates as itself (e.g. "webmail_application_1"). To permit the access that users need the intermediate's userid is permitted to access all needed resources (e.g. mailboxes), perhaps by adding its userid to the resource ACLs. This may be easy to implement (if the ACLs can be managed in bulk), but tends to distort access records, as operations done via the intermediate will be shown as performed by it rather than the user on whose behalf it was working ("who deleted those messages? uh, the webmail app"). Another potential problem is that the intermediate, if it is used by many users, has access to all those users' resources all the time. If it is compromised attackers have access to lots of resources.
In approach (B), a refinement of approach (A), the intermediate authenticates as itself, but also passes to the backend an indication of the user on whose behalf it is acting. The backend server can then check that this "impersonation" is permitted, and if so establish a security context for the impersonated user rather than the intermediate. This permits users to get access to backend resources without authorization settings being changed. On the other hand, this approach may be difficult to implement because it requires some means of sending the impersonated userid via the intermediate-backend protocol, and support for doing the impersonation steps at both intermediate and backend. It also has the "too powerful intermediate" issue as (A) does (i.e. the intermediate can access many resources all the time). Note: the UW Webpine installation uses this method to authenticate to the IMAP servers, taking advantage of an IMAP protocol feature that supports expressing authentication "on behalf of" (SASL authorization ID).
In approach (C), the intermediate has access to a user secret so it can authenticate to the backend in the same way the user would. The secret can be provided in various ways: a password entered by the user to the intermediate at signon time, a password store available to the intermediate, etc. This approach provides access to user resources (e.g., mailboxes) with no additional requirements on the backend, but requires some intermediate support. However, this approach exposes user secrets (passwords, usually) to the intermediate. If those secrets are usable for many services (as UW NetID passwords are) then a compromise of the intermediate exposes many services to abuse.
In approach (D), when the user signs on to the intermediate, the intermediate receives (or can obtain) a security token from the authentication service that it can pass along to the backend. The meaning of the token is "server Y acting on behalf of user X". The backend can verify the received token (perhaps via a call to the authentication service) and establish a security context for user X. This approach provides limited access for the intermediate (i.e., not all users all the time), doesn't expose passwords, and doesn't require the intermediate to be present in backend authorization settings. It may be difficult to implement because it requires support in the initial authentication protocol, the intermediate, the backend, and the authentication service.
Authentication is always about trust, or more precisely risk management, primarily on the part of the service, i.e. the relying party. The service decides which evidence from a client to trust in order to create security contexts for use in evaluating which operations to permit. In traditional username/password client/server authentication the service accepts the risk that the user might given their password to someone, or that it is sniffed in transit, or that is guessable, etc. In schemes using an authentication service, e.g. Pubcookie, Kerberos, PKI, the service accepts the risks of relying on the authentication service (service compromise, protocol attacks, etc) in exchange for the benefits (no local password-handling, SSO, etc).
3-tier scenarios make the trust picture more complicated. In a 2-tier scenario a service relies on authentication mechanisms to provide confidence that the party requesting operations is really a particular userid (ak identity, or principal, or subject). In a 3-tier scenario these ordinary 2-tier mechanisms apply to the authentication between intermediate and backend. But now the backend must consider: what the relationship is between the intermediate and the user on behalf of which it is making (or claiming to make) requests, since the backend will be associating those requests with the user, i.e. holding the user responsible for them. Under what circumstances is the backend justified in deciding that the intermediate accurately speaks for the user?
In many situations the intermediate and the backend are under common administration (e.g. UW WebPine and the UW IMAP servers). In this case the backend may accept simple assertions from the intermediate that it is operating on behalf of one user or another. This is very common practice.
But as protocol access to services increases, particularly using web services of various flavors, the situation where the intermediate and the backend are not under common administration is more common. If the backend service is run by university central IT, the intermediate may be run by a department or by an outsourced service provider. In these situations simply accepting an assertion of a user from an intermediate may not be an acceptable risk. Managing this risk can mean two distinct things. One is: did the intermediary do a good job of ensuring that the claimed user is the right one; i.e. did it authenticate the user well? The other is: did the user consent to the intermediary performing these operations on its behalf? That is, there could be a circumstance where the intermediary is well-authenticated, and the user is well-authenticated, and this is proved to the satisfaction of the backend, but the intermediary is doing things that are contrary to the user's interest.
The notion of controlling what kinds of things and intermediary can do is generally called "constrained delegation." ...
Various policy controls desirable at an authentication service ...
In the canonical 3-tier scenario the intermediate performs operations on the backend on behalf of a user who has an active session with the intermediate. The intermediate may be thought of as translating, in real-time, operations the user does on it into operations the intermediate does on the backend. Such scenarios may benefit from authentication mechanisms that use some feature of user-intermediate authentication to enable intermediate-backend "on behalf of" authentication.
There are other scenarios where the intermediate is asked to do operations on behalf of a user who does not have an active session with the intermediate (i.e., the user is "not present"). An example is a backup service that wants to write to a backend storage server "as the user" rather than as itself. Long-running e-science processes provide other examples. In such scenarios the intermediate may be enabled to act as the user via some setup step where the user creates a context on the intermediate that it can use at future times to authenticate to backends on behalf of the user. It is probably attractive to support both user-present and user-not-present scenarios with the same or similar 3-tier mechanisms, for the sake of simplicity at the backends.
Work well with web apps as intermediates
Limit the damage a bad or compromised intermediate can do
Not increase exposure of user passwords
Work with non-modifiable backends
Work with many intermediate-backend protocols
Work well with intermediate-backend communication using RESTful web services
Provide for user choice in scenarios that need it
Support constraints on what an intermediate can do
WS-* and WS-Trust