assumed persistent source value of the alternate identity

Abstract

An identity and access management service implements a persistent source of value for assumed identities, PSV. The source value (e.g., an original identifier for an entity) is persisted in the assumed identity, facilitating identification of the entity (user or application) responsible for actions taken with the assumed (e.g., surrogate) identity. A manager receives a request to assume an identity. The request includes an entity's current credentials and the PSV. The current credentials have been authenticated, and a persistent source of value policy can be relied on to determine whether and / or how to grant the assumed identity. The PSV can be copied from the credentials in the request to be included in the credentials for the requested identity provided by the manager in response to the request. Access to a service or resource using the requested credentials (including the PSV) can be logged, with the log including the PSV from the request to assume the identity.

Description

Background Technology

[0001] Identity and access management can include policies and technical frameworks to ensure that various customer entities can appropriately access technical resources. For example, an identity and access management system not only identifies, authenticates, and authorizes entities using computing resources, but also identifies, authenticates, and authorizes the hardware and applications that employees need to access. In recent years, as regulatory compliance requirements have become increasingly stringent and complex, identity and access management solutions have become more prevalent and important. Identity and access management addresses the need to ensure appropriate access to resources in an increasingly heterogeneous technological environment. Identity management systems, products, and applications manage identification and supporting data about entities, including individuals, computer-related hardware, and software applications in such heterogeneous systems.

[0002] Identity management can address issues such as how a client (sometimes referred to as a user or programmatic application in this document) acquires an identity and assumes an alternative identity (sometimes referred to as a temporary identity or temporary assumption of an alternative identity in this document), as well as, in some cases, the permissions granted to an identity and the technologies that protect that identity and support that protection (e.g., network protocols, digital certificates, passwords, etc.).

[0003] Because the system does not automatically track long-term identities across multiple assumed temporary identities, it is difficult to determine responsibility for actions performed using multiple assumed temporary identities, especially across multiple domains where different domains are prevented from viewing logs from other domains. Making such decisions may require complex, custom applications that compare chains of identity identifiers across many different logs across many different domains (e.g., to identify the entity that assumed a temporary identity and performed a specific action). For example, it may be necessary to reveal an entire chain of temporary identities to trace an action back to the long-term identity responsible for it. Because access to logs from other accounts is not permitted, the original source of an entity that has assumed a role across accounts may not be found. Attached Figure Description

[0004] Figure 1 This is a block diagram illustrating components of a system that assumes a persistent source value of an alternative identity according to some implementation schemes.

[0005] Figure 2A and Figure 2B This is a block diagram / dataflow diagram illustrating a combination of architectures and technologies used to implement persistent source values ​​for assumed alternative identities, according to some implementation schemes.

[0006] Figure 3 This is a flowchart illustrating a technique for processing requests for temporary identities in a system that implements a persistent source value for an assumed alternative identity, according to some implementation schemes.

[0007] Figure 4This is a table illustrating various characteristics of persistent source value strategies for systems implementing alternative identities based on some implementation schemes.

[0008] Figure 5 This is a flowchart illustrating a technique, according to some implementations, for processing requests made via a temporary identity in a system that implements a persistent source value of an assumed alternative identity.

[0009] Figure 6 This is a flowchart illustrating a technique for obtaining persistent source values ​​from logs according to some implementation schemes.

[0010] Figure 7 Examples of computer systems according to embodiments are shown, one or more of which may implement various components described and shown throughout this disclosure, including components of a system that implements a persistent source value of an assumed alternative identity.

[0011] Although this invention has been described by way of example of some embodiments and illustrative drawings, those skilled in the art will recognize that the invention is not limited to the described embodiments or drawings. It should be understood that the drawings and detailed description thereto are not intended to limit the invention to the specific forms disclosed, but rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. The headings used herein are for organizational purposes only and are not intended to limit the scope of the specification. Detailed Implementation

[0012] As discussed in more detail below, various implementations of an identity and access management service are disclosed that implement persistent source values ​​for assumed alternative identities. In these implementations, the disclosed capabilities facilitate tracking (e.g., logging) the original source values ​​(e.g., identifiers of service or user entities) of actions performed by one or more alternative identities assumed by the entity (sometimes referred to herein as temporary identities, temporary assumptions of alternative identities). Entities are intended to be broad and may include users, principals, client devices, client applications, services (e.g., programmatic clients), servers, etc. In some implementations, "temporary" may refer to the duration of the identity assumption, rather than the duration of the identity's presence or availability within the system.

[0013] In some systems, when an entity assumes a substitute (or temporary) identity, logging software that records resource actions targeted by the substitute identity records the substitute identity, rather than the entity's long-term (or "original") identity. In such systems, it can be difficult to trace actions performed by the substitute identity back to the long-term original identity.

[0014] In contrast, for at least some of the embodiments described herein, the system can enforce or require the definition of a persistent source value when an alternate identity is assumed, even across multiple alternate identities within the same session. A persistent source value can persist across multiple alternate identities (or across roles, one identity in some systems) and is logged whenever an assumed alternate identity performs an action. For example, failed or successful access requests to a resource can be logged, and / or requests made by the assumed alternate identity can also be logged. In some embodiments, the presence of a persistent source value in the credential of the last credential in a chain of many alternate identities in a session may make it unnecessary to investigate and reveal the entire chain of alternate identities to trace the action back to the long-term identity ultimately responsible for the action. In some embodiments, the persistent source value in the credential of the last alternate identity will be the long-term identity (e.g., the original identity) responsible for the action. In example use, logs recording requests to resources and persistent source values ​​(e.g., from credentials) can be viewed or queried to identify responsibility for actions performed using alternate identities within a customer account (e.g., without having to trace the entire chain back to the original identity associated with the entity).

[0015] In the implementation, persistent source values ​​act as trackers through an identity and logging system that retains source values ​​through multiple assumptions, making it unnecessary to recreate or discover the entire identity chain to determine the original responsible entity for the action.

[0016] Although the implementation described herein describes using persistent source values ​​across assumed identities to persist identifiers of an entity’s original identity (e.g., usernames or similar for long-term credentials), it is envisioned that persistent source values ​​can be used to persist other values, such as, but not limited to, tickets, project names, etc.

[0017] In some implementations, identifiers associated with a set of credentials for the primary identity (long-term or temporary identity) are persisted due to the assumption of a subsequent identity (e.g., a subsequent temporary identity). In these implementations, credentials that are part of or associated with a user identity have broad intents, and non-exhaustive examples of credentials include passwords, access keys, server certificates, and various other identifiers (such as session keys, but not limited to these).

[0018] In the implementation, when assuming a temporary identity, the persistent source value may or may not be a required request parameter (e.g., a persistent source value policy may specify a requirement). For example, an administrator may configure the system (e.g., via a policy) to require requesting entities (programmed or user) to define their persistent source values ​​when assuming a temporary identity in an account. Entities that do not provide the required persistent source value according to the policy can be prevented from assuming the corresponding temporary identity, and failed identity assumptions may be logged in the implementation (e.g., by a logging proxy at the identity manager).

[0019] In the implementation, the persistent identifier may be referred to as a persistent source value. In the implementation, a persistent source value is a unique identifier that an application sets as an attribute when assuming a temporary identity. In the implementation, the persistent source value attribute accepts a string as its value, such as, but not limited to, a passphrase or a policy variable.

[0020] In some systems, a special type of identity (sometimes called a role) is an identity associated with an account that has specific permissions. For example, a role may have an identity with permission policies that determine what that identity can and cannot do within the system. However, a role is not uniquely associated with a person and can be assumed by anyone who needs it. Furthermore, in some implementations, roles do not have standard long-term credentials, such as a password or access key associated with them. Instead, when a role is assumed, it provides temporary security credentials for the role session.

