Authorization information for invoking a management service

Abstract

Example embodiments of the present disclosure relate to authorization information for invoking a management service. In one aspect, a first device sends a request for authorization information to a second device. The authorization information is used to invoke a management service by an application program interface (API) invoker based on access rights controlled by the second device, and the second device is located in a second domain different from a first domain of the first device. The first device also receives the authorization information from the second device.

Description

Technical Field

[0001] The exemplary embodiments of this disclosure generally relate to the field of communications, and more specifically to devices, methods, apparatuses, and computer-readable storage media for providing authorization information for invoking management services. Background Technology

[0002] A communication network can be viewed as a facility that enables communication between two or more communication devices, or provides communication devices with access to a data network. Mobile or wireless communication networks are an example of communication networks. Application servers can provide services to communication devices.

[0003] Such communication networks operate according to standards provided by organizations such as 3GPP (3rd Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of these standards are the so-called 5G (fifth generation) standard, the 6G (sixth generation) standard, or other standards provided by 3GPP. Summary of the Invention

[0004] Overall, the exemplary embodiments of this disclosure provide a solution for providing authorization information for invoking management services.

[0005] In a first aspect, a first apparatus is provided. The first apparatus includes at least one processor and at least one memory storing instructions, which, when executed by the at least one processor, cause the first apparatus to at least perform: sending a request for authorization information to a second apparatus. The authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second apparatus, and the second apparatus is located in a second domain different from a first domain of the first apparatus. The first apparatus is also configured to receive the authorization information from the second apparatus.

[0006] In a second aspect, a second apparatus is provided. The second apparatus includes at least one processor and at least one memory storing instructions, which, when executed by the at least one processor, cause the second apparatus to at least perform: receiving a request for authorization information from a first apparatus. The authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second apparatus, and the second apparatus resides in a second domain different from a first domain of the first apparatus. The second apparatus is also configured to verify the request and, based on determining that the request is valid and permitted, send the authorization information to the first apparatus.

[0007] In a third aspect, a method is provided. The method includes sending a request for authorization information to a second device. This authorization information is used by an API caller to invoke a management service based on access permissions controlled by the second device, and the second device is located in a second domain different from the first device's first domain. The method also includes receiving the authorization information from the second device.

[0008] In a fourth aspect, a method is provided. The method includes receiving a request for authorization information from a first device. This authorization information is used by an API caller to invoke a management service based on access permissions controlled by a second device, and the second device is located in a second domain different from the first device's first domain. The method also includes verifying the request; and, based on determining that the request is valid and permitted, sending the authorization information to the first device.

[0009] In a fifth aspect, an apparatus is provided. The apparatus includes components for sending a request for authorization information to a second device. This authorization information is used by an API caller to invoke a management service based on access permissions controlled by the second device, and the second device is located in a second domain different from a first device's first domain. The apparatus also includes components for receiving the authorization information from the second device.

[0010] In a sixth aspect, an apparatus is provided. The apparatus includes components for receiving a request for authorization information from a first device. The authorization information is used by an API caller to invoke a management service based on access permissions controlled by a second device, and the second device is located in a second domain different from a first domain of the first device. The apparatus includes components for verifying the request; and components for sending the authorization information to the first device based on determining that the request is valid and permitted.

[0011] In a seventh aspect, a non-transitory computer-readable medium is provided, comprising program instructions for causing a device to execute at least the method according to any one of the third to fourth aspects.

[0012] In an eighth aspect, a computer program is provided that includes instructions, when executed by a device, to cause the device to perform at least the method according to any one of the third to fourth aspects.

[0013] In a ninth aspect, a first apparatus is provided. The first apparatus includes: a transmitting circuitry configured to send a request for authorization information to a second apparatus. The authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second apparatus, and the second apparatus is located in a second domain different from a first domain of the first apparatus. The first apparatus also includes a receiving circuitry configured to receive the authorization information from the second apparatus.

[0014] In a tenth aspect, a second apparatus is provided. The second apparatus includes: a receiving circuitry configured to receive a request for authorization information from a first apparatus. The authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second apparatus, and the second apparatus is located in a second domain different from a first domain of the first apparatus. The second apparatus includes a verification circuitry configured to verify the request; and a sending circuitry configured to send the authorization information to the first apparatus based on determining that the request is valid and permitted.

[0015] It should be understood that the summary portion is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0016] Some exemplary embodiments will now be described with reference to the accompanying drawings, in which:

[0017] Figure 1A The illustration shows an example network environment in which exemplary embodiments of this disclosure can be implemented;

[0018] Figure 1B The illustration shows another example of a network environment associated with an exemplary embodiment of this disclosure;

[0019] Figure 2 The illustration shows flowcharts of methods according to some embodiments of the present disclosure;

[0020] Figure 3 The illustration depicts an exemplary scenario, according to some embodiments of the present disclosure, where authorization information needs to be exchanged before a service API call (initiated by the API caller) occurs;

[0021] Figure 4 Examples of signaling flow cases according to some embodiments of this disclosure are illustrated;

[0022] Figure 5 The illustration shows an example of another signaling flow case according to some embodiments of the present disclosure;

[0023] Figure 6 The illustration shows a flowchart of a method implemented at a device according to some exemplary embodiments of the present disclosure;

[0024] Figure 7 The illustration shows a flowchart of a method implemented at a device according to some exemplary embodiments of the present disclosure;

[0025] Figure 8 The illustration shows a simplified block diagram of a device suitable for implementing some example embodiments of the present disclosure; and

