Abstract: A system and method are provided to allow access to one or more computing resources using a single authentication scheme even though some of the computing resources may support different authentication schemes. In various embodiments, upon receiving a user request to access one or more computing resources, a first authentication credential according to a first authentication scheme is generated subsequent to successful authentication of the user. If processing of the request requires a second authentication credential according to a second authentication scheme, the second credential may be encapsulated in the first authentication credential and later extracted and combined with additional information, if necessary, for providing the requested access to the one or more computing resources.

Abstract: Authenticated requests can be sent without requiring the requests to include or potentially expose secret information used for the authentication process. A client device use a security credential such as a key to sign a request to be sent to a recipient. When the request is received, the recipient determines whether the request was signed using the correct key for the sender. In some embodiments a client token is included with the request that statelessly encodes the key, enabling a recipient capable of decoding the client token to determine the key and compare that key to the signature of the request. The sender can store the secret information in a secure location, such as a browser security module, such that the secret information is not exposed to the browser or script executing on the client device.

Abstract: Client impersonation is recognized by an access control service using servicer credentials to allow a servicer to impersonate a user's context while requesting actions be performed on a computing resource. A servicer may be requested to perform an action through impersonation, granting access to the context of a user related to the computing resource. The computing resource receives servicer credentials and impersonation information from the servicer. After verifying the servicer's authorization to perform actions under the context of the user, the servicer may attempt to perform the requested action. The action may be logged as performed by the servicer impersonating the user. The user may also be billed for any costs incurred.

Abstract: Authenticated requests can be sent without requiring the requests to include or potentially expose secret information used for the authentication process. A client device use a security credential such as a key to sign a request to be sent to a recipient. When the request is received, the recipient determines whether the request was signed using the correct key for the sender. In some embodiments a client token is included with the request that statelessly encodes the key, enabling a recipient capable of decoding the client token to determine the key and compare that key to the signature of the request. The sender can store the secret information in a secure location, such as a browser security module, such that the secret information is not exposed to the browser or script executing on the client device.

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 in the form of parameters that are used to specialize keys. Keys and/or information derived from keys held by multiple authorities may be used to generate other keys such that signatures requiring such keys and/or information can be verified without access to the keys. Keys may also be derived to form a hierarchy of keys that are distributed such that a key holder's ability to decrypt data depends on the key's position in the hierarchy relative to the position of a key used to encrypt the data. Key hierarchies may also be used to distribute key sets to content processing devices to enable the devices to decrypt content such that sources or potential sources of unauthorized content are identifiable from the decrypted content.

Abstract: Methods and apparatus for a mixed-mode authorization metadata manager for cloud computing environments are disclosed. A system includes a plurality of service managers coordinating respective distributed multitenant services, and a metadata manager. In response to a metadata request for an authorization entity, the metadata manager identifies a first and a second service manager coordinating services in use by a client account with which the authorization entity is affiliated. The first and second service managers implement respective authorization APIs. The metadata manager provides composite authorization metadata of the authorization entity based at least in part on (a) service authorization metadata provided by each of the first and second service managers and (b) identity authorization metadata provided by an identity manager.

Abstract: Secret information, such as seeds, codes, and keys, can be automatically renegotiated between at least one sender and at least one recipient. Various mechanisms, such as counters, events, or challenges, can be used to trigger automatic renegotiations through various requests or communications. These changes can cause the current secret information to diverge from older copies of the secret information that might have been obtained by unintended third parties. In some embodiments, a secret can be configured to “decay” over time, or have small changes periodically introduced that can be determined to be valid by an authorized party, but can reduce the effectiveness of prior versions of the secret information.

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: Session-specific information stored to a cookie or other secure token can be selected and/or caused to vary over time, such that older copies will become less useful over time. Such an approach reduces the ability of entities obtaining a copy of the cookie from performing unauthorized tasks on a session. A cookie received with a request can contain a timestamp and an operation count for a session that may need to fall within an acceptable range of the current values in order for the request to be processed. A cookie returned with a response can be set to the correct value or incremented from the previous value based on various factors. The allowable bands can decrease with age of the session, and various parameter values such as a badness factor for a session can be updated continually based on the events for the session.

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 are described for delegating permissions to enable account access to entities not directly associated with the account. The systems determine a delegation profile associated with a secured account of at least one customer. The delegation profile includes a name, a validation policy that specifies principals which may be external to the account and which are permitted to assume the delegation profile, and an authorization policy that indicates the permitted actions within the account for those principals which are acting within the delegation profile. Once the delegation profile is created, it can be provided to external principals or services. These external principals or services can use the delegation profile to obtain credentials for performing various actions in the account using the credentials of the delegation profile.

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: Methods and apparatus for an account state simulation service for cloud computing environments are disclosed. A system includes a plurality of service managers coordinating respective distributed network-accessible services, and a metadata manager. The metadata manager receives an account state change simulation request, indicating (a) an initial account state of a client account and (b) a collection of operations to be simulated. The metadata manager generates a response to the account change state simulation request, comprising at least one of (a) a representation of an expected end state of the client account reachable as a result of performing the collection of operations (b) an indication of an expected failure of a particular operation of the collection of operations or (c) an estimate of an expected billing amount associated with an implementation of the collection of operations.

