OAUTH2SAML token service
阅读说明：本技术 Oauth2 saml令牌服务 (OAUTH2SAML token service ) 是由 D.G.德什潘德 G.库尔卡尼 于 2018-11-30 设计创作，主要内容包括：本公开涉及用于主要传播的系统、软件,和计算机实施的方法。一个示例方法包括将令牌服务部署到第一云平台。从集成组件接收对于将被包括在从第一云平台向第二云平台发送的消息中的令牌的第一令牌请求。用户信息请求被生成并且被发送给与第一云平台相关联的身份提供者。用户信息是响应于用户信息请求从身份提供者接收到的。第二令牌请求被生成并且被发送给与第二云平台相关联的令牌服务提供商。第二令牌请求包括所接收的用户信息。从令牌服务提供商接收所请求的令牌。向集成组件发送所接收的令牌以使得集成组件能够向第二云平台发送消息。(The present disclosure relates to systems, software, and computer-implemented methods for mass propagation. One example method includes deploying a token service to a first cloud platform. A first token request is received from an integration component for a token to be included in a message sent from a first cloud platform to a second cloud platform. A user information request is generated and sent to an identity provider associated with the first cloud platform. The user information is received from an identity provider in response to a user information request. A second token request is generated and sent to a token service provider associated with a second cloud platform. The second token request includes the received user information. The requested token is received from the token service provider. The received token is sent to the integration component to enable the integration component to send a message to the second cloud platform.)
1. A computer-implemented method, comprising:
deploying a token service to a first cloud platform;
receiving, at the token service, a first token request from an integration component for a token to be included in a message sent by the integration component to a second cloud platform representing a user application associated with a user; and
in response to receiving the first token request:
generating a user information request to be sent to an identity provider associated with the first cloud platform;
sending the user information request to the identity provider;
receiving user information about a user from the identity provider in response to the user information request;
generating a second token request to be sent to a token service provider associated with the second cloud platform, the second token request including the received user information;
sending the second token request to the token service provider;
receiving the requested token from the token service provider; and
sending the received token to the integration component to enable the integration component to send the message to the second cloud platform.
2. The method of claim 1, wherein the first token request includes a URL (uniform resource locator) of the token service provider and generating the second token request includes including the URL of the token service provider in the second token request.
3. The method of claim 1, wherein the user information request is sent using a local API (application programming interface) specific to the first set of the first cloud platform.
4. The method of claim 1, wherein the first token request is made using a token request interface provided by the token service.
5. The method of claim 4, further comprising deploying the token service to a third cloud platform, including configuring the token service to: calling a second set of local APIs specific to the second cloud platform; receiving user information provided through the second cloud platform; and receiving a token request from the integrated component using the same token request interface.
6. The method of claim 4, wherein the token service receives a third token request from another integrated component using the token request interface, the other integrated component configured to send a message to a third cloud platform that is a different type of cloud platform than the first and second cloud platforms.
7. The method of claim 6, wherein the token service sends a fourth token request to another token service provider associated with the third cloud platform in response to receiving the third token request.
8. A system, comprising:
one or more computers; and
a computer-readable medium coupled to the one or more computers having instructions stored thereon that, when executed by the one or more computers, cause the one or more computers to perform operations comprising:
deploying a token service to a first cloud platform;
receiving, at the token service, a first token request from an integration component for a token to be included in a message sent by the integration component to a second cloud platform representing a user application associated with a user; and
in response to receiving the first token request:
generating a user information request to be sent to an identity provider associated with the first cloud platform;
sending the user information request to the identity provider;
receiving user information about a user from the identity provider in response to the user information request;
generating a second token request to be sent to a token service provider associated with the second cloud platform, the second token request including the received user information;
sending the second token request to the token service provider;
receiving the requested token from the token service provider; and
sending the received token to the integration component to enable the integration component to send the message to the second cloud platform.
9. The system of claim 8, wherein the first token request includes a URL (uniform resource locator) of the token service provider and generating the second token request includes including the URL of the token service provider in the second token request.
10. The system of claim 8, wherein the user information request is sent using a local API (application programming interface) specific to the first set of the first cloud platform.
11. The system of claim 8, wherein the first token request is made using a token request interface provided by a token service.
12. The system of claim 11, wherein the operations further comprise deploying the token service to a third cloud platform, including configuring the token service to: calling a second set of local APIs specific to the second cloud platform; receiving user information provided through the second cloud platform; and receiving a token request from the integrated component using the same token request interface.
13. The system of claim 11, wherein the token service receives a third token request from another integrated component using the token request interface, the other integrated component configured to send a message to a third cloud platform that is a different type of cloud platform than the first and second cloud platforms.
14. The system of claim 13, wherein the token service sends a fourth token request to another token service provider associated with the third cloud platform in response to receiving the third token request.
15. A computer program product encoded on a non-transitory storage medium, the product comprising non-transitory computer readable instructions to cause one or more processors to perform operations comprising:
deploying a token service to a first cloud platform;
receiving, at the token service, a first token request from an integration component for a token to be included in a message sent by the integration component to a second cloud platform representing a user application associated with a user; and
in response to receiving the first token request:
generating a user information request to be sent to an identity provider associated with the first cloud platform;
sending the user information request to the identity provider;
receiving user information about a user from the identity provider in response to the user information request;
generating a second token request to be sent to a token service provider associated with the second cloud platform, the second token request including the received user information;
sending the second token request to the token service provider;
receiving the requested token from the token service provider; and
sending the received token to the integration component to enable the integration component to send the message to the second cloud platform.
16. The computer program product of claim 15, wherein the first token request includes a URL (uniform resource locator) of the token service provider and generating the second token request includes including the URL of the token service provider in the second token request.
17. The computer program product of claim 15, wherein the user information request is sent using a local API (application programming interface) specific to the first set of the first cloud platform.
18. The computer program product of claim 15, wherein the first token request is made using a token request interface provided by the token service.
19. The computer program product of claim 18, wherein the operations further comprise deploying the token service to a third cloud platform, including configuring the token service to: calling a second set of local APIs specific to the second cloud platform; receiving user information provided through the second cloud platform; and receiving a token request from the integrated component using the same token request interface.
20. The computer program product of claim 18, wherein the token service receives a third token request from another integrated component using the token request interface, the other integrated component configured to send a message to a third cloud platform that is a different type of cloud platform than the first and second cloud platforms.
Technical Field
The present disclosure relates to computer-implemented methods, software, and systems for primary propagation.
Background
With single sign-on (SSO), a user can log-on using a single identifier and password to gain access to multiple systems without having to use multiple user names and passwords for the multiple systems. The main propagation is the process by which the sending system forwards unchanged user context information to the receiving system. SAML (security assertion markup language) is an open standard for exchanging authentication and authorization data between parties. OAuth2 (open authentication version 2) is an open standard for access delegation.
Disclosure of Invention
The present disclosure relates to systems, software and computer-implemented methods for mass propagation. One example method includes deploying a token service to a first cloud platform. A first token request is received from an integration component for a token to be included in a message sent from a first cloud platform to a second cloud platform. A user information request is generated and sent to an identity provider associated with the first cloud platform. The user information is received from an identity provider in response to a user information request. A second token request is generated and sent to a token service provider associated with a second cloud platform. The second token request includes the received user information. The requested token is received from the token service provider. The received token is sent to the integration component to enable the integration component to send a message to the second cloud platform.
While generally described as computer-implemented software embodied on a tangible medium for processing and transforming corresponding data, some or all aspects may be computer-implemented methods or further included in corresponding systems or other devices for performing the described functions. The details of these and other aspects and embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.
Drawings
FIG. 1 is a block diagram illustrating an example system for primary propagation.
Fig. 2 illustrates a system in which the main propagation occurs between various cloud systems.
FIG. 3 is a block diagram illustrating an example of the OAuth2SAML token service.
Fig. 4 illustrates a system in which the OAuth2SAML token service provides a token for a first cloud system to access a second cloud system.
FIG. 5 is a flow diagram of an example method for primary propagation.
Detailed Description
The integration scheme is capable of modeling the integration and connectivity between two computing systems. The different computing systems are capable of communicating, for example, in an enterprise-to-enterprise (B2B) communication, Electronic Data Interchange (EDI), or some other type of system-to-system or server-to-server communication. The integration scheme can include a user using an application provided by the first system. The first system may invoke a service provided by another system. User information can be propagated from a first system to a second system so that services can be performed in the second system on behalf of the user.
The OAuth2SAML token service can be used in the first system to interface with a local API (application programming interface) of the first system for retrieving user information from the first system for generating a token to be passed to the second system. The OAuth2SAML token service can shield the details about how user information is retrieved and how tokens are generated in a particular system from applications and integrated components. The OAuth2SAML token service can encapsulate user information retrieval and token request details-i.e., the application and integration component can simply request the token and pass the received token to the second system without needing to know such details. Although two system scenarios are described, if an application calls multiple services provided by multiple external systems, the OAuth2SAML token service can be used to provide multiple tokens for multiple target systems.
The OAuth2SAML token service can be a reusable, pluggable component that can be deployed to various types of cloud systems to expose various native APIs of the respective cloud systems to the integration component. The integration component is able to use a consistent common interface provided by the OAuth2SAML token service rather than having to learn the details of the differences of the various local APIs that may be found from among the various types of cloud systems. The OAuth2SAML token service can be configured to interface with various types of local APIs provided by various cloud systems.
The OAuth2SAML token service can be extended in the future to interface with new cloud systems that may provide new, different local APIs. The interface to the new, different native API can be encapsulated within the OAuth2SAML token service, and the integrated component can access the new native API of the new cloud system without being changed, using the same consistent interface as provided by the OAuth2SAML token service for the previous cloud system. Encapsulating native API details within OAuth2SAML token service can enable the integration scheme to scale more easily for other and new platforms, as integration components outside of the token service do not need to know the native API details.
Fig. 1 is a block diagram illustrating an example system 100 for primary propagation. In particular, the illustrated environment 100 includes or is communicatively coupled with a client 102, a cloud platform 104, a token service provider 106, a target system 108, and a network 110. A trust relationship can be established between cloud platform 104, token service provider 106, and target system 108. The trust relationship 109a can be generated (e.g., by the trust module 109b) and stored at the token service provider 106 (and/or at other points within the system 100).
A client application 112 running on the client 102 can invoke a cloud application 114 provided by the cloud platform 104. The cloud application 114 can be part of an integration scheme in that the cloud application 114 can be configured to integrate with external cloud applications 116 provided by the target system 108. The cloud application 114 can be configured to invoke the integration services component 118 to interface with the target system 108. The integration services component 118 can provide an integration adapter 120 configured to communicate with the target system 108.
The target system 108 can require that the request for the external cloud application 116 include an authentication credential, such as a token. The cloud platform 104 can provide cloud local APIs 122 for applications that request user information that can be used in token creation. The user information can be stored in user database 124 and managed by identity provider 126, which identity provider 126 is included in cloud platform 104 or otherwise associated with cloud platform 104.
Rather than requiring the integration adapter 120 to know both details about communication with the target system 108 and details about user information retrieval and token creation within the cloud platform 104, the integration adapter 120 can be configured to request tokens from a token service 128 (e.g., OAuth2SAML token service). Decoupling the integration adapter 120 from the local user information retrieval and token creation can enable the integration adapter 120 to be deployed unchanged to a cloud platform other than the cloud platform 104. The token service 128 can encapsulate details specific to a particular cloud system.
The token service 128 is capable of receiving the received token request 130 from the integration adapter 120. The received token request 130 can include, for example, a URL (uniform resource locator) of the token service provider 106 and/or a client identifier associated with the target system 108. The token service 128 can invoke (e.g., as a user information request 131) the cloud local API 122 to request and receive user information about the currently logged-in user. The local-to-general transformer 132 of the token service 128 can include the user information received from the cloud local API in the generated token request 134.
The generated token request 134 can be sent to the token service provider 106 by the token retriever 135 (e.g., using the URL of the token service provider 106). The token generator 136 is capable of generating a token 137 in response to receiving the generated token request 134 and providing the generated token 137 to the token retriever 135 as a received token 138. The target translator 140 is capable of formatting the received token 138 into a target system token 142 that is in a format that is acceptable and processable by the integration adapter 120 and the target system 108.
The target translator 140 is capable of providing a target system token 142 to the integration adapter 120. The integration adapter 120 can include the target system token 142 in the target system message 144. The target system message 144 including the target system token 142 can be sent to the target system 108 for processing by the external cloud application 116. The token analyzer 146 in the target system 108 is able to verify the target system token 142. The external cloud application 116 can process the target system message 144 and generate a response 148. The response 148 can be sent to the integration adapter 120 using the integration services component 118 and forwarded to the cloud application 114.
As used in this disclosure, the term "computer" is intended to encompass any suitable processing device. For example, although FIG. 1 illustrates a single cloud deckA station 104, a single client 102, a single target system 108, and a single token service provider 106, although the system 100 can be implemented using two or more cloud platforms 104, two or more clients 102, two or more target systems 108, and two or more token service providers 106. In practice, the cloud platform 104, the client 102, the target system 108, and the token service provider 106 may be or include any computer or processing device, such as, for example, a blade server, a general-purpose Personal Computer (PC), a personal,
Interfaces 150, 152, 154, and 156 are used by client 102, cloud platform 104, token service provider 106, and target system 108, respectively, for communicating with other systems in a distributed environment connected to network 110, included within system 100. In general, interfaces 150, 152, 154, and 156 each include logic encoded in software and/or hardware in a suitable combination and operable to communicate with network 110. More specifically, interfaces 150, 152, 154, and 156 may each include software that supports one or more communication protocols associated with communications such that network 110 or the hardware of the interfaces is operable to communicate physical signals within and external to illustrated system 100.
The client 102, cloud platform 104, token service provider 106, and target system 108 each include a processor (or processors) 160, 162, 164, or 166, respectively. Each of the processor(s) 160, 162, 164, or 166 may be or include a Central Processing Unit (CPU), a blade, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or another suitable component. In general, each of the processor(s) 160, 162, 164, or 166 executes instructions and manipulates data to perform the operations of the respective computing device.
Regardless of the particular implementation, "software" may include computer-readable instructions on a tangible medium (transitory or non-transitory, as the case may be), firmware, wired and/or programmed hardware, or any combination thereof, that is operable when executed to perform at least the processes and operations described herein. Indeed, it may be in any suitable computer language (including C, C + +, JavaTM、Visual Basic language, assembler,
The client 102, cloud platform 104, token service provider 106, and target system 108 each include memory 170, 172, 174, or 176, respectively. In some implementations, one or more of the described computing devices include multiple memories. Each of memories 170, 172, 174, and 176 may include any type of memory or database module and may take the form of volatile and/or nonvolatile memory including, without limitation, magnetic media, optical media, Random Access Memory (RAM), Read Only Memory (ROM), removable media, or any other suitable local or remote memory component. Each of the memories 170, 172, 174, and 176 may store various objects or data, including directories, classes, frames, applications, backup data, business objects, jobs, web pages, web page templates, database tables, database queries, stores business and/or dynamic information repositories, and any other suitable information, including any parameters, variables, algorithms, instructions, rules, constraints, or references associated therewith for the system 100.
The client 102 may generally be any computing device operable to connect to the cloud platform 104 or communicate with the cloud platform 104 via the network 110 using a wireline or wireless connection. In general, the client 102 comprises an electronic computer device operable to receive, transmit, process, and store any suitable data associated with the system 100 of FIG. 1. The client 102 can include one or more client applications, including a client application 112. A client application is any type of application that allows the client 102 to request and view content on the client 102. In some implementations, the client application can access a particular set of data from the cloud platform 104 using parameters, metadata, and other information received at startup. In some instances, the client application may be a proxy or client-side version of one or more enterprise applications running on an enterprise server (not shown). The processor(s) 160 included in the client 102 each perform the functions required to send requests to the cloud platform 104 and receive and process responses from the cloud platform 104.
The client 102 is generally intended to encompass any client computing device, such as a laptop/notebook computer, a wireless data port, a smart phone, a Personal Data Assistant (PDA), a tablet computing device, one or more processors within these devices, or any other suitable processing device. For example, the client 102 may include a computer that includes an input device such as a keypad, touch screen, or other device capable of accepting user information, and an output device that conveys information associated with the operation of the cloud platform 104 or the client 102 itself, including digital data, visual information, or a GUI (graphical user interface) 180.
GUI180 of client 102 interfaces with at least a portion of system 100 for any suitable purpose, including generating a visual representation of client application 112. In particular, GUI180 may be used to view and navigate various web pages. In general, GUI180 provides the user with an efficient and user-friendly presentation of business data provided by system 100 or communicated within system 100. GUI180 may include a plurality of customizable frames or views having interactive sections, drop down lists, and buttons operated by a user. GUI180 contemplates any suitable graphical user interface, such as a combination of a general purpose web browser, an intelligent engine, and a Command Line Interface (CLI) that processes information and visually presents structure to a user efficiently.
There may be any number of client devices 102 associated with the system 100 or external to the system 100. For example, although the illustrated system 100 includes one client 102, alternative embodiments of the system 100 may include multiple clients 102 communicatively coupled to the cloud platform 104 and/or the network 110, or any other number suitable for the purpose of the system 100. Additionally, there may also be one or more additional client devices 102 external to the illustrated portion of the system 100 that are capable of interacting with the system 100 via the network 110. Furthermore, the terms "client," "client device," and "user" may be used interchangeably, as the case may be, without departing from the scope of this disclosure. Moreover, although the client 102 is described in terms of the client 102 being used by a single user, the present disclosure contemplates that many users may use one computer, or that one user may use multiple computers.
Fig. 2 illustrates a system 200 in which the main propagation occurs between various cloud systems. The user uses an integrated application 202 provided by a cloud platform 204. The integrated application 202 is configured to invoke an application 206 provided by a first cloud system 208 and an application 210 provided by a second cloud system 212. For example, the integration application 202 may be a sales order approval application. The application 206 can be an application that retrieves sales order information stored in the first cloud system 208. The application 210 can be an application that retrieves vendor information from the second cloud system 212. The integration application 202 can be configured to present sales orders and vendor information to the user and, for example, enable the user to approve or reject a particular sales order.
When using the integration application 212, the user is able to provide login information. The integration application 202 can use an API provided by the cloud platform 204 to verify that the login information matches the information stored by the identity provider 214.
The integration application 212 can invoke integration services provided by the cloud platform 204 to connect to the first cloud system 208 and the second cloud system 212. The integration service can include connector components that are each configured to connect to a cloud system of some type. For example, an HTTP (hypertext transfer protocol)/OData connector 216 can be configured to connect to the first cloud system 208, and a third party connector 218 specific to the second cloud system 212 can be configured to connect to the second cloud system 212. The connector assembly can be referred to as an integrated adapter. Other types of connectors are possible, such as OData (open data), SOAP (simple object access protocol), among others. New types of connectors can be supported.
Each connector component can require a token to access a respective cloud system. The cloud platform 204 can provide a token service configured to accept requests for tokens from a given connector component, retrieve user information from the identity provider 214, and request tokens from a token service provider associated with a cloud system associated with the given connector component. The connector component can be provided with a token received from a token service provider through a token service. The connector component can include the token in a request sent to the respective cloud system. For example, the HTTP/OData connector 216 can include the token received from the token service and associated with the first cloud system 208 in a message 220 sent to the first cloud system 208. As another example, the third party connector 218 can include the token received from the token service and associated with the second cloud system 212 in the message 222 sent to the second cloud system 212.
The first cloud system 208 can receive the message 220 and, based on the message 220 including the token associated with the first cloud system 208, enable the message 220 to be received and processed by the application 206. Similarly, the second cloud system 212 can receive the message 222 and enable the message 222 to be received and processed by the application 210 based on the message 222 including the token associated with the second cloud system 212. The applications 206 and 210 can generate respective responses to be returned to the HTTP/OData connector 216 or the third party connector 218, respectively, where each respective connector provides the respective response it receives to the integrated application 202.
Fig. 3 is a block diagram illustrating an example of a token service 300. The token service 300 can be, for example, the OAuth2SAML token service. The token service 300 includes a local-to-general transformer 302 configured to request user information using a local API 304. The local API 304 can be, for example, an OAuth2 API. The request for user information can include configuration information 306 received from a consumer 308 of the token service 300. The consumer 308 can be a connector or an integrated adapter assembly. The configuration information 306 can include a token service URL, a client identifier, or other information of the target system to which the consumer wants to connect.
The local-to-general transformer 302 can transform the user information received from the local API 304 into a token request to be sent by the token retriever 310 to the token service provider. The token retriever 310 can be, for example, an OAuth2SAML token retriever. The token retriever 310 is capable of receiving a token from a token service provider. In some implementations and for some types of tokens, the target runtime converter 312 can perform a transformation of the received token into a format used by the consumer 308. The consumer-specific format can be a format configured for a consumer-specific runtime (e.g., a specific type of archive file). Target runtime translator 312 can provide transformed tokens to consumer 308 such that consumer 308 can use the provided tokens to connect with the target system.
Fig. 4 illustrates a system 400 in which the OAuth2SAML token service provides a token for a first cloud system to access a second cloud system. The initial state of the system 400 in the example of fig. 4 can be as follows: (1) user 402 has registered with cloud platform 404 (e.g., an account is created); (2) a trust relationship has been established between target system 406 and identity provider 408 included in cloud platform 404 (or otherwise associated with cloud platform 404); and (3) the OAuth2SAML token service 410 has been deployed in the cloud platform 404.
In a first phase of the integration scheme (e.g., shown as circled "1"), the user 402 requests access to an application 412 provided by the cloud platform 404. Application 412 can be configured to use or invoke one or more services of target system 406 (and possibly one or more services of one or more other target systems (not shown)).
In the second phase, application 412 sends authentication request 414 to identity provider 408 in response to a request by user 402 to access application 412. Identity provider 408 attempts to authenticate user 402 in response to authentication request 414 and sends an authentication response to application 412.
In the third phase, if the authentication response indicates successful authentication of user 402, application 412 invokes integration service 416 to request communication with target system 406.
In the fourth phase, the integration service 416 identifies and invokes an integration adapter 418 configured to connect to the target system 406. The integration adapter 418 can require authentication of the target system 406.
In the fifth stage, the integration adapter 418 sends a request to the OAuth2SAML token service 410 that includes attributes that can include the token service URL of the target system 406 and the OAuth2 client identifier. The token service URL of the target system 406 can be the URL of the service provided by the target system 406 that generated the OAuth2 token. For example, if the target system 406 is a Success Factor system (Success Factor system), the token service URL may be https:// example-data-center. The OAuth2 client identifier can be an identifier that has been registered by the integration service 416.
In the sixth phase, the OAuth2SAML token service 410 calls the local API(s) 420 of the cloud platform 404 to request user data about the user 402, such as encoded SAML content. The user data can include user context or other user information stored by identity provider 408. The user data can include parameters such as first and last names of the user, a login or username for the cloud platform 404, or an email address for the user 402.
In the seventh stage, the cloud platform 404 provides the requested user data 422 as one or more return or output values of the local API(s) 420.
In the eighth stage, the OAuth2SAML token service 410 uses the received user context information and user data 422 to generate and send a request for an OAuth2 token to the token service provider 424. The request for the OAuth2 token can include the OAuth2 client identifier that the OAuth2SAML token service 410 received from the integration adapter 418. Token service provider 424 is able to determine whether OAuth2 client identifiers have been registered with token service provider 424. If the OAuth2 client identifier has been registered with the token service provider 424, the token service provider 424 is able to generate and provide an OAuth2 token 426 to the OAuth2SAML token service 410.
In the ninth phase, the OAuth2SAML token service 410 provides an OAuth2 token 426 to the integration adapter 418.
In the tenth stage, the integration adapter 418 creates a request 428 (e.g., an HTTP request), which request 428 includes an OAuth2 token 426 and the endpoint of the service in the target system 406 that was invoked by the application 412. The integration adapter 418 sends a request 428 to the target system 406. The target system 406 performs the requested service.
In the eleventh stage, the target system 406 sends a response 430 to the integration adapter 418.
In the twelfth stage, a response 430 is provided by integration service 416 to application 412.
In some implementations, the OAuth2SAM token service 410 caches the OAuth2 token 426 within the cloud platform 404 for use by other call(s) to the target system 406 that may occur prior to the expiration time of the token 426. The stored token can be used instead of requesting another token from the token service provider 424. If the OAuth2SAML token service 410 requires a token for the requested access to the target system 406 after the stored token has expired, the OAuth2SAML token service 410 can request a new token from the token service provider 424.
Fig. 5 is a flow diagram of an example method 500 for dominant propagation. It will be understood that the method 500 and related methods may be performed, for example, by any suitable system, environment, software, and hardware, or combination of systems, environments, software, and hardware, as the case may be. For example, the method 500 and related methods can be performed using one or more of a client, server, or other computing device and any data retrieved from a memory of the client, server, or other computing device. In some embodiments, method 500 and related methods are performed by one or more components of system 100 described above with respect to fig. 1. The method 500 and related methods can be performed, for example, by the token service 128 of FIG. 1.
At 502, a token service is deployed to a first cloud platform. The token service can be, for example, an OAuth2SAML token service.
At 504, a first token request is received at the token service from the integration component for a token to be included in a message sent by the integration component to a second cloud platform representing a user application associated with a user. The first token request can include a URL of the token service provider and/or a client id associated with the token service provider. The first token request can be received through a token request interface provided by a token service.
At 506, in response to receiving the first token request, a user information request is generated for requesting user information about the user.
At 508, a user information request is sent to an identity provider associated with the first cloud platform. The user information request can be sent using a local API specific to the first set of the first cloud platform.
At 510, user information about the user is received from the identity provider in response to the user information request.
At 512, a second token request is generated that includes the received user information. The second token request can include the URL of the token service provider received in the first token request.
At 514, a second token request is sent to a token service provider associated with the second cloud platform.
At 516, the requested token is received from the token service provider. The requested token can be a token generated by the token service provider in response to the second token request.
At 518, the received token is sent to the integration component to enable the integration component to send a message to the second cloud platform. The integration component can send a message including the token to the second cloud platform. The second cloud platform is capable of authenticating the user and processing the message at the second cloud platform.
Although an integration scheme between cloud platforms is described, in some embodiments, the token service can be used within the same cloud platform, such as if it is desired that propagation occur primarily between two applications running on the same cloud platform. In this case, the token requestor can be an integrated component, or can be another component that requests the token to be passed to the calling application to propagate the credentials used when initiating the calling application.
The foregoing figures and the accompanying description illustrate example processes and computer-implementable techniques. It is contemplated that system 100 (or software or other components thereof) uses, implements, or performs any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any suitable time, including in parallel, independently, or in combination. Further, many of the operations in these processes may occur simultaneously, in parallel, and/or in different orders than as shown. Moreover, the system 100 may use processes with additional operations, fewer operations, and/or different operations, so long as the methods remain appropriate.
In other words, while the present disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.
- 上一篇：一种医用注射器针头装配设备
- 下一篇：大规模实时多媒体通信技术