[0026] Figure 9 A block diagram illustrating an example of a computer-readable medium 1000 according to some exemplary embodiments of the present disclosure is shown.

[0027] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0028] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and to assist those skilled in the art in understanding and implementing this disclosure, and do not constitute any limitation on the scope of this disclosure. The disclosure described herein can be implemented in various ways other than those described below.

[0029] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0030] In this disclosure, references to "an embodiment," "embodiment," and "example embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment must include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, those skilled in the art will understand that, whether explicitly described or not, combining it with other embodiments to affect such a feature, structure, or characteristic is within the knowledge of those skilled in the art.

[0031] It should be understood that although the terms "first," "second," etc., may be used to describe various elements herein, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0032] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. The singular forms “a,” “an,” and “the” used herein also include the plural forms unless the context clearly indicates otherwise. Further understanding, the terms “comprises,” “comprising,” “has,” “having,” “includes,” and / or “including”, when used herein, specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. As used herein, “at least one of the following: ” and “<at least one of a list of two or more elements>” and similar wording (where a list of two or more elements is connected by “and” or “or”) means at least any one of these elements, or at least any two or more of these elements, or at least all of these elements.

[0033] As used in this application, the term "circuit system" may refer to one or more or all of the following: (a) Purely hardware circuits (such as in analog and / or digital circuits), and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits and software (e.g., firmware), and (ii) Any part of a hardware processor (including multiple digital signal processors), software, and memory (multiple processors) having software, which work together to enable a device (such as a mobile phone or server) to perform various functions, and (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may be absent when operation is not required.

[0034] The definition of "circuit system" applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term "circuit system" also covers only hardware circuitry or a processor (or processors) or a portion of hardware circuitry or a processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0035] As used herein, the term "cellular network" refers to a network operating according to any suitable radio access technology defined by standards, such as Long Term Evolution (LTE), LTE-A Advanced (LTE-A), New Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a cellular network can be performed according to any suitable generation of communication protocols, including but not limited to fourth-generation (4G), 4.5G, future fifth-generation (5G) communication protocols, and / or any other currently known or future-developed protocols. Embodiments of this disclosure can be applied to a variety of cellular networks. Given the rapid development of communications, there will naturally be future types of communication technologies and systems that can be used to embody the present disclosure. This should not be construed as limiting the scope of this disclosure to the systems described above.

[0036] As used herein, the term "network device" refers to any device in a cellular network through which terminal devices access the data network and receive services offered by other network devices in that cellular network. In some examples, a network device may include or implement the network functions of a fifth-generation communication system (5GS) (e.g., the core network) of the cellular network. In some examples, a network device may be located in the RAN of a 5GS. A network device may be part of a satellite, base station (BS), or access point (AP), such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB), a remote radio unit (RRU), a radio header (RH), a remote radio header end (RRH), a relay, or a low-power node (such as a femto, pico, etc.), depending on the terminology and technology applied. A gNB may include a centralized unit (CU) and one or more distributed units (DUs). Femto and pico nodes are small base stations with small coverage areas.

[0037] The term "terminal device" refers to a device in a cellular network communication system (such as a fifth-generation communication system (5GS)) that is capable of wireless (e.g., radio) communication with the 5GS's NR-RAN. As an example and not a limitation, a terminal device may also be referred to as a wireless communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Examples of terminal devices include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop mounted devices (LMEs), USB dongles, smart devices, wireless customer premises equipment (CPEs), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, commercially operated devices and / or industrial wireless networks, etc. In the following description, the terms "terminal device," "communication device," "terminal," "user equipment," and "UE" are used interchangeably.

[0038] As used herein, an API caller refers to an entity that invokes a CAPIF or service API. A resource refers to the object or component on which an operation on an API is performed. A resource owner refers to a UE user or MNO subscriber who can grant access to protected resources associated with the invoked API via resource owner functions. Resource owner functions refer to an entity that enables the authorization of resource access and manages and revokes the authorization of resource access. A CAPIF provider domain refers to a domain that contains instances of the core CAPIF functionality and may contain both API provider domains and API callers. A CAPIF provider can be a Public Land Mobile Network (PLMN), a Standalone Non-Public Network (SNPN), or a third party. In the embodiments of this application, a PLMN trust domain is typically used as a typical deployment of a CAPIF provider domain; however, an SNPN trust domain or a third-party trust domain is equally applicable.

[0039] The Common API Framework (CAPIF) is defined as a single, harmonized platform for all 3GPP Capability Open APIs (Network Northbound APIs and Application Enablement Layer APIs) and any non-3GPP defined APIs (i.e., APIs defined by other SDOs or alliances, such as ETSI ISG MEC, TM Forum, CAMARA, etc.). CAPIF provides common functionalities applicable to any set of network or service APIs, such as API publishing, API discovery, API open functionality (e.g., NEF) management, API caller (e.g., application function) onboarding management, security (e.g., NBI API access control), routing management, auditing, and accounting. In its security, authentication, and authorization functions, CAPIF also enables the collection and management of user consent for applications requiring end-user consent.

[0040] CAPIF introduces a consistent approach to general support capabilities, simplifying the development and rapid deployment of applications (AFs) that call APIs such as the 3GPP Network and Services API.

[0041] In many scenarios, a device (such as the CAPIF Core Function (CCF) in CAPIF) needs to interact with an external authorization function to obtain (and forward to the API caller) the appropriate access token (or the corresponding authorization information required for the call). Typically, this authorization function resides in a different domain than the device (such as the CCF).