Abstract: Systems and methods are described for delegating permissions to enable account access. The systems utilize a delegation profile that can be created within a secured account of at least one user. The delegation profile includes a name, a validation policy that specifies principals which may be external to the account and which are permitted to assume the delegation profile, and an authorization policy that indicates the permitted actions within the account for those principals which are acting within the delegation profile. Once the delegation profile is created, it can be provided to external principals or services. These external principals or services can use the delegation profile to obtain credentials for performing various actions in the account using the credentials of the delegation profile.

Abstract: Authenticated requests can be sent without requiring the requests to include or potentially expose secret information used for the authentication process. A client device use a security credential such as a key to sign a request to be sent to a recipient. When the request is received, the recipient determines whether the request was signed using the correct key for the sender. In some embodiments a client token is included with the request that statelessly encodes the key, enabling a recipient capable of decoding the client token to determine the key and compare that key to the signature of the request. The sender can store the secret information in a secure location, such as a browser security module, such that the secret information is not exposed to the browser or script executing on the client device.

Abstract: Secret information, such as seeds, codes, and keys, can be automatically renegotiated between at least one sender and at least one recipient. Various mechanisms, such as counters, events, or challenges, can be used to trigger automatic renegotiations through various requests or communications. These changes can cause the current secret information to diverge from older copies of the secret information that might have been obtained by unintended third parties. In some embodiments, a secret can be configured to “decay” over time, or have small changes periodically introduced that can be determined to be valid by an authorized party, but can reduce the effectiveness of prior versions of the secret information.

Abstract: Systems and methods are described for delegating permissions to enable account access to entities not directly associated with the account. The systems determine a delegation profile associated with a secured account of at least one customer. The delegation profile includes a name, a validation policy that specifies principals which may be external to the account and which are permitted to assume the delegation profile, and an authorization policy that indicates the permitted actions within the account for those principals which are acting within the delegation profile. Once the delegation profile is created, it can be provided to external principals or services. These external principals or services can use the delegation profile to obtain credentials for performing various actions in the account using the credentials of the delegation profile.

Abstract: Methods and apparatus for an account state simulation service for cloud computing environments are disclosed. A system includes a plurality of service managers coordinating respective distributed network-accessible services, and a metadata manager. The metadata manager receives an account state change simulation request, indicating (a) an initial account state of a client account and (b) a collection of operations to be simulated. The metadata manager generates a response to the account change state simulation request, comprising at least one of (a) a representation of an expected end state of the client account reachable as a result of performing the collection of operations (b) an indication of an expected failure of a particular operation of the collection of operations or (c) an estimate of an expected billing amount associated with an implementation of the collection of operations.

Abstract: Authenticated requests can be sent without requiring the requests to include or potentially expose secret information used for the authentication process. A client device use a security credential such as a key to sign a request to be sent to a recipient. When the request is received, the recipient determines whether the request was signed using the correct key for the sender. In some embodiments a client token is included with the request that statelessly encodes the key, enabling a recipient capable of decoding the client token to determine the key and compare that key to the signature of the request. The sender can store the secret information in a secure location, such as a browser security module, such that the secret information is not exposed to the browser or script executing on the client device.