[0021] Some systems can implement the RoleSessionName condition element, which differs from the persistent source value described here. In some systems, the RoleSessionName condition helps control the naming of individual identity (or role) sessions. For example, each instantiation of an alternate identity and its associated set of credentials (e.g., short-lived credentials) can be referred to as a role session. In the example, a role session is uniquely identified by a role session name. The RoleSessionName condition element can be used to control how entities (e.g., users and applications) name their role sessions when assuming an identity. Such a RoleSessionName condition differs from the persistent source value described here, at least in that the RoleSessionName condition is not persisted across identity assumption; it exists only for the session associated with the current identity. In contrast, in implementations, persistent source values ​​are transitive, sticky, and logged by a logging agent located at the target resource.

[0022] For example, persistent source values ​​can be persisted across an assumption identity as persistent identifiers (e.g., attributes or fields) maintained in credentials (e.g., tokens, etc.) provided for the assumption identity. Some implementations in this paper describe persistent source values ​​as identifiers of the initiating entity or client (e.g., sometimes referred to as the persistent source identifier of the entity). However, persistent source values ​​can be interpreted broadly. A persistent source value can identify a specific ticket (or task) for an IT service, or a specific procedural process running on a network, or a specific project within an organization, as are a few non-exhaustive examples.

[0023] In one example, the identity manager component of a system or identity service may receive a request to assume a temporary identity. This request may originate from a client (e.g., a user device running client software, or a programmatic process (application) acting as a client). The request presents a first credential associated with a first identity of the requesting entity. The service verifies the first credential associated with the first identity and, for valid credentials, permits the request (in an implementation, the determination of whether to permit the request may be further specified in the policy permissions) and embeds a persistent source value in a second credential (the second credential being the credential of the requested temporary identity).

[0024] In the implementation, if an additional identity is assumed by the entity, persistent source values ​​are persisted across the additional assuming entity. The values ​​of the persisted persistent source values ​​may originate from various sources, including but not limited to requests (e.g., usernames provided in a request, fields provided by the user via CLI, API, or GUI), or fields or attributes specified by a persistent source value policy, etc. In the implementation, persistent source values ​​are a mechanism for persisting some values ​​from the initial use of long-term identities and long-term credentials (e.g., before obtaining a temporary identity / credential) across one or more uses of assumed temporary identities and credentials. In the implementation, the phrases "long-term" and "temporary" are relative terms. For example, the lifetime of a long-term credential may be longer than that of a temporary credential (significantly longer in the implementation). In the implementation, temporary identities and / or credentials may be associated with relatively short lifetimes and have an earlier expiration date than long-term credentials with later expiration dates. In the implementation, long-term and short-term identities and / or credentials may be updatable. In the implementation, when an assumed temporary identity session expires, the entity identity may return or revert to a long-term identity. In the implementation, when a temporary identity session expires, the entity may need to verify the long-term credential.

[0025] In the implementation, when an assumed alternate identity is used, the logging agent logs the activities performed by the assumed identity (e.g., generating logs that include a persistent source value and information about the activities). When viewing the logs, the persistent source value helps track the entity that performed the action, even if that entity is performing the action with an assumed (e.g., temporary) identity. For example, if an entity sets the persistent source value to the entity username of its long-term credentials when assuming a temporary identity, the logging service will log any activities performed by the temporary identity, and an administrator can rely on the username persisted in the persistent source value to identify the entity responsible for the action performed using the temporary identity when viewing the associated logs. In the implementation, when another temporary identity is assumed in an existing session using a temporary identity, the identity and access management service will also maintain a persistent source value (e.g., source identity information) to perform the action.

[0026] Non-exhaustive examples of some benefits of maintaining a source identity for an assumed identity include facilitating the identification of the entity responsible for actions performed under that assumed identity (e.g., not using the entity's original identity). For example, an administrator might require all entities in their company to set their username (or other identifier) ​​to their source identity when assuming another identity. In a particular example, activities performed by the first assumed identity can be logged (e.g., the source identity can be passed along with credentials or tokens used for the first assumed identity and logged when the target resource receives the request), and the administrator can rely on the source identity to identify the entity responsible for actions performed under that assumed identity when reviewing the logs. In some implementations, the system can maintain a persistent source value for actions even when that identity assumes yet another identity in an existing session.

[0027] The descriptions of the various diagrams are now presented. Typically, in some implementation schemes, Figure 1 The components depicted in Figure 8 can perform Figure 2A / Figures 2B to 6 At least some of the functions described in the text, and Figure 4 The table shown provides information that can be obtained from... Figure 1 The system and components shown in Figure 8 are implemented and Figure 2A / Figures 2B to 3 and Figure 5 Examples of the strategies upon which the functions described in the text depend. For example, Figure 2A / Figure 2B The process and components of identity assumption depicted in the text are composed of Figure 1 Similar components in the process perform, and Figure 3 The identity assumption process shown can be performed by Figure 1 , Figure 2A / Figure 2B The identity and access management service 102 is executed. In the implementation plan, Figure 5 The access request process shown can be performed by Figure 1 The services 110, 120, or 130 are executed by resources 112, 122, or 132. In the implementation plan, Figure 6 The log processing procedure shown can be performed by Figure 1 The logging service 140 is executed by one or more components.

[0028] Figure 1 This is a block diagram illustrating components of a system that assumes a persistent source value of an alternative identity according to some implementation schemes. The various illustrated components can perform... Figure 2A / Figures 2B to 3 and Figures 5 to 6 The functions described in the text. For example, the identity and access management service is illustrated using an identity manager 104 and a mapping table of alternative identity identifiers to persistent source value policies (e.g., policies in...). Figure 4 As shown below).

[0029] In an implementation, policies are objects that define permissions when associated with an identity or resource. When an entity (user or programmatic) makes a request using an identity, system components evaluate these policies. Systems (service provider networks or other types of systems) can enforce various types of policies (e.g., identity-based policies, resource-based policies, access control lists, session policies, etc.). For example, different types and numbers of policies can be associated with identities or resources. The system can provide interfaces (command-line interface - CLI, application programming interface - API, graphical interface - GUI, etc.) for accessing, creating, configuring, and / or managing various types of policies. As described below, Figure 1 and 4 The persistent source value strategy shown is an example of a variety of strategy types.

[0030] In some implementations, clients with long-term identities and associated long-term credentials (e.g., external client 152(a, n) or internal client 152b / c) send requests (e.g., access requests—intended broadly and including but not limited to storage requests, data retrieval requests, processing requests, update requests, etc.) to resources (112a-n, 122a-n, and / or 132a-n) of services (computing service 110, storage service 120, and / or database service 130). In some implementations, services include, but are not limited to, services of service provider network 100 (e.g., network-based services) that provide computing power, storage, content delivery, or other functionalities, such as various applications built from computing and storage resources. In some implementations, services may include technical infrastructure and distributed computing building blocks and tools arranged in various architectures for use with other services that can be accessed via requests described herein. Resources of the various services process requests and provide responses to them.

[0031] Clients 152a, b, c, ... n can use their long-term credentials to send requests to services 110-130, or they can assume temporary credentials and then use those temporary credentials to send requests to services 110-130 instead. For example, internal client 152b (e.g., an application running on or across one or more resources of services 110-130) can interact with identity manager 104 of identity and access management service 102 to request an alternative identity associated with alternative credentials, and then, if successful, use the alternative credentials to send requests to other resources of services 110-130. Similarly, external client 152a can provide long-term credentials from external identity provider 180 (e.g., a third-party identity provider or an identity provider on the client network) in a request to identity manager 104 to assume an alternative identity, and then use those alternative credentials to access services 110-130. As described herein, the persistent source value determined at the time of identity assumption can be persisted in the assumed credentials. Persistent values ​​can be provided and recorded in requests to services 110, 120, and 130 (e.g., recorded by a local proxy on the resource) to track source information about the request (e.g., tracking the original long-term identity that assumed the alternative identity that made the request).