[0042] In view of the above, an example embodiment of this disclosure provides a solution for providing authorization information for invoking management services. In an example embodiment of this disclosure, a first device may send a request for authorization information to a second device. This authorization information is used by an API caller to invoke the management service based on access permissions controlled by the second device, and the second device is located in a second domain different from the first device's first domain. The first device may also receive the authorization information from the second device.

[0043] Thus, according to some embodiments of this disclosure, a new reference point CAPIF-X / Xe and associated signaling messages required to enable the exchange of authorization-related information between different domains are introduced in CAPIF. Based on this new CCF interface, external management service (MnS) consumers are authorized to access the management service API published and discoverable via CCF.

[0044] Figure 1A An example of a network environment 100a that can implement exemplary embodiments of the present disclosure is illustrated. Environment 100a may be part of a communication network, including multiple terminal devices, network devices, and network elements.

[0045] like Figure 1AAs shown, the communication system 100a may include a first device 110 and a second device 120, a terminal device 130 (hereinafter also referred to as the first terminal device 130 or UE 130), a terminal device 140 (hereinafter also referred to as the second terminal device 140 or UE 140), and a base station 150. In some embodiments, the first device 110 may be a network element (NE) or network function in the network, such as the CAPIF core function (CCF), and the second device 120 may be an NE or network function in the network, such as an Authentication and Authorization Management Service (AA MnS) producer or authorization function.

[0046] In some other embodiments, terminal device 130 and / or terminal device 140 may be an external MnS consumer or API caller. Base station 150 may manage cell 101. Terminal device 130 or terminal device 140 may communicate with base station 150 within the coverage area of ​​cell 101. Base station 150 is connected to first device 110 and second device 120. Terminal device 130 may communicate with terminal device 140 via first device 110, second device 120 and base station 150. It should also be noted that, although Figure 1A API callers are included or deployed on the terminal device, but they are not always included or deployed on the terminal device. For example, API callers can be deployed in any of the following ways: API callers can be deployed on the UE as an application function (AF) (i.e., a third-party application); API callers can be deployed on the UE as an AF supporting multiple other third-party applications deployed on the UE; API callers can be deployed in the network as an AF.

[0047] It should be understood that the number of devices is for illustrative purposes only and does not indicate any limitation. System 100a may include any suitable number of terminal devices or network devices suitable for implementing embodiments of this disclosure. Although not shown, it should be understood that one or more terminal devices or network devices may be present in system 100a.

[0048] Figure 1B An example of another network environment 100b associated with an exemplary embodiment of this disclosure is illustrated. An authorization function, as an internal entity of the CAPIF Core Function (CCF) of the first device 110, is included for distributing access tokens when authorization from the resource owner is required to grant access to a protected resource.

[0049] After successfully authenticating the resource owner and obtaining authorization from the resource owner via the resource owner function, the authorization function distributes an access token to the API caller.

[0050] The authorization function is envisioned only within the context of a resource owner authorizing access to protected resources (e.g., PII data). However, other scenarios exist where the CCF / authorization function itself cannot distribute access tokens and instead needs to forward requests to an "external" authorization function, regardless of whether a resource owner is involved. A typical scenario is when an external Management Service (MnS) consumer needs to be authorized to access the Management Service API, and the Authentication and Authorization (AA) MnS producer (which performs the aforementioned authorization) is located in a different domain than the CCF (meaning the AA MnS producer will act as the external authorization function).

[0051] Figure 2 A flowchart illustrating a method according to some embodiments of the present disclosure is shown. For discussion purposes, reference will be made to... Figure 1A Method 200 is described. It should be understood that although process flowchart 200 has been referenced... Figure 1A The process flowchart 200 is described, but it can also be applied to other similar communication scenarios.

[0052] In process flowchart 200, first device 110 may send (205) a request 202 for authorization information to second device. In some embodiments, authorization information 202 is used by an API caller to invoke management services based on access permissions controlled by the second device, and the second device 120 is located in a second domain different from the first domain of first device 110.

[0053] The second device 120 can then verify (215) the request 202. In some other embodiments, the second device 120 can send (220) authorization information 204 to the first device 110 based on determining that the request is valid and permitted. The first device 110 can then receive (225) authorization information 204 from the second device 120.

[0054] In some other embodiments, the second device 120 may extract the API caller's API caller identifier from the request 202 based on determining that the request is valid. The second device 120 may then map the API caller to a Management Service Access Control (MSAC) identifier and generate authorization information including the MSAC identifier. In some embodiments, the MSAC identifier is mapped to an authorized API that the API caller is authorized to invoke.

[0055] In some example embodiments, the first device 110 may send the API caller's joining credentials to the second device 120. The second device 120 may then receive the API caller's joining credentials from the first device and verify them.

[0056] In some other example embodiments, the second device 120 may retrieve the MSAC identifier associated with the API caller's join credentials based on determining that the API caller's join credentials are valid. The second device 120 may then send a response indicating that the join credentials are valid to the first device 110. The first device 110 may receive the response indicating that the join credentials are valid from the second device 120.

[0057] In some example embodiments, the first device 110 may send the API caller identifier of the API caller to the second device 120. After receiving the API caller identifier from the first device 110, the second device 120 may send an acknowledgment of the API caller identifier to the first device 110. The first device 110 can then receive the acknowledgment of the API caller identifier from the second device 120. In some other embodiments, the second device 120 may associate the API caller identifier of the API caller with a retrieved MSAC identifier.

[0058] In some example embodiments, the first device 110 may send the API caller's joining credentials to the second device 120, and the joining credentials may include the API caller's API caller identifier. After receiving the API caller's joining credentials from the first device 110, the second device 120 may verify the API caller's joining credentials. Based on determining that the API caller's joining credentials are valid, the second device 120 may retrieve the MSAC identifier associated with the API caller's joining credentials.

