Abstract: Described herein is a token exchange framework between two different cloud services providers. A multi-cloud infrastructure included in a first cloud environment that is provided by a first cloud services provider (CSP) receives a first request from a user associated with an account in a second cloud environment that is provided by a second CSP. The first request corresponds to using of a service provided by the first cloud environment and includes a first token issued by the second CSP. The multi-cloud infrastructure obtains a second token issued by the first CSP based on validating the first token with respect to a trust configuration corresponding to the second CSP. The trust configuration is previously generated and maintained by the first CSP in the first cloud environment. The multi-cloud infrastructure transmits the second token to the service to enable the user to utilize the service provided by the first cloud environment.

Abstract: Described herein is a token exchange framework between two different cloud services providers. A multi-cloud infrastructure included in a first cloud environment that is provided by a first cloud services provider (CSP) receives a first request from a user associated with an account in a second cloud environment that is provided by a second CSP. The first request corresponds to using of a service provided by the first cloud environment and includes a first token issued by the second CSP. The multi-cloud infrastructure obtains a second token issued by the first CSP based on validating the first token with respect to a trust configuration corresponding to the second CSP. The trust configuration is previously generated and maintained by the first CSP in the first cloud environment. The multi-cloud infrastructure transmits the second token to the service to enable the user to utilize the service provided by the first cloud environment.

Abstract: Described herein is a token exchange framework between two different cloud services providers. A multi-cloud infrastructure included in a first cloud environment that is provided by a first cloud services provider (CSP) receives a first request from a user associated with an account in a second cloud environment that is provided by a second CSP. The first request corresponds to using of a service provided by the first cloud environment and includes a first token issued by the second CSP. The multi-cloud infrastructure obtains a second token issued by the first CSP based on validating the first token with respect to a trust configuration corresponding to the second CSP. The trust configuration is previously generated and maintained by the first CSP in the first cloud environment. The multi-cloud infrastructure transmits the second token to the service to enable the user to utilize the service provided by the first cloud environment.

Abstract: Techniques are described for providing a multi-cloud control plane (MCCP) in a first cloud infrastructure (included in a first cloud environment provided by a first cloud services provider) that enables services and/or resources provided in the first cloud infrastructure to be utilized by users of a second cloud environment. The first cloud infrastructure receives a request from a user associated with an account in the second cloud infrastructure. The request corresponding to using a service provided by the first cloud infrastructure. A tenancy is created for the user in the first cloud infrastructure to enable the user to utilize the service, and a link-resource object is created that includes information linking the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, the link-resource object enabling the user to utilize the service provided by the first cloud infrastructure.

Abstract: The present disclosure describes techniques for using instances of a connector to communicate with multiple target systems without a manual pre-configuration step for each of the multiple target systems. The connector may be an extensible program-code-template for creating objects to perform one or more operations. For example, each instance of the connector may obtain information regarding a corresponding target system, determine an interface to the corresponding target system based on the information, and translate requests for the corresponding target system according to the interface.

Abstract: The present methods are directed to authenticating multi-author message content. In aspects, a sender of a message (first author) may utilize a messaging application to create the message and some message content. However, when creating the message, the sender may embed original content (e.g., from a second author) into the message. For instance, the sender may embed original content corresponding to a news article, a Twitter® post, an invoice, a blog post, or any other original content. Traditional systems are able to verify the sender (first author), but cannot verify the authenticity of the embedded original content. That is, when the recipient receives the message, the recipient cannot verify whether or not the sender (or some other individual) altered the original content prior to sending the message. The present systems provide for recipient authentication of the identity of the second author, as well as the authenticity of embedded original content.

Abstract: The present disclosure describes techniques for using instances of a connector to communicate with multiple target systems without a manual pre-configuration step for each of the multiple target systems. The connector may be an extensible program-code-template for creating objects to perform one or more operations. For example, each instance of the connector may obtain information regarding a corresponding target system, determine an interface to the corresponding target system based on the information, and translate requests for the corresponding target system according to the interface.

Abstract: The present disclosure describes techniques for using instances of a connector to communicate with multiple target systems without a manual pre-configuration step for each of the multiple target systems. The connector may be an extensible program-code-template for creating objects to perform one or more operations. For example, each instance of the connector may obtain information regarding a corresponding target system, determine an interface to the corresponding target system based on the information, and translate requests for the corresponding target system according to the interface.

Abstract: The present methods are directed to authenticating multi-author message content. In aspects, a sender of a message (first author) may utilize a messaging application to create the message and some message content. However, when creating the message, the sender may embed original content (e.g., from a second author) into the message. For instance, the sender may embed original content corresponding to a news article, a Twitter® post, an invoice, a blog post, or any other original content. Traditional systems are able to verify the sender (first author), but cannot verify the authenticity of the embedded original content. That is, when the recipient receives the message, the recipient cannot verify whether or not the sender (or some other individual) altered the original content prior to sending the message. The present systems provide for recipient authentication of the identity of the second author, as well as the authenticity of embedded original content.

Abstract: A message is rendered in an email inbox, with a user actuable element. User actuation is detected and an endpoint associated with the user actuable element is interacted with to perform an action in a service from within the email inbox.

Abstract: The present disclosure describes techniques for using instances of a connector to communicate with multiple target systems without a manual pre-configuration step for each of the multiple target systems. The connector may be an extensible program-code-template for creating objects to perform one or more operations. For example, each instance of the connector may obtain information regarding a corresponding target system, determine an interface to the corresponding target system based on the information, and translate requests for the corresponding target system according to the interface.