[0032] In the implementation, when resources 112, 122, and 132 process requests, logging agents 142a-n can log information associated with the request. For example, the logging agents can log alternative identity identifiers (e.g., the name of the alternative identity) and persistent source values, as well as other information about the request. For example, log viewer 144 of logging service 140 can provide access to the logs to determine persistent source values ​​associated with the request.

[0033] exist Figure 1 The persistent source value policy is illustrated in the Identity and Access Management Service 102. For a given identity (such as an alternative identity identified by an identity identifier), in... Figure 1 (Examples include TempDev123, TempSvcxyz, etc.). The strategy used for this identity may or may not require a persistent source value. The strategy (e.g., a persistent source value strategy, such as...) Figure 1 and Figure 4(Those shown) can specify other criteria, such as a specific value, format, or source of the persistent source value. In some implementations, the value of the persistent source value can be used to control the permissions granted to the entity assuming the alternative identifier. For example, an entity can request to assume an alternative identity named TempUserxyz, where a policy named PSV_Cust_Policy specifies read-only permissions for the target storage service, but allows the TempUserxyz alternative identity to read and write when the persistent source value is set to RoyG44. In some implementations, the information specified in the policy can be embedded in the credentials generated for the requested alternative identity.

[0034] In some implementations, the system can divide the functionality for managing temporary and long-term credentials into different identity management components. For example, the system can implement a long-term identity component or service for creating, managing, and / or validating credentials associated with a long-term identity, and a separate short-term identity component or service for creating, managing, and / or validating credentials associated with a short-term (e.g., temporary) identity. For instance, a user or application can use a first set of credentials via the long-term identity component as a long-term identity, and then assume a short-term identity via the short-term component to perform actions limited to that short-term identity. In some implementations, the identity and access management service is configured to ensure that persistent source values ​​persist across multiple assumed temporary identities, regardless of the source of the credentials submitted with the identity assumption request.

[0035] In some implementations, the identity and access management service 102 may include a management interface (e.g., API, CLI, or GUI) (not shown). In one implementation, for persistent identities or applications, to define their persistent source values ​​when assuming temporary identities, an administrator may grant them permissions for this action. Furthermore, when granting permissions, the administrator can use conditions to control what persistent identities or applications will set as their persistent source values.

[0036] Figure 2A and Figure 2B This is a block diagram / dataflow diagram illustrating a combination of techniques for implementing persistent source values ​​of an assumed alternative identity according to some implementation schemes. Figure 2A and Figure 2B An example of an identity chain is shown together. In the implementation, Figure 2A and Figure 2B Together, they illustrate the transitive properties of persistent source values ​​(e.g., PSV applies between successive assumptions).

[0037] like Figure 2AAs shown in step 1, client 152b generates and sends a request for a first alternative identity to identity and access management service 102. The request includes credentials (CR) associated with the current identity of the requesting entity (in various embodiments, these may be long-term or alternative credentials associated with a long-term or alternative identity), the entity's current credentials including (indicated by square brackets) a persistent source value (PSV), and an identity identifier indicating the requested (first) alternative identity (AII1).

[0038] In the illustrated implementation, the Identity and Access Management Service 102 processes the request, verifies credentials, and processes the request according to a persistent source value policy (e.g., determining whether the use of an alternative identity is authorized, whether a persistent source value is required, or whether it must conform to a specific format, etc.). If the credentials are verified and the assumption of the alternative identity is permitted, the Identity and Access Management Service 102 generates a response (transmitted in step 2) that includes credentials for the first alternative identity (ACR1). The generated credentials include the identity identifier (AII1) of the first alternative identity and a copy of the persistent source value (PSV) that appeared in the request in step 1. In step 2, the Identity and Access Management Service 102 responds to the client request in step 1 with the generated response (e.g., responding with a token containing a copy of the first alternative identity (AII1) and the persistent source value (PSV).

[0039] Figure 2A Continuing with step 3, client 152b transmits an access request to a resource (e.g., resource 112a). The access request includes credentials comprising a copy of the identity identifier (AII1) and persistent source value (PSV) of a first alternative identity. In the illustrated embodiment, the resource processes the request, and a logging agent at the resource (e.g., log agent 142a) logs information about the request, including at least a copy of the identity identifier (AII1) and persistent source value (PSV) of the first alternative identity. Resource 112a generates a response and transmits the response (step 4). Figure 2A and Figure 2B The ellipsis between them indicates the time period. Figure 2A and Figure 2B It takes place between these two periods.

[0040] exist Figure 2B In this process, the same client 152b requests to assume yet another alternate identity. This time, the request for the second alternate identity (AII2) (step 5) uses... Figure 2AThe request is made using credentials of the first alternative identity (ACR1), which includes the same PSV that has been persisted via steps 1-2. The Identity and Access Management Service 102 processes the request (e.g., based on a persistent source value policy) and generates a response with the requested credentials (ACR2), which includes the second alternative identity AII2 and the persisted PSV.

[0041] Figure 2B The diagram shows client 152b using credentials of a second alternative identity (ACR2) to make a data access request, this time for resource 132a (of database service 130). Resource 132a processes the request and transmits a response back (step 8). Log broker 142j generates a log about the request, indicating at least the second alternative identity. Figure 2B Showing from Figure 2A The PSV (the one in step 1) is persisted through multiple identity assumptions and access requests, and eventually ends up in a log that associates the PSV with an access request performed under a different (alternative) identity than the one used in step 1.

[0042] In the implementation, when an entity assumes multiple alternative identities (also known as identity or role chains) in a session, the persistent source value remains the same for all alternative identities assumed in the session. In the implementation, the identity and access management service 102 will not allow modification of the persistent source value when an entity assumes another alternative identity within a session. In the implementation, the identity and access management service 102 will reject attempts to modify the persistent source value when assuming another alternative identity within an existing alternative identity session.

[0043] Figure 2A / Figure 2B This is illustrated using client 152b, which initiates an alternative identity request and sends a request to the resource, but the process is similar for other clients such as external client 152a and client 152c.

[0044] Figure 2A / Figure 2B The diagram illustrates a persistent source value and an alternative identity identifier (e.g., in cryptographic form within a token) included in the credentials. It is conceivable that, in implementations, the persistent source value and the alternative identity identifier may be transmitted as part of the request, but not necessarily within the credential portion of the request.

[0045] In some implementations (e.g., implementations using session tokens), the persistent source value is contained in the session token. For example, the session token is used for each action performed by the substitute identity, including the assumption of yet another substitute identity. In some implementations, transmitting the session token may be a necessary part of assuming the substitute identity. In some implementations, the session token may be encrypted, and the target resource receiving the encrypted session token may send the token to an authentication service that decrypts the token, extracts the persistent source value, and populates the authentication result with the decrypted persistent source value.

[0046] In the implementation plan, requests to assume an alternative identity, such as Figure 2A As shown in step 1, this can be achieved via various APIs, such as, but not limited to, a custom AssumeIdentity API, a SAML-based AssumeIdentity API, and a WebIdentity-based AssumeIdentity API. Example parameters included in the request include, but are not limited to, the value of the Persistent Source Value (PSV) parameter, the identifier of the requested alternate identity, and the credentials of the identity making the request. Before calling the AssumeIdentity API, the administrator can grant permission to set the persistent source value. An example sample permission that the administrator can grant is to assume the developer identity, provided that the developer sets the developer long-term identity username as the persistent source value.

[0047] In the implementation, when assuming the developer identity, the administrator uses identity conditions to enforce that the long-term identity username be set to a persistent source value. The administrator can also use conditions to define acceptable source identity values, such as known values, like the long-term identity username, or a predefined list of available values ​​(e.g., some roles may be restricted to use by listed entity groups). Administrators can also enforce these or similar conditions in identity trust policies for any alternative identities they possess. For example, if two users, Connor and Doug, are the only users allowed to assume the identity (as specified by conditions in the policy), attempting to set a persistent source value other than Connor or Doug will cause the identity assumption attempt to fail.

[0048] In another example, the persistent source value strategy can specify that the persistent source value must be in a format that combines certain information, such as, but not limited to, username-project ID. Using the example above, for example, combining... Figure 4 The TempIT1234 temporary identifier (described below) will have a persistent source value name of Connor-TroubleTicket3914. For example, the required characteristics of the persistent source value can be set by conditions specified in the policy.

[0049] In yet another example, statements in a policy (e.g., conditional statements) can be used to specify permissions based on persistent source values. The following describes... Figure 4 Examples are provided. For instance, a policy for a given resource or a policy for a given identity might reference a persistent source value property.

[0050] It is conceivable that in various implementation schemes, Figure 2A The credential CR in the protocol can be a credential that is part of a Security Assertion Markup Language (SAML)-based protocol or a federated identity protocol. In the implementation scheme, Figure 2A The credentials (CR) in the system can originate from an identity provider (180) outside the service provider network (100). For example, Figure 2A Client 172 can log in to identity provider 180 (or the Active Directory agent of the enterprise client network) and request a SAML assertion, then use the SAML assertion to request a temporary identity. Figure 2A Step 1), etc. In implementations, attributes in the SAML assertion (input by the SAML assertion provider) or input from the requesting entity (e.g., as specified or required by a policy) or the identity of the requesting client-server application can be used as a persistent source value (PSV) in the request in step 1. It is conceivable that in some implementations, identity provider 180 can be implemented on a client network, such as a client network.