[0059] The second device 120 can then associate the retrieved MSAC identifier with the API caller's API caller identifier and send a response to the first device 110 indicating that the joining credential is valid and the mapping to the MSAC identifier was successfully executed. In some other embodiments, the first device 110 may purge the API caller identifier based on receiving a response indicating that the joining credential is invalid or the mapping to the MSAC identifier was not executed. In some embodiments, the response may include the API caller's API caller identifier.

[0060] In some other embodiments, authorization information may include an MSAC identifier that is mapped to a permitted API that the API caller is authorized to invoke. In some other embodiments, the exchange of authorization-related information between the first device 110 and the second device 120 is performed via a dedicated generic API framework reference point, such as the (CAPIF)-X reference point or the CAPIF-Xe reference point. In some other embodiments, X may represent a number.

[0061] Figure 3The illustration depicts an exemplary scenario where authorization information needs to be exchanged before a service API call (initiated by the API caller) occurs, according to some embodiments of the present disclosure. It should be noted that process flowchart 300 can be considered as another example of network environment 100a. For example, CCF 310 can be included in one of the example devices of the first device 110, and authorization functions 320 and 330 can be included in one of the example devices of the second device 120. API caller 340 can be included in one of the example devices of the terminal device 130 or network device. It should be understood that these devices are described for illustrative purposes only and do not imply any limitation on the scope of the present disclosure.

[0062] In some embodiments, API caller 340 may correspond to an external API caller. In some other embodiments, API provider domain 1 may be a domain in which the Network Open Function (NEF) implementation conforms to a service-specific aspect of the CAPIF architecture. API provider domain 2 may be provided by a PLMN management domain. API provider domain 3 may be a third-party domain, such as corresponding to a Non-Public Network (NPN) domain or a third-party quantum computing infrastructure domain.

[0063] For API provider domains 2 and 3, each domain may have an authorization function 320 or 330. These authorization functions 320 and 330, located outside of CCF 310, are responsible for providing the API caller 340 (via CCF 310) with the necessary authorization information so that the API caller 340 can use it at the time of the call. This authorization information may correspond to, for example, an access token.

[0064] Figure 4 The illustration shows an example of a signaling flow according to some embodiments of the present disclosure. Figure 4 CCF 410 in the text can represent, for example, the first device 110. Figure 4 The AA MnS producer or external licensing function 420 in the text can represent, for example, the second device 120. Figure 4 The external MnS consumer or API caller 430 can represent, for example, terminal device 130 or network device. The external MnS consumer (acting as the API caller) 430 is provided with the corresponding authorization information to consume management services published and discoverable via CCF 410.

[0065] At 402, a prerequisite exists that an offline CAPIF registration process may be prepared. In some embodiments, there may be offline registration / subscription for an external MnS consumer 430, to which access credentials are provided in the process (distributed by the AA MnS producer 420, which acts as an external authorization function in the management domain).

[0066] The registration process involves the management system administrator assigning a specific identifier, called a Management Service Access Control (MSAC) identifier, to the API caller 430. The MSAC identifier is mapped to one or more access roles associated with the API caller 430 within the management system. Each role can then be associated with one or more access rules that define which managed objects (e.g., cells) the API caller can access and what permitted operations (e.g., read, write, delete, etc.) it can perform on those managed objects. This management access control information (i.e., MSAC identifier, MSAC role, and MSAC access rules) is configured in the AA MnS producer 420. The MSAC model has been specified in the specification.

[0067] At 404, the API caller joining process can begin. At 406, in order to begin the joining process, the external MnS consumer 430, acting as the API caller 430, can establish a secure connection with CCF 410 based on TLS server-side authentication. The server certificate is the CCF's root CA, which is sent to the API caller 430 after registration.

[0068] At 408, API caller 430 may send a join API caller request to CCF 410 via the CAPIF-1 / CAPIF-1e interface. This request involves providing join registration information using the “APIInvokerEnrolmentDetails” data type. This data type includes join credentials, which are sent to API caller 430 after registration. In some embodiments, alternatively or additionally, CCF 410 may send an acknowledgment to the API caller confirming receipt of the join API caller request (…). Figure 4 (Not shown in the text), which may turn step 432 into a notification (rather than a response).

[0069] At 412, CCF 410 can extract the "Joining Credential" from the APIInvokerEnrolmentDetails data type and send it to the AA MnS producer (external authorization function) 420 via the CAPIF-Xe reference point. At 414, the AA MnS producer (external authorization function) 420 can verify the received "Joining Credential".

[0070] At 416, in some embodiments, if the "join credential" is valid (i.e., during the offline registration / subscription phase of the external MnS consumer), the AA MnS producer (external authorization function) 420 can retrieve the domain-specific identity instance associated with the join credential (i.e., the Management Service Access Control (MSAC) identity instance associated with the external MnS consumer). The retrieved MSAC identity instance can represent authorization information associated with the API caller.

[0071] At 418, the AA MnS producer (external authorization function) 420 can send a "join credentials ok" response to CCF 410 via the CAPIF-Xe reference point. In some embodiments, at 422, upon receiving the "join credentials ok" notification, CCF 410 can generate an API caller ID representing a unique identifier of the API caller within CCF 410.

[0072] At point 424, CCF 410 can send the newly generated API caller ID to AA MnS producer (external authorization function) 420 via the CAPIF-Xe reference point. At point 426, after receiving the "generated API caller ID", AA MnS producer (external authorization function) 420 can send an acknowledgment to CCF via the CAPIF-Xe reference point.

