Abstract: Multi-tenant resources can be funded using payment submitted with requests for those resources, such that the resources do not need to be associated with a specific user account. A resource can be allocated and available as long as payment has been provided. If a user wants the resource to be available for additional processing, for example, the user can submit another request with additional funding. The funding can come in the form of donations from any user, or in the form of investments where the investor expects some return on the investment in the form of revenue, visibility, or other such compensation. One or more management components can track funding for various resources, can accept and select bids for period of sponsorship, and can manage various donation models.

Abstract: A first request from a client using a first protocol is translated into one or more second requests by a servicer using a second protocol through a virtual request using the first protocol. A client may use parameters of the first protocol to pass virtual request components to the servicer. A format agreement between the client, servicer and/or authentication service may allow the servicer and/or authentication service to translate virtual request components over the first protocol to one or more second requests using the second protocol. Virtual request components may also prove the authenticity of the virtual request received by the servicer to an authentication service. Once satisfied the virtual request is valid, the authentication service may issue a credential to the servicer to send the one or more second requests to an independent service. Virtual requests may be included in various protocols, including credential-based protocols and certificate exchange-based protocols.

Abstract: Techniques are described for enabling principals to inject context information into a credential (e.g. session credential). Once the credential has been issued, any arbitrary principal is allowed to inject context information into the existing credential. The injected context is scoped to the principal that made the injection. Subsequently, at authentication time, when the credential is used to request access to a particular resource, the system can verify whether the principal that made the injection is trusted and if the principal is deemed trusted, the context information can be applied to a policy that controls access to one or more resources, or can alternatively be translated into some context residing in a different namespace which can then be applied to the policy. In addition, the system enables arbitrary users to insert additional deny statements into an existing credential, which further restrict the scope of permissions granted by the credential.

Abstract: A system includes a memory and a processor. The memory is operable to store a credential verifier associated with a user account and a counter. The processor is coupled to the memory and the memory includes executable instructions that cause the system to receive a first authentication attempt and increment the counter if validation of the first authentication attempt against the credential verifier fails. The instructions also cause the system to receive a second authentication attempt and increment the counter only if validation of the second authentication attempt against the credential verifier fails and the second authentication attempt is distinct from the first authentication attempt.

Abstract: Systems and methods for authentication generate keys from secret credentials shared between authenticating parties and authenticators. Generation of the keys may involve utilizing specialized information that, as a result of being used to generate the keys, renders the generated keys usable for a smaller scope of uses than the secret credential. Further, key generation may involve multiple invocations of a function where each of at least a subset of the invocations of the function results in a key that has a smaller scope of permissible use than a key produced from a previous invocation of the function. Generated keys may be used as signing keys to sign messages. One or more actions may be taken depending on whether a message and/or the manner in which the message was submitted complies with restrictions of the a key's use.

Abstract: A support system negotiates secure connections on behalf of multiple guest systems using a set of credentials associated with the guest systems. The operation of the secure connection may be transparent to the guest system such that guest system may send and receive messages that are encrypted or decrypted by the support system, such as a hypervisor. As the support system is in between the guest system and a destination, the support system may act as a local endpoint to the secure connection. Messages may be altered by the support system to indicate to a guest system which communications were secured. The credentials may be managed by the support system such that the guest system does not require access to the credentials.

Abstract: Systems and methods for authentication generate keys from secret credentials shared between authenticating parties and authenticators. Generation of the keys may involve utilizing specialized information that, as a result of being used to generate the keys, renders the generated keys usable for a smaller scope of uses than the secret credential. Further, key generation may involve multiple invocations of a function where each of at least a subset of the invocations of the function results in a key that has a smaller scope of permissible use than a key produced from a previous invocation of the function. Generated keys may be used as signing keys to sign messages. One or more actions may be taken depending on whether a message and/or the manner in which the message was submitted complies with restrictions of the a key's use.

Abstract: Systems and methods for authentication generate keys from secret credentials shared between authenticating parties and authenticators. Generation of the keys may involve utilizing specialized information that, as a result of being used to generate the keys, renders the generated keys usable for a smaller scope of uses than the secret credential. Further, key generation may involve multiple invocations of a function where each of at least a subset of the invocations of the function results in a key that has a smaller scope of permissible use than a key produced from a previous invocation of the function. Generated keys may be used as signing keys to sign messages. One or more actions may be taken depending on whether a message and/or the manner in which the message was submitted complies with restrictions of the a key's use.

Abstract: Access control techniques relate to verifying compliance with security policies before enabling access to the computing resources. An application is provided on a client that generates verification codes using an authentication seed. Prior to granting the client the authentication seed necessary to generate a verification code, a server may perform a policy check on the client. Some embodiments ensure that the client complies with security policies imposed by an authenticating party by retrieving a number of parameter values from the client and then determining whether those parameter values comply with the security policies. Upon determining that the client complies, the authentication seed is issued to the client. In some embodiments, the authentication seed is provided such that a policy check is performed upon the generation of a verification code. The client is given access to secure information when the client is determined to comply with the security policies.