[0051] In at least some implementations, the persistent source value may be automatically set by the identity and access management service 102 (e.g., set to a long-term username of the requesting entity or an attribute specified by some policy). In some implementations, the owner of the temporary identity may specify whether the persistent source value is required to assume the temporary identity (e.g., this may be specified in a policy or otherwise) and / or may specify requirements regarding what is allowed from the persistent source value. In some implementations, the owner of the temporary identity may specify that the persistent source value is not allowed to assume the temporary identity (e.g., this may be specified in a policy or otherwise).

[0052] In the implementation plan, the identity is assumed ( Figure 2AThe credentials (e.g., sometimes called tokens) in step 2) are generated based on at least three characteristics: an access key ID, a session token, and a secret key (the private key is used to sign the token generated based on the access key ID and the session token; the private key is not sent as part of the token). In an implementation, the session token may include a persistent source value. For example, the persistent source value may be a field in the session token. Upon receiving a request made using cryptographic credentials and targeting a service resource, the target resource or service may pass the cryptographic credentials to an authentication service, which decrypts and verifies the credentials, extracts the persistent source value, and passes the decrypted persistent source value back to the target resource in the authentication response. This process may involve generating a log entry associated with the request and including the persistent source value for actions associated with the request. In an implementation, the temporary identity session name differs from the persistent source value.

[0053] exist Figure 2B In step 5, client 172 requests a second alternative identity. This request includes alternative credentials for the first alternative identity (ACR1), the identity identifier (AII1) of the first identity, and a persistent source value (PSV). In some implementations, when the identity and access management service 102 receives the request, it can identify the persistent source value field in the request and persist the value in that field to other alternative credentials for the session (e.g., whether a persistent source value is required in some implementation). For example, if the incoming request (step 5) includes a persistent source value and attempts to set the persistent source value of the requested alternative identity to some other value, the request may be rejected and an error message may be generated (e.g., the system may prevent the persistent source value from being changed in the session because various alternative identities are assumed).

[0054] In some implementations, even if a persistent source value policy does not specify that a persistent source value is necessary for obtaining the requested alternative identity or is required to be included in the credentials of the requested alternative identity, the system may still embed (or otherwise include) the value provided by the persistent source value in the credentials of the requested alternative identity. In some implementations, such active “stickiness” of values ​​in one or more alternative identities (e.g., sticky, transient identifiers) can keep the value “alive” or in process even when the policy does not require it, so that the value remains available for subsequent alternative identities associated with a persistent source value policy that does specify that a persistent source value is necessary for obtaining the requested alternative identity or needs to be included in the credentials of the requested alternative identity.

[0055] Figure 2A The document does not specify whether the credential for the current identity (step 1) is a long-term or short-term credential. In the implementation, the credential for the current identity can be of any type. The credential for the current identity can be generated from any of several different sources. For example, Figure 2AThe credentials for the current identity shown may have been generated by the Identity and Access Management Service 202, or they may have been generated by an identity provider 180 outside the Service Provider Network 100. Figure 1 The credentials for the current identity may have been generated by a third-party identity provider or by the identity provider service of a client network (e.g., a part of the client network, not shown). In implementations, the identity provider may implement a persistent credential service and separate alternative credential services to provide different types of credentials.

[0056] In the implementation, once an alternate developer identity is assumed and a persistent source value is set, the identity and access management service 102 will not allow the persistent source value to be changed during the duration of the assumed identity session. In the implementation, attempts to change the persistent source value at this time may result in an error message and / or a request rejection. The identity and access management service 102 will carry the persistent source value for any actions performed using the alternate identity, and when yet another alternate identity is assumed within an existing assumed identity session.

[0057] In some implementations (not shown), instead of like Figure 2A As in steps 2, 3, 6, and 7 of Figure B, the PSV is transmitted in the credentials, and the Identity and Access Management Service 102 can store the PSV. The stored PSV can be used when a resource is requested. For example, a client can obtain the PSV from the Identity and Access Management Service 102 when generating a request to send to the target resource. In some implementations, the client can generate a request indicating the location of the stored PSV, and the target resource can obtain the PSV from the Identity and Access Management Service 102.

[0058] Figure 3 This is a flowchart illustrating a technique for processing requests for an alternative identity in a system that implements a persistent source value for an assumed alternative identity, according to some implementation schemes. Figure 3 At least some of the steps shown are similar to Figure 2A / Figure 2B The steps shown, and can be performed by, for example Figure 1 and Figure 2A / Figure 2B The entity shown is executed.

[0059] In box 302, identity manager 104 receives, for example, a request from client 152 to assume an alternative identity, the request including credentials and a persistent source value. In embodiments, the request may include either a long-term or alternative credential for the corresponding long-term or alternative identity. The credential is verified (box 304). For example, identity manager 104 may verify the credential directly, or identity manager 104 may send the credential (encrypted) to an authentication / authorization service for verification, and the authentication service may return one or more decrypted values ​​from the decrypted credential to identity manager 104. In some embodiments, the verification at step 304 may be password-based verification—rather than verification based on a persistent source value policy. For failed verification (e.g., invalid credentials), an error may be generated and an error response transmitted (box 306). For example, a verification failure response message may be generated and sent.

[0060] For valid credentials (box 308), Identity Manager 104 can check whether the use of the requested alternative identity is authorized. For example, Identity Manager 104 can retrieve one or more policies associated with the requested alternative identity and determine authorization based on statements (e.g., conditional statements, etc.) in the corresponding policies. In an implementation, an access control list is also an example implementation for determining whether the use of the alternative identity is authorized in box 308. If the use of the alternative identity is not authorized (box 308, No), an error can be generated and transmitted (box 310). For example, an authorization error can be generated and sent. In an implementation, the error can be logged (e.g., via logging agents 142a-n, as described below).