[0073] At 428, the AA MnS producer (external authorization function) 420 can associate the received API caller ID with the stored MSAC identifier associated with the external MnS consumer 430 (from step 416). It should be noted that steps 426 and 428 can be interchanged.

[0074] At 432, CCF 410 can send a Join API Caller response to API Caller 430, with the response body represented by the "APIInvokerEnrolmentDetails" data type. In some embodiments, the response may include an assigned API Caller ID.

[0075] In some other embodiments, to gain access to one or more service APIs, the API caller needs to obtain authorization using the OAuth 2.0 framework built into CAPIF. This authorization process is a two-phase process: service API call authorization request (steps 436-454) 434 and service API call 456. At 436, when the API caller 430 wants to call a specific service API, it establishes a TLS session with CCF 410 based on certificate-based mutual authentication.

[0076] At 438, API caller 430 can send an access token request to CCF 410 to invoke a specific service API(s), providing the API caller ID and optionally a list of the service API(s) it wishes to invoke. In some alternative embodiments, the request body may carry information described by the AccessTokenReq data type. At 442, CCF 410 can verify the request. At 444, if the request is valid, CCF 410 can forward the access token request to AA MnS producer (external authorization function) 420 via the CAPIF-Xe reference point.

[0077] At 446, the AA MnS producer (external authorization function) 420 can verify the request. At 448, if the request is valid, the AA MnS producer (external authorization function) 420 can extract the API caller ID from the access token request and map it to the associated MSAC identifier. In some embodiments, the AA MnS producer (external authorization function) 420 can generate an access token that will contain the MSAC identifier as part of the token scope statement, which will be mapped to the allowed API (MnS) that the API caller 430 is authorized to call on the MnS producer 420 (i.e., AEF in the CAPIF terminology).

[0078] At 452, the AA MnS producer (external authorization function) 420 can send the generated access token to CCF 410 via the CAPIF-Xe reference point. At 454, upon receiving the access token, CCF 410 can forward the received access token response to the API caller 430. In some embodiments, CCF 410 can send a "Service API Authorization Response" carrying information described by the AccessTokenRsp data type. At 458, the API caller 430 can successfully invoke the service API at AEF (located within MSED 440).

[0079] Figure 5 An example of another signaling flow case according to some embodiments of this disclosure is illustrated. Figure 5 CCF510 in the text can represent, for example, the first device 110. Figure 5 The AA MnS producer 520 in the text can represent, for example, the second device 120. Figure 5 The external MnS consumer or API caller 530 can represent, for example, terminal device 130 or network device. The external MnS consumer (acting as the API caller) 530 is provided with the corresponding authorization information to consume management services published and discoverable via CCF 510. Figure 5 Presented Figure 4The signaling alternatives shown have altered the first part of the information flow. Figure 5 In this context, "management domain" corresponds to the API provider domain, which, according to this disclosure, also includes (external) authorization functionality.

[0080] At 502, a prerequisite exists that an offline CAPIF registration process may be prepared. In some embodiments, there may be offline registration / subscription of an external MnS consumer 530, which is provided with access credentials (distributed by an AA MnS producer 520 acting as an external authorization function in the management domain).

[0081] The registration process involves the management system administrator assigning a specific identifier, called a Management Service Access Control (MSAC) identifier, to the API caller 530. The MSAC identifier is mapped to one or more access roles associated with the API caller 530 within the management system. Each role can then be associated with one or more access rules that define which managed objects (e.g., cells) the API caller can access and what permitted operations (e.g., read, write, delete, etc.) it can perform on those managed objects. This management access control information (i.e., MSAC identifier, MSAC role, and MSAC access rules) is configured in the AA MnS producer 520. The MSAC model has been specified.

[0082] To initiate the joining process 504, at 506, the API caller 530 can establish a secure connection with CCF 510 based on TLS server-side authentication. The server certificate is the CCF's root CA, which is sent to the API caller after registration.

[0083] At point 508, API caller 530 can send a join API caller request to CCF 510 via the CAPIF-1 / CAPIF-1e interface. This request involves providing join registration information using the "APIInvokerEnrolmentDetails" data type. This data type includes join credentials, which are sent to the API caller after registration. In some other embodiments, CCF 510 can send an acknowledgment to the API caller confirming receipt of the join API caller request. Figure 5 (not shown in the image), which may turn step 526 into a notification (rather than a response).

[0084] At 512, CCF 510 can generate an API caller ID, which represents a unique identifier for the API caller within CCF 510. At 514, CCF 510 can obtain the "joining credential" from the APIInvokerEnrolmentDetails data type and send it (including the generated API caller ID) to the AA MnS producer (external authorization function) 520 via the CAPIF-Xe reference point.

[0085] At point 516, the AA MnS producer (external authorization function) 520 can verify the received "join credential". At point 518, if the "join credential" is valid (i.e., during the offline registration / subscription phase of the external MnS consumer), the AA MnS producer (external authorization function) 520 can retrieve the MSAC identity instance associated with the join credential. The retrieved identity instance can represent the authorization information of the API caller 530.

[0086] At 522, the AA MnS producer (external authorization function) can associate the retrieved MSAC identifier with the received API caller ID. At 524, the AA MnS producer (external authorization function) 520 can send a response to CCF 510 (via the CAPIF-Xe reference point) indicating that the "join credential" is valid and the mapping to the MSAC identifier has been performed, and optionally return the API caller ID (from step 514). In some additional embodiments, if the results of steps 518-522 fail, CCF 510 can clear the API caller ID generated in step 512. At 526, CCF 510 can send a join API caller response to API caller 530, the response body being represented by the "APIInvokerEnrolmentDetails" data type. This response includes the assigned API caller ID.

[0087] In some other embodiments, to gain access to one or more service APIs, API caller 530 needs to authorize using the OAuth 2.0 framework built into CAPIF. This authorization process is a two-phase procedure: service API call authorization request (steps 532-548) 528 and service API call 552. At 532, when API caller 530 wants to call a specific service API, it establishes a TLS session with CCF 510 based on certificate-based mutual authentication.

[0088] At 534, API caller 530 can send an access token request to CCF 510 to invoke a specific service API(s), providing the API caller ID and optionally a list of the service API(s) it wishes to invoke. In some alternative embodiments, the request body may carry information described by the AccessTokenReq data type. At 536, CCF 510 can verify the request. At 538, if the request is valid, CCF 510 can forward the access token request to AA MnS producer (external authorization function) 520 via the CAPIF-Xe reference point.

[0089] At 542, the AA MnS producer (external authorization function) 520 can verify the request. At 544, if the request is valid, the AA MnS producer (external authorization function) 520 can extract the API caller ID from the access token request and map it to the associated MSAC identifier. In some embodiments, the AA MnS producer (external authorization function) 520 can generate an access token that will contain the MSAC identifier as part of the token scope statement, which will be mapped to the allowed API (MnS) that the API caller 530 is authorized to call on the MnS producer 520 (i.e., AEF in CAPIF terminology). At 546, the AA MnS producer (external authorization function) 520 can send the generated access token to the CCF 510 via the CAPIF-Xe reference point.

[0090] At 548, upon receiving the access token, CCF 510 can forward the received access token response to API caller 530. In some embodiments, CCF 510 can send a "Service API Authorization Response" carrying information described by the AccessTokenRsp data type. At 554, API caller 530 can successfully invoke the service API at AEF (located within MSED 540).

[0091] Figure 6 A flowchart illustrating a method 600 implemented at an apparatus according to some exemplary embodiments of the present disclosure is shown. Reference will be made for discussion purposes. Figure 1A Method 600 is described from the perspective of the first device 110.

[0092] At box 602, the first device 110 may send a request for authorization information to the second device. This authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second device, and the second device is located in a second domain different from the first device's first domain. At box 604, the first device 110 may receive the authorization information from the second device.

[0093] In some embodiments, the first device may send the API caller's joining credentials to the second device. In some embodiments, the first device may receive a response from the second device indicating that the joining credentials are valid.

[0094] In some embodiments, the first device may send the API caller identifier of the API caller to the second device and receive confirmation of the API caller identifier from the second device.

[0095] In some embodiments, the first device may send the API caller's joining credentials to the second device, and the joining credentials include the API caller's API caller identifier. The first device may receive a response from the second device indicating whether the joining credentials are valid and whether the mapping to the Management Service Access Control (MSAC) identifier was successfully performed.

[0096] In some embodiments, the first device may clear the API caller ID based on receiving a response indicating that the joining credential is invalid or that the mapping to the MSAC ID was not performed. In some other embodiments, the response may include the API caller ID of the API caller.

[0097] In some example embodiments, authorization information includes an MSAC identifier that is mapped to a permitted API that the API caller is authorized to invoke. In some embodiments, the exchange of authorization-related information between the first and second devices is performed via a dedicated Common API Framework (CAPIF) reference point.

[0098] In some example embodiments, the first device may include CAPIF core functionality (CCF). In some example embodiments, the second device may include Authentication and Authorization Management Service (AA MnS) producer or authorization functionality.

[0099] Figure 7 A flowchart illustrating a method 700 implemented at a second device according to some exemplary embodiments of the present disclosure is shown. Reference will be made to this flowchart for discussion purposes. Figure 1A Method 700 is described from the perspective of the second device 120.

[0100] In box 702, the second device 120 may receive a request for authorization information from the first device. This authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second device, and the second device resides in a second domain different from the first device's first domain. In box 704, the second device 120 may verify the request. In box 706, the second device 120 may send authorization information to the first device based on determining that the request is valid and permitted.

[0101] In some embodiments, the second apparatus may extract the API caller's identifier from the request based on determining that the request is valid. The second apparatus may map the API caller to a Management Service Access Control (MSAC) identifier. The second apparatus may generate authorization information including the MSAC identifier. In some embodiments, the MSAC identifier is mapped to allowed APIs that the API caller is authorized to invoke.

[0102] In some embodiments, the second device may receive the API caller's joining credentials from the first device. The second device may then verify the API caller's joining credentials.

[0103] In some embodiments, the second device may retrieve the MSAC identifier associated with the API caller's join credentials based on determining that the join credentials of the API caller are valid. The second device may send a response to the first device indicating that the join credentials are valid.

[0104] In some embodiments, the second device may receive an API caller identifier from the first device. In some embodiments, the second device may send an acknowledgment of the API caller identifier to the first device.

[0105] In some embodiments, the second device may associate the API caller's API caller identifier with the retrieved MSAC identifier. In some embodiments, the second device may receive the API caller's joining credentials from the first device, and the joining credentials include the API caller's API caller identifier. In some embodiments, the second device may verify the API caller's joining credentials.

[0106] In some embodiments, the second device may retrieve the MSAC identifier associated with the API caller's join credentials based on determining that the API caller's join credentials are valid. In some embodiments, the second device may associate the retrieved MSAC identifier with the API caller's API caller identifier. In some embodiments, the second device may send a response to the first device indicating that the join credentials are valid and that the mapping to the MSAC identifier was successfully performed. The response includes the API caller's API caller identifier.

[0107] In some embodiments, the exchange of authorization-related information between the first and second devices is performed via a dedicated Common API Framework (CAPIF) reference point. In some embodiments, the first device may include CAPIF Core Functions (CCF). In some embodiments, the second device may include Authentication and Authorization Management Service (AA MnS) producer or authorization functionality.

[0108] In some embodiments, the means capable of performing method 600 (e.g., first means 110) may include components for performing corresponding steps of method 600. These components may be implemented in any suitable form. For example, the components may be implemented as a circuit system or a software module.

[0109] In some embodiments, the apparatus includes components for sending a request for authorization information to a second device. This authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second device, and the second device resides in a second domain different from the first device's first domain. In some embodiments, the apparatus includes components for receiving authorization information from the second device.

[0110] In some embodiments, the apparatus further includes components for sending the API caller's joining credentials to the second apparatus. In some embodiments, the apparatus further includes components for receiving a response from the second apparatus indicating that the joining credentials are valid.

[0111] In some example embodiments, the apparatus further includes components for sending an API caller identifier of the API caller to a second device, and components for receiving acknowledgment of the API caller identifier from the second device.

[0112] In some example embodiments, the apparatus includes components for sending an API caller's joining credentials to a second device, the joining credentials including an API caller identifier of the API caller. In some example embodiments, the apparatus also includes components for receiving a response from the second device, the response indicating whether the joining credentials are valid and whether the mapping to the Management Service Access Control (MSAC) identifier was successfully performed.

[0113] In some example embodiments, the apparatus includes components for clearing the API caller identifier based on a response indicating that the joining credential is invalid or that the mapping to the MSAC identifier has not been performed. In some other embodiments, the response may include the API caller's API caller identifier.

[0114] In some example embodiments, authorization information includes an MSAC identifier that is mapped to a permitted API that the API caller is authorized to invoke. In some embodiments, the exchange of authorization-related information between the first and second devices is performed via a dedicated Common API Framework (CAPIF) reference point.

[0115] In some example embodiments, the device may include CAPIF Core Functionality (CCF). In some example embodiments, the second device may include Authentication and Authorization Management Service (AA MnS) producer or authorization functionality.

[0116] In some embodiments, the apparatus further includes components for performing other steps in some embodiments of method 600. In some embodiments, the components include at least one processor and at least one memory, the at least one memory including computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause the apparatus to execute.

[0117] In some embodiments, the apparatus capable of performing method 700 (e.g., second means 120) may include components for performing the corresponding steps of method 700. These components may be implemented in any suitable form. For example, the components may be implemented as a circuit system or a software module.

[0118] In some embodiments, the apparatus includes components for receiving a request for authorization information from a first device. This authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by a second device, and the second device is located in a second domain different from the first device's first domain. In some embodiments, the apparatus includes components for verifying the request. In some other embodiments, the apparatus includes components for sending authorization information to the first device based on determining that the request is valid and permitted.

[0119] In some embodiments, the apparatus includes components for extracting an API caller identifier from the request based on determining that the request is valid. In some embodiments, the apparatus includes components for mapping the API caller to a Management Service Access Control (MSAC) identifier. In some embodiments, the apparatus includes components for generating authorization information including the MSAC identifier. In some embodiments, the MSAC identifier is mapped to a permitted API that the API caller is authorized to invoke.

[0120] In some embodiments, the apparatus includes components for receiving joining credentials from an API caller from a first apparatus. In some embodiments, the apparatus includes components for verifying the joining credentials of the API caller.

[0121] In some embodiments, the apparatus includes components for retrieving an MSAC identifier associated with the API caller's join credentials based on determining that the API caller's join credentials are valid. In some embodiments, the apparatus includes components for sending a response to a first apparatus indicating that the join credentials are valid.

[0122] In some embodiments, the apparatus includes components for receiving an API caller identifier from a first device. In some embodiments, the apparatus further includes components for sending an acknowledgment of the API caller identifier to the first device. In some embodiments, the apparatus further includes components for associating the API caller identifier of the API caller with a retrieved MSAC identifier.

[0123] In some embodiments, the apparatus further includes components for receiving joining credentials from the first apparatus, the joining credentials including an API caller identifier. In some embodiments, the apparatus further includes components for verifying the joining credentials of the API caller.

[0124] In some example embodiments, the apparatus further includes components for retrieving an MSAC identifier associated with the API caller's join credentials based on determining that the API caller's join credentials are valid. In some embodiments, the apparatus further includes components for associating the retrieved MSAC identifier with the API caller's API caller identifier. In some embodiments, the apparatus further includes components for sending a response to a first apparatus indicating that the join credentials are valid and that the mapping to the MSAC identifier was successfully performed. The response includes the API caller's API caller identifier.

[0125] In some embodiments, the exchange of authorization-related information between the first and second devices is performed via a dedicated Common API Framework (CAPIF) reference point. In some embodiments, the first device may include CAPIF Core Functions (CCF). In some embodiments, the second device may include Authentication and Authorization Management Service (AA MnS) producer or authorization functionality.

[0126] In some embodiments, the apparatus further includes components for performing other steps in some embodiments of method 700. In some embodiments, the components include at least one processor and at least one memory, the at least one memory including computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause the apparatus to execute.