[0061] In some implementations, the identity manager 104 can inspect one or more policies to determine authorization and other permissions / requirements. Box 312 illustrates the ability to inspect persistent source value requirements. For example, Figure 1 This demonstrates that for the alternative identifier AltDev123, a Persistent Source Value (PSV) is set to required. In the example, Identity Manager 104 determines that a PSV is needed for the requested identity (based on the PSV requirement specified in the policy) and looks up the value in the request (e.g., Figure 2A / Figure 2B (Steps 1 and 5 in the document). If a value has been provided, the persistent value requirement is met (312, Yes). If no PSV is provided (312, No) (or if the format does not match the format specification in the policy), an error can be generated, logged, and / or transmitted (box 314). For example, an error indicating that a persistent source value is required can be generated and sent. In some high-security systems, regarding errors 306, 310, and 314, the request can be rejected without providing a reason for rejection.

[0062] For a PSV requirement that has already been met, Identity Manager 104 can copy the persistent source value presented in the requested credentials to include the credentials of the requested alternative identity (box 316), and respond to the request with the credentials of the requested alternative identity, wherein the credentials in the response include the persistent source value provided along with the credentials in the request (box 318), similar to... Figure 2A / Figure 2B Steps 2 and 6 in the process.

[0063] Figure 4 This is a table illustrating various characteristics of persistent source value strategies for systems implementing persistent source values ​​that assume alternative identities, according to some implementation schemes. In these implementations, Figure 4 The table shown is Figure 1 A more detailed view of the table.

[0064] As mentioned above, the system can implement various types of strategies. Figure 4 This illustrates a specific type of strategy: the persistent source value strategy. It is conceivable that other types of strategies could include properties, fields, or related elements without departing from the public scope. Figure 4 Other similar features are shown in the table. The table illustrates the mapping between alternative and temporary identity identifiers (at the top) to persistent source value policies (policy name row), as well as various features of the example policies (e.g., target resource, permissions, etc.).

[0065] The first persistent source value policy (TempDev123) is an example policy that specifies permissions for developers to access a database service (e.g., database service 130). The surrogate identity has read / write permissions, and specifically, the policy has another permission statement that restricts read / write permissions to the developer's database, Dev_Database. The policy specifies the duration of the surrogate identity (here, 4 hours).

[0066] The next persistent source value policy (AltSvcxyz) is an example of a policy that specifies the permissions for a service (e.g., an application or other programmatic client) to access a storage service (e.g., storage service 120). The target resource is storage resource xyz, and write permissions are specified. In particular, this policy has another permission statement that prevents the assumption of other identities from this identity. The policy specifies the duration of the surrogate identity (here, 24 hours), and the persistent source value requirement is optional.

[0067] The next persistent source value policy (TempUserxyz) is an example of a customer policy that specifies permissions for the storage service (e.g., storage service 120), typically specifying read-only permissions. Furthermore, this policy specifies permission values ​​based on the persistent source value (when the persistent source value in the request is set to "RoyG44", the target storage service is allowed to read / write). Additionally, this policy specifies that the persistent source value (PSV) must be set to the username field of the long-term credential.

[0068] The Persistent Source Value (PSV) policy TempIT234 is an example of an administrator policy that specifies full permissions for a compute service (e.g., compute service 110, or event-driven serverless compute service, etc.). This policy specifies that the PSV must be in the format "username-ticket number," which identifies not only the username used to assume the temporary identity but also the identifier of the project the user is working on—the ticket.

[0069] Policies, such as those described herein, may include other permission statements. In the examples, the information in the statements is contained within a series of elements. The version element can specify the version of the policy language. The statement policy element can be used as a container for other elements. A policy may include more than one statement. Examples of other elements include, but are not limited to, statement identifiers (to distinguish statements), effect elements (indicating whether the policy allows or denies access), actions (a list of actions that the policy allows or denies), and resources (e.g., a list of resources to which the actions apply).

[0070] In some implementations, the system can implement multiple policies. For example, one policy might specify whether a requesting entity is authorized to assume the identity associated with that policy, and another policy might specify the permissions associated with the assumed identity. In implementations, either type of policy can be associated with a persistent source value. For example, a requesting entity (a client entity that receives input from a user or programmatic entity) may or may not be allowed to assume an identity based on whether it provides a value for a persistent source value. In another example, only entities that provide administrative values ​​as persistent source values ​​are allowed to have configuration type access permissions to the target resource.

[0071] In one implementation, permissions are narrowed down to the assumed alternative identity only. In other implementations, permissions are not necessarily narrowed down to the assumed alternative identity and can be determined independently on an individual identity basis.

[0072] Figure 5 This is a flowchart illustrating a technique for processing requests made via an alternate identity in a system that implements a persistent source value for an assumed alternate identity, according to some implementation schemes. In the implementation schemes, the illustrated process can be performed by various resource and logging agents of services 110, 120, and 130.

[0073] In box 502, receive the request and the credentials used to process it. For example, Figure 2A / Figure 2B Steps 3 and 7 in the diagram illustrate the resources of the service receiving the request. Information about the request is logged. For example, information about the request, such as, but not limited to, the identity of the requesting entity, and the persistent source value provided with the request, can be logged by a logging agent (e.g., logging agents 142a, 142j). At box 504, the validity of the request's credentials is checked. If the credentials are invalid (box 504, No), the request is rejected, and information about the rejection is logged (e.g., information about the request, such as, but not limited to, the reason for the rejection, an alternative identity for the requesting entity, and the persistent source value provided with the request).

[0074] In the implementation, when a persistent source value is specified when assuming an alternate identity, the logging component (e.g., a logging agent for the target resource) includes the persistent source value in the log details captured for actions performed using the assumed alternate identity. In the implementation, when an action is performed on a resource using the assumed alternate identity, the persistent source value is placed in a portion of the log details. For example, when a persistent source value is set for the assumed alternate identity, the log viewer component can display the persistent source value in the parameter section of the log details.

[0075] Figure 6 This is a flowchart illustrating a technique for obtaining persistent source values ​​from logs according to some implementation schemes. In some implementation schemes, the illustrated functionality can be performed via an interface of logging service 140 (e.g., log viewer 144).

[0076] In box 602, a request for logs associated with an account is received via an interface for a logging service. The logs associated with the account are retrieved (box 604), and then parsed for a persistent source value and an alternative identity identifier (box 606). In an implementation, information from the logs is provided via the interface, including information about the request, the persistent source value, and / or the alternative identity identifier (box 608).

[0077] In an implementation, components of the log viewer 144 may include components that provide a view of a persistent source value for an access request (as opposed to a query or presentation based on long-term or alternative credentials). Various systems may provide configurable settings that allow the displayed log information to be organized based on persistent source values. In an implementation, a log view for a specific access request provides a persistent source value from the log.

[0078] Log viewer 144 is not necessarily the only way to obtain persistent source values ​​from logs. It is conceivable that some systems may implement various APIs (APIs for accessing the logging system) or code that facilitate applications other than the logging service in obtaining and presenting information from the logs.

[0079] In the implementation, the logging of the first account may include a persistent source value indicating a long-term user ID from some other second account, otherwise the logging of the first account is not available to the second account.

[0080] Although specific functionalities have been described for clarity, other functionalities can be envisioned for retrieving persistent source values ​​of records associated with a particular request. For example, a console or similar interface element could provide a way to query logs.

[0081] Example computer system

[0082] Figure 7 Examples of computer systems according to embodiments are shown, one or more of which may implement various components described and shown throughout this disclosure, including one or more components implementing an identity and access management service that implements a persistent source value of an alternative identity.

[0083] The article described Figure 1 , Figure 2A / Figure 2B and Figure 7 The various parts of the system and / or in Figure 3 , Figure 5 and Figure 6 The methods presented herein can be executed on one or more computer systems similar to those described herein, and can interact with a variety of other devices of the system.

[0084] In the illustrated embodiments, computer system 700 includes one or more processors 710 coupled to system memory 720 via input / output (I / O) interface 730. Computer system 700 also includes a network interface 740 coupled to I / O interface 730 and one or more input / output devices 760 (such as cursor control devices, keyboards, audio devices, and displays). In some embodiments, it is contemplated that an implementation may be carried out using a single instance of computer system 700, while in other embodiments, multiple such systems or multiple nodes comprising computer system 700 may be configured to host different portions or instances of the implementation. For example, in one embodiment, some elements may be implemented via one or more nodes of computer system 700 that are different from the nodes implementing other elements.

[0085] In various embodiments, computer system 700 may be a single-processor system including one processor 710, or a multiprocessor system including several processors 710 (e.g., two, four, eight, or another suitable number). Processor 710 may be any suitable processor capable of executing instructions. For example, in various embodiments, processor 710 may be a general-purpose or embedded processor implementing any of a variety of instruction set architectures (ISAs), such as x86, PowerPC, SPARC, or MIPSISA, or any other suitable ISA. In a multiprocessor system, each of the processors 710 may typically (but not necessarily) implement the same ISA.

[0086] In some implementations, at least one processor 710 may be a graphics processing unit (GPU). A GPU can be considered a dedicated graphics rendering device for a personal computer, workstation, game console, or other computer system. GPUs are highly efficient at manipulating and displaying computer graphics, and their highly parallel architecture can make them more efficient than a typical CPU within the realm of complex graphics algorithms. For example, a GPU can perform a variety of primitive graphics operations in a way that makes execution much faster than direct dragging and dropping onto a screen with a host central processing unit (CPU). In various implementations, the methods disclosed herein for implementing persistent source values ​​for assumed alternative identities can be implemented via program instructions configured to execute on one of such GPUs or in parallel on two or more such GPUs. The GPU may implement one or more application programmer interfaces (APIs) that allow programmers to invoke the functionality of the GPU. Suitable GPUs may be commercially available from vendors such as NVIDIA Corporation, ATI Technologies, etc.

[0087] System memory 720 may be configured to store program instructions and / or data accessible to processor 710. In various embodiments, system memory 720 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated embodiment, program instructions and data that implement the desired functionality, such as the identity and access management services described above for implementing persistent source values ​​for assumed alternative identities, are shown stored within system memory 720 as identity and access management code 102 and data 726 (e.g., policies, etc.). In other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-accessible media or on similar media separate from system memory 720 or computer system 700. Generally, computer-accessible media may include storage media or memory media, such as magnetic or optical media, such as a CD / DVD-ROM coupled to computer system 700 via I / O interface 730. Program instructions and data stored via a computer-accessible medium can be transmitted via a transmission medium or signal (such as electrical, electromagnetic, or digital signals that can be delivered via a communication medium, such as a network and / or wireless link that can be implemented via network interface 740). The program instructions may include instructions for implementing the technology described in any figure.

[0088] In some embodiments, I / O interface 730 may be configured to coordinate I / O traffic between processor 710, system memory 720, and any peripheral devices, including network interface 740 or other peripheral interfaces such as input / output devices 750. In some embodiments, I / O interface 730 may perform any necessary protocols, timing, or other data transformations to convert data signals from one component (e.g., system memory 720) into a format suitable for use by another component (e.g., processor 710). In some embodiments, for example, I / O interface 730 may include support for devices attached via various types of peripheral buses, such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, the functionality of I / O interface 730 may be partitioned across two or more separate components. Furthermore, in some embodiments, some or all of the functionality of I / O interface 730 (such as the interface to system memory 720) may be directly incorporated into processor 710.

[0089] Network interface 740 can be configured to allow data exchange between computer system 700 and other devices (such as other computer systems) attached to the network or between nodes of computer system 700. In various embodiments, network interface 740 can support communication via: wired or wireless general data networks, such as any suitable type of Ethernet network; telecommunications / telephone networks, such as analog voice networks or digital fiber optic communication networks; storage area networks, such as Fibre Channel SAN; or any other suitable type of network and / or protocol.

[0090] In some embodiments, computing device 700 may include input / output devices, which may include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, accelerometers, multi-touch screens, or any other devices adapted to input or retrieve data through one or more computer systems 700. Multiple input / output devices 750 may be present in computer system 700 or may be distributed across various nodes of computer system 700. In some embodiments, similar input / output devices may be separate from computer system 700 and may interact with one or more nodes of computer system 700 via wired or wireless connections (such as via network interface 740).

[0091] Memory 820 may include: program instructions (e.g., such as code 824) configured to implement an identity and access management service that implements a persistent source value assuming an alternative identity as described herein; and data storage device 726 that includes various data accessible by program instructions 724. In one embodiment, program instructions 724 may include software elements of the method shown in the figures above. Data storage device 726 may include data that can be used in the embodiments described herein. In other embodiments, other or different software elements and / or data may be included.

[0092] Those skilled in the art will understand that computer system 700 is illustrative only and is not intended to limit the scope of the systems and methods described herein. Specifically, computer systems and apparatus may include any combination of hardware or software capable of performing the indicated functions, including computers, network devices, internet-connected appliances, PDAs, cordless phones, pagers, etc. Computer system 700 may also be connected to other devices not shown, or alternatively may operate as a stand-alone system. Furthermore, in some embodiments, the functionality provided by the illustrated components may be combined in a few components or distributed across additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided and / or other additional functionality may be used.

[0093] Those skilled in the art will also understand that while various items are shown as being stored in memory or on a storage device when in use, these items or portions thereof may be transferred between memory and other storage devices for memory management and data integrity purposes. Alternatively, in other embodiments, some or all of the software components may be executed in memory on another device and communicate with the illustrated computer system via inter-computer communication. Some or all of the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or portable item for reading by a suitable drive (various examples of which are described above). In some embodiments, instructions stored on a computer-accessible medium separate from computer system 700 may be transmitted to computer system 700 via a transmission medium or signal (such as electrical, electromagnetic, or digital signals delivered via communication media such as networks and / or wireless links). Various embodiments may also include receiving, transmitting, or storing instructions and / or data implemented according to the foregoing on a computer-accessible medium. Thus, the invention can be practiced with other computer system configurations. In some embodiments, some of the technologies described herein (e.g., persistent source values ​​of assumed alternative identities) may be hosted in a cloud computing infrastructure.

[0094] Various implementations may also include receiving, transmitting, or storing instructions and / or data implemented as described above on a computer-accessible medium. Generally, computer-accessible / readable storage media may include: non-transitory storage media such as magnetic or optical media (e.g., magnetic disks or DVD / CD-ROMs); volatile or non-volatile media such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM; and transmission media or signals (such as electrical signals, electromagnetic signals, or digital signals delivered via communication media such as networks and / or wireless links).

[0095] The embodiments disclosed herein may be described with respect to the following provisions:

[0096] Clause 1. A system comprising:

[0097] Multiple computers, each including a processor and memory, are configured to implement one or more services of a service provider network to provide access to managed resources.

[0098] One or more processors and memory, the one or more processors and memory being configured to implement an identity manager, the identity manager being configured to:

[0099] Receive a request from the client to assume a temporary identity, the request including:

[0100] The client's current identity and current credentials, the current credentials including a persistent source value; and

[0101] The identifier of the temporary identity;

[0102] Based on the verification of the current credentials, a first credential for the temporary identity is generated, wherein the first credential includes the identifier of the temporary identity and the persistent source value; and

[0103] The request is responded to using the first credential, which includes the identifier of the temporary identity and the persistent source value copied from the request;

[0104] A computer among multiple computers, which hosts a given resource and a logging agent among the resources, is configured to:

[0105] Receive an access request for the given resource, including the first credential;

[0106] The access request is processed based on the verification of the first credential; and

[0107] Record information associated with the access request, wherein the log information includes the identifier of the temporary identity and the persistent source value.

[0108] Clause 2. The system described in Clause 1,

[0109] The identity manager is configured as follows:

[0110] Receive another request from the client to assume a second temporary identity, the other request including:

[0111] The first credential of the first temporary identity of the client, wherein the first credential includes the persistent source value;

[0112] Based on the verification of the first credential, a second credential for the second temporary identity is generated, wherein the second credential includes the identifier of the second temporary identity and the persistent source value; and

[0113] The request is responded to using the second credential, which includes the identifier of the second temporary identity and the persistent source value copied from the other request.

[0114] Clause 3. The system described in Clause 1 or 2,

[0115] The services provided by the service provider network that grant access to hosted resources include event-driven serverless computing services and computing services; and

[0116] The programmatic process receives the request from one or more resource-hosted processes of the storage service or the computing service, and transmits the response to the programmatic process.

[0117] Clause 4. The system according to any one of Clauses 2 to 3 further includes:

[0118] Data storage policy, which specifies permissions associated with a corresponding persistent source value or requirements for the corresponding persistent source value;

[0119] The second credential used to generate the temporary identity is based, at least in part, on the specified permissions or requirements of the persistent source value specified in a corresponding policy within the stored policies.

[0120] Clause 5. A method comprising:

[0121] Executed by one or more computing devices:

[0122] The identity manager generates a first credential for the alternative identity in response to a request to assume an alternative identity. The request includes an identifier of the current identity of the requesting client, the first credential, and a persistent source value, wherein the first credential includes the identifier of the alternative identity and the persistent source value.

[0123] The request is responded to using the first credential, which includes the identifier of the alternative identity and the persistent source value copied from the request; and

[0124] The persistent source value is persisted for the subsequent identity of the requesting client.

[0125] Clause 6. The method described in Clause 5 further includes:

[0126] In response to another request to assume a second alternative identity and based at least in part on a corresponding strategy that specifies a requirement for a persistent source value in the other request, determine whether the persistent source value has been included in the other request; and

[0127] Based on the other request including the persistent source value, a second credential for the second alternative identity is generated, wherein generating the second credential includes copying the persistent source value from the other request to the second credential.

[0128] Clause 7. The method described pursuant to Clause 5 or 6 further includes:

[0129] In response to another request for an alternative identity, the other request including a second credential and an identifier of the alternative identity:

[0130] Verify the second credential; and

[0131] A strategy for identifying the alternative identity based on the identifier of the alternative identity;

[0132] Based on the strategy, it is determined that one or more requirements for the persistent source value have been met; and

[0133] Based on the determination that one or more of the requirements have been met, generate

[0134] The third credential of the alternative identity, the third credential including the persistent source value copied from the request for the alternative identity.

[0135] Clause 8. The method described in Clause 7, wherein verifying the second credential includes:

[0136] The second credential is transmitted to the verification service, the transmitted second credential including an encrypted persistent source value from the other request; and

[0137] Receive a response to the verification request, the response including a decrypted persistent source value from the other request.

[0138] Clause 9. The method according to any one of Clauses 5 to 8 further includes:

[0139] In response to another request to assume another alternative identity, a policy corresponding to the other alternative identity is retrieved from a data store, wherein the stored policies include:

[0140] Strategy name,

[0141] One or more target resources or services

[0142] The specification regarding whether the alternative identity requires a persistent source value.

[0143] The format specification of the persistent source value, and

[0144] One or more permissions to access one or more target resources or services using the alternative identity;

[0145] Based on the strategy, agreeing to the other request is determined; and

[0146] The other request is responded to using credentials of an alternative identity, wherein the credentials include the persistent source value in the format specified in the policy.

[0147] Clause 10. The method according to any one of Clauses 5 to 9,

[0148] The services provided by the service provider network to grant access to hosted resources include storage services and computing services; and

[0149] The request is received from one or more programmatic processes hosting the storage service or the computing service, and the response is transmitted to the programmatic process.

[0150] Clause 11. The method according to any one of Clauses 5 to 10 further includes:

[0151] Store the permissions or policies that require the persistent source value attribute of the temporary identity's credentials into the data store;

[0152] The identity manager receives a specification for persistent source value requirements via a management interface used to configure the policy, the specification requiring the identity manager to perform the following:

[0153] Extract the persistent source value from the credentials provided in the request for the corresponding alternative identity; and

[0154] Copy the extracted persistent source value to the credentials of the requested alternative identity.

[0155] Clause 12. The method according to any one of Clauses 5 to 11 further includes:

[0156] The computer hosting the resource and logging agent receives an access request for the resource, the access request including the first credential and the persistent source value;

[0157] The computer processes the access request based on the verification of the first credential; and

[0158] The computer's logging agent records information associated with the access request, wherein the log information includes the identifier of the alternate identity and the persistent source value.

[0159] Clause 13. The method according to any one of Clauses 5 to 12 further includes:

[0160] The requesting client receives another request to assume a second alternative identity, the other request including:

[0161] The first credential for the first identity of the client, the first credential including the persistent source value;

[0162] Based on the verification of the first credential, a second credential for the second alternative identity is generated, wherein the second credential includes an identifier of the second alternative identity and the persistent source value; and

[0163] The request is responded to using the second credential, which includes the identifier of the second alternative identity and the persistent source value copied from the other request.

[0164] Clause 14. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, cause the one or more processors to implement an identity manager, the identity manager being configured to perform:

[0165] The identity manager generates a first credential for the alternative identity in response to a request to assume an alternative identity. The request includes an identifier of the current identity of the requesting client, the first credential, and a persistent source value, wherein the first credential includes the identifier of the alternative identity and the persistent source value.

[0166] The request is responded to using the first credential, which includes the identifier of the alternative identity and the persistent source value copied from the request; and

[0167] The persistent source value is persisted for the subsequent identity of the requesting client.

[0168] Clause 15. One or more non-transitory computer-readable storage media as described in Clause 14, wherein the program instructions configure the identity manager to perform:

[0169] In response to another request to assume a second alternative identity and based at least in part on a corresponding strategy that specifies a requirement for a persistent source value in the other request, determine whether the persistent source value has been included in the other request; and

[0170] Based on the other request including the persistent source value, a second credential for the second alternative identity is generated, wherein generating the second credential includes copying the persistent source value from the other request to the second credential.

[0171] Clause 16. One or more non-transitory computer-readable storage media as described in Clause 14 or 15, wherein the program instructions configure the identity manager to perform:

[0172] In response to another request for an alternative identity, the other request including a second credential and an identifier of the alternative identity:

[0173] Verify the second credential; and

[0174] A strategy for identifying the alternative identity based on the identifier of the alternative identity;

[0175] Based on the strategy, it is determined that one or more requirements for the persistent source value have been met; and

[0176] Based on the determination that one or more of the requirements have been met, generate

[0177] The third credential of the alternative identity, the third credential including the persistent source value copied from the request for the alternative identity.

[0178] Clause 17. One or more non-transitory computer-readable storage media as described in Clause 16, wherein, in order to perform the verification of the second credential, the program instructions configure the identity manager to perform:

[0179] The second credential is transmitted to the verification service, the transmitted second credential including an encrypted persistent source value from the other request; and

[0180] Receive a response to the verification request, the response including a decrypted persistent source value from the other request.

[0181] Clause 18. One or more non-transitory computer-readable storage media according to any one of Clauses 14 to 17, wherein the program instructions configure the identity manager to perform:

[0182] In response to another request to assume another alternative identity, a policy corresponding to the other alternative identity is retrieved from a data store, wherein the stored policies include:

[0183] Strategy name,

[0184] One or more target resources or services

[0185] The specification regarding whether the alternative identity requires a persistent source value.

[0186] The format specification of the persistent source value, and

[0187] One or more permissions to access one or more target resources or services using the alternative identity;

[0188] Based on the strategy, agreeing to the other request is determined; and

[0189] The other request is responded to using credentials of an alternative identity, wherein the credentials include the persistent source value in the format specified in the policy.

[0190] Clause 19. One or more non-transitory computer-readable storage media according to any one of Clauses 14 to 18, wherein the program instructions configure the identity manager to perform:

[0191] Store the permissions or policies for the persistent source value attributes that are associated with the credentials of the alternative identity into the data store;

[0192] The identity manager receives a specification for persistent source value requirements via a management interface used to configure the policy, the specification requiring the identity manager to perform the following:

[0193] Extract the persistent source value from the credentials provided in the request for the corresponding alternative identity; and

[0194] Copy the extracted persistent source value to the credentials of the requested alternative identity.

[0195] Clause 20. One or more non-transitory computer-readable storage media according to any one of Clauses 14 to 19, wherein the program instructions configure the identity manager to perform:

[0196] The requesting client receives another request to assume a second alternative identity, the other request including:

[0197] The first credential for the first identity of the client, the first credential including the persistent source value;

[0198] Based on the verification of the first credential, a second credential for the second alternative identity is generated, wherein the second credential includes an identifier of the second alternative identity and the persistent source value; and

[0199] The request is responded to using the second credential, which includes the identifier of the second alternative identity and the persistent source value copied from the other request.

[0200] The figures and various methods described herein represent example implementations of the methods. The methods can be implemented in software, hardware, or a combination thereof. The order of the methods can be varied, and various elements can be added, rearranged, combined, omitted, modified, etc.

[0201] Those skilled in the art who benefit from this disclosure will readily recognize that various modifications and changes can be made. It is intended to cover all such modifications and changes, and therefore the above description is to be regarded as illustrative rather than limiting.

[0202] This disclosure includes references to “implementation” or “group of implementations” (e.g., “some implementations” or “various implementations”). An implementation is a different way or instance of the disclosed concepts. References to “implementation,” “an implementation,” “a particular implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of this disclosure.

[0203] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise specifies, different labels used for a feature (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of that feature. Furthermore, the labels “first,” “second,” and “third,” when applied to features, do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise stated.

Claims

1. A system comprising: One or more processors and memory, the one or more processors and memory being configured to implement an identity manager, the identity manager being configured to: Receive a request from the client to assume a temporary identity, the request including: The client's current identity and current credentials, the current credentials including a persistent source value; and The identifier of the temporary identity; Generate a first credential for the temporary identity, wherein the first credential includes the identifier of the temporary identity and the persistent source value; The request is responded to using the first credential, which includes the identifier of the temporary identity and the persistent source value copied from the request; and The persistent source value is persisted for the subsequent identity of the client.

2. The system according to claim 1, The identity manager is configured as follows: Receive another request from the client to assume a second temporary identity, the other request including: The first credential of the temporary identity of the client, the first credential including the persistent source value; Based on the verification of the first credential, a second credential for the second temporary identity is generated, wherein the second credential includes the identifier of the second temporary identity and the persistent source value; and The request is responded to using the second credential, which includes the identifier of the second temporary identity and the persistent source value copied from the other request.

3. The system according to claim 2, further comprising: Multiple computers, each including a processor and memory, are configured to implement one or more services of a service provider network to provide access to managed resources. The services provided by the service provider network that grant access to hosted resources include event-driven serverless computing services and computing services; and The programmatic process receives the request from one or more resource-hosted processes of the storage service or the computing service, and transmits the response to the programmatic process.

4. The system according to any one of claims 2 to 3, further comprising: Data storage policy, which specifies permissions associated with a corresponding persistent source value or requirements for the corresponding persistent source value; The second credential used to generate the temporary identity is based, at least in part, on the specified permissions or requirements of the persistent source value specified in a corresponding policy within the stored policies.

5. A method comprising: Executed by one or more computing devices: The identity manager generates a first credential for the alternative identity in response to a request to assume an alternative identity. The request includes an identifier of the current identity of the requesting client, the first credential, and a persistent source value, wherein the first credential includes the identifier of the alternative identity and the persistent source value. The request is responded to using the first credential, which includes the identifier of the alternative identity and the persistent source value copied from the request; and The persistent source value is persisted for the subsequent identity of the requesting client.

6. The method of claim 5, further comprising: In response to another request to assume a second alternative identity and based at least in part on a corresponding strategy that specifies a requirement for a persistent source value in the other request, determine whether the persistent source value has been included in the other request; and Based on the other request including the persistent source value, a second credential for the second alternative identity is generated, wherein generating the second credential includes copying the persistent source value from the other request to the second credential.

7. The method according to any one of claims 5 or 6, further comprising: In response to another request for an alternative identity, the other request including a second credential and an identifier of the alternative identity: Verify the second credential; as well as A strategy for identifying the alternative identity based on the identifier of the alternative identity; Based on the strategy, it is determined that one or more requirements for the persistent source value have been met; as well as Based on the determination that one or more of the requirements have been met, generate The third credential of the alternative identity, the third credential including the persistent source value copied from the request for the alternative identity.

8. The method of claim 7, wherein verifying the second credential comprises: The second credential is transmitted to the verification service, and the transmitted second credential includes an encrypted persistent source value from the other request; as well as Receive a response to the verification request, the response including a decrypted persistent source value from the other request.

9. The method according to any one of claims 5 or 6, further comprising: In response to another request to assume another alternative identity, a policy corresponding to the other alternative identity is retrieved from a data store, wherein the stored policies include: Strategy name, One or more target resources or services The specification regarding whether the alternative identity requires a persistent source value. The format specification of the persistent source value, and One or more permissions to access one or more target resources or services using the alternative identity; Based on the strategy, agreeing to the other request is determined; and The other request is responded to using credentials of an alternative identity, wherein the credentials include the persistent source value in the format specified in the policy.

10. The method according to any one of claims 5 or 6, The services provided by the service provider network that grant access to managed resources include storage services and computing services; and The request is received from one or more programmatic processes hosting the storage service or the computing service, and the response is transmitted to the programmatic process.

11. The method according to any one of claims 5 or 6, further comprising: Store the permissions or policies that require the persistent source value attribute of the temporary identity's credentials into the data store; The identity manager receives a specification for persistent source value requirements via a management interface used to configure the policy, the specification requiring the identity manager to perform the following: Extract the persistent source value from the credentials provided in the request for the corresponding alternative identity; and Copy the extracted persistent source value to the credentials of the requested alternative identity.

12. The method according to any one of claims 5 or 6, further comprising: The computer hosting the resource and logging agent receives an access request for the resource, the access request including the first credential and the persistent source value; The computer processes the access request based on the verification of the first credential; and The computer's logging agent records information associated with the access request, wherein the information includes the identifier of the alternate identity and the persistent source value.

13. The method according to any one of claims 5 or 6, further comprising: The requesting client receives another request to assume a second alternative identity, the other request including: The first credential of the alternative identity of the client, the first credential including the persistent source value; Based on the verification of the first credential, a second credential for the second alternative identity is generated, wherein the second credential includes an identifier of the second alternative identity and the persistent source value; and The request is responded to using the second credential, which includes the identifier of the second alternative identity and the persistent source value copied from the other request.

14. One or more non-transitory computer-readable media, comprising program instructions executable on or across one or more processors to perform: The identity manager generates a first credential for the alternative identity in response to a request to assume an alternative identity. The request includes an identifier of the current identity of the requesting client, the first credential, and a persistent source value, wherein the first credential includes the identifier of the alternative identity and the persistent source value. The request is responded to using the first credential, which includes the identifier of the alternative identity and the persistent source value copied from the request; and The persistent source value is persisted for the subsequent identity of the requesting client.

15. One or more non-transitory computer-readable media according to claim 14, wherein the program instructions are executable to perform: In response to another request to assume a second alternative identity and based at least in part on a corresponding strategy that specifies a requirement for a persistent source value in the other request, determine whether the persistent source value has been included in the other request; and Based on the other request including the persistent source value, a second credential for the second alternative identity is generated, wherein generating the second credential includes copying the persistent source value from the other request to the second credential.

Images