[0127] Figure 8 A simplified block diagram of a device 800 suitable for implementing some example embodiments of the present disclosure is illustrated. The device 800 can be provided to implement a communication device, for example, such as... Figure 1A The first device 110 or the second device 120 shown. As shown, the device 800 includes one or more processors 810, one or more memories 820 coupled to the processors 810, and one or more communication modules 840 coupled to the processors 810.

[0128] Communication module 840 is used for bidirectional communication. Communication module 840 has at least one antenna to facilitate communication. The communication interface can represent any interface required for communication with other network elements.

[0129] Processor 810 can be of any type suitable for a local technology network, and by way of non-limiting example, can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 800 can have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock synchronized with the main processor.

[0130] Memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), and other magnetic and / or optical storage devices. Examples of volatile memories include, but are not limited to, random access memory (RAM) 822 and other volatile memories that do not persist during power outages.

[0131] Computer program 830 includes computer-executable instructions that are executed by the associated processor 810. Program 830 may be stored in ROM 824. Processor 810 may perform any suitable actions and processes by loading program 830 into RAM 822.

[0132] The embodiments of this disclosure can be implemented via program 830, enabling device 800 to execute reference... Figure 2 Any process discussed in this disclosure. Embodiments of this disclosure may also be implemented by hardware or a combination of software and hardware.

[0133] In some example embodiments, program 830 may be tangibly contained in a computer-readable medium, which may be included in device 800 (such as memory 820) or other storage device accessible to device 800. Device 800 may load program 830 from the computer-readable medium into RAM 822 for execution. The computer-readable medium may include any type of tangible non-volatile storage medium, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0134] Figure 9 A block diagram of an example of a computer-readable medium 900 according to some exemplary embodiments of the present disclosure is illustrated. A program 830 is stored on the computer-readable medium 900. It should be noted that, although... Figure 9The computer-readable medium 900 is depicted in the form of a CD or DVD, but the computer-readable medium 900 may be any other form suitable for carrying or containing the program 830.

[0135] Generally, the various embodiments of this disclosure can be implemented using hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented using hardware, while others can be implemented using firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, apparatuses, systems, techniques, or methods described herein can be implemented using hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0136] Some exemplary embodiments of this disclosure also provide at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, which execute in a device on a target real or virtual processor to perform the functions described above. Figure 6 or Figure 7 Methods 600 or 700 are applicable. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The machine-executable instructions of a program module can execute on a local or distributed device. In a distributed device, a program module can reside on both local and remote storage media.

[0137] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0138] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0139] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination of the foregoing. More specific examples of computer-readable storage media will include electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. The term "non-transient" as used herein is a limitation on the medium itself (i.e., tangible, not signaling), not a limitation on the persistence of data storage (e.g., RAM and ROM).

[0140] Furthermore, although operations are described in a specific order, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or to perform all of the shown operations to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0141] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features or actions described above are disclosed as exemplary forms of implementing the claims.

Claims

1. A first device for communication, comprising: At least one processor; as well as At least one memory stores instructions that, when executed by the at least one processor, cause the first device to at least: Send a request for authorization information to a second device, wherein the authorization information is used by an application programming interface (API) caller to invoke the management service based on access permissions controlled by the second device, wherein the second device is located in a second domain different from the first device's first domain; as well as Receive the authorization information from the second device.

2. The first device according to claim 1, wherein the first device is further configured to: Send the API caller's joining credentials to the second device; and Receive a response from the second device indicating that the joining credential is valid.

3. The first device according to claim 2, wherein the first device is further configured to: Send the API caller's API caller identifier to the second device; and The second device receives confirmation of the API caller's identifier.

4. The first device according to claim 1, wherein the first device is further configured to: Send the API caller's joining credentials to the second device, wherein the joining credentials include the API caller's API caller identifier; and The second device receives a response indicating whether the joining credential is valid and whether the mapping to the Management Service Access Control (MSAC) identifier was successfully executed.

5. The first device according to claim 4, wherein the first device is further configured to: Based on the response received indicating that the joining credential is invalid or that the mapping to the MSAC identifier was not executed, the API caller identifier is cleared.

6. The first apparatus according to claim 4 or 5, wherein the response includes the API caller identifier of the API caller.

7. The first apparatus according to any one of claims 1 to 5, wherein the authorization information includes an MSAC identifier, the MSAC identifier being mapped to a permitted API that the API caller is authorized to invoke; or The exchange of authorization-related information between the first device and the second device is performed via a dedicated general API framework CAPIF reference point; or At least one of the following: The first device includes the CAPIF core function CCF; or The second device includes certification and authorization management services for AA MnS producers or authorization functions.

8. A second means for communication, comprising: At least one processor; as well as At least one memory stores instructions that, when executed by the at least one processor, cause the second device to perform at least the following: A request for authorization information is received from a first device, wherein the authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by the second device, wherein the second device is located in a second domain different from the first domain of the first device; Verify the request; as well as Based on the determination that the request is valid and permitted, the authorization information is sent to the first device.

9. A method for communication, comprising: Send a request for authorization information to a second device, wherein the authorization information is used by an application programming interface (API) caller to invoke the management service based on access permissions controlled by the second device, wherein the second device is located in a second domain different from the first device's first domain; as well as Receive the authorization information from the second device.

10. A method for communication, comprising: A request for authorization information is received from a first device, wherein the authorization information is used by an application programming interface (API) caller to invoke a management service based on access permissions controlled by a second device, wherein the second device is located in a second domain different from the first device's first domain; Verify the request; as well as Based on the determination that the request is valid and permitted, the authorization information is sent to the first device.

Images