Secure application programming interface access management in a communication network environment

Abstract

Security management techniques are provided for enabling inter-domain authentication functionality in a communication network environment. For example, a method includes managing, at a first entity, a request from a second entity, the first entity and the second entity being in a first domain of a communication network environment, to obtain a security object from a third entity in a second domain of the communication network environment usable to gain access to an interface of a service of a fourth entity in the second domain. In some examples, security management techniques are applicable to a common application programing interface framework (CAPIF).

Description

[0001] SECURE APPLICATION PROGRAMMING INTERFACE ACCESS MANAGEMENT IN A COMMUNICATION NETWORK ENVIRONMENT

[0002] Field

[0003] The field relates generally to communication networks, and more particularly, but not exclusively, to security management in such communication networks.

[0004] Background

[0005] This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0006] Modem communication network environments can have a wide variety of different types of networks (e.g., 5G core networks, 5G radio access networks, cloud computing networks, edge computing networks, public networks, private networks, and the like) interconnected to enable entities (e.g., users, applications, user equipment, network functions, and the like) to communicate with one another for some purpose within and / or across the different types of networks. For example, an entity may need to access a service of another entity in one of the networks, e.g., one application program may need to communicate with another application program. Typically, access to a given application program is facilitated through an application programming interface (API). Thus, an entity may first need to gain access to the API of the application program for which it seeks to utilize its corresponding service. To ensure security (e.g., communication privacy, identity verification, and the like), it is desired to have a security procedure in place for API access.

[0007] Security management is an important consideration in any communication network environment. However, due to continuing attempts to improve the architectures and protocols associated with networks in order to increase network efficiency and / or entity convenience, security management issues associated with API access in a communication network environment can present significant technical challenges.

[0008] Summary

[0009] Illustrative embodiments provide techniques for security management in a communication network environment. In one illustrative embodiment, a method includes receiving, at a first entity, a request from a second entity, the first entity and the second entity being in a first domain of a communication network environment, to obtain a security object usable to gain access to an interface of a service of a third entity in a second domain of the communication network environment. The method includes modifying, by the first entity, the request to generate a modified request, wherein modifying the request comprises changing an existing parameter in the received request from an identifier of the second entity to an identifier of the first entity, and adding an additional parameter to the received request that specifies the identifier of the second entity. The method includes sending, from the first entity, the modified request to a fourth entity in the second domain for verification. The method includes receiving, at the first entity from the fourth entity, a response with the security object upon verification of the request by the fourth entity. The method includes sending, from the first entity, the response with the security object to the second entity to enable the second entity to gain access to the interface of the service of the third entity in the second domain.

[0010] In another illustrative embodiment, a method includes receiving, at a first entity, a request from a second entity in a first domain of a communication network environment to obtain a security object on behalf of a third entity in the first domain usable by the third entity to gain access to an interface of a service of a fourth entity, wherein the first entity and the fourth entity are in a second domain of the communication network environment. The method includes verifying, by the first entity, the request. The method includes verifying, by the first entity, that the second entity is authorized to request access for the service on behalf of the third entity. The method includes, in response to successful verifications of the request and the second entity, generating, by the first entity, the security object for the third entity, wherein the security object includes an identifier of the third entity. The method includes sending, from the first entity, a response with the security object to the second entity to enable the second entity to forward the security object to the third entity.

[0011] In yet another illustrative embodiment, a method includes generating, by a first entity in a first domain of a communication network environment, a request to obtain a security object usable by the first entity to gain access to an interface of a service of a second entity in a second domain of the communication network environment. The method includes sending the request to a third entity in the first domain with a credential assertion object digitally signed by the first entity. The method includes receiving a response from the third entity with the security object upon verification of the request by a fourth entity in the second domain. The method includes sending the security object to the second entity to gain access to the interface of the service in the second domain.

[0012] Advantageously, illustrative embodiments provide security management techniques for enabling inter-domain authentication functionality in a common application programing interface framework (CAPIF).

[0013] Further illustrative embodiments are provided in the form of a non-transitory computer readable medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above and / or other steps, operations, and the like. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above and / or other steps, operations, and the like. Some illustrative embodiments comprise a system configured to perform the above and / or other steps, operations, and the like. Further, some illustrative embodiments comprise an apparatus or a system comprising means for performing the above and / or other steps, operations, and the like.

[0014] These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

[0015] Brief Description of the Drawings

[0016] FIG. 1 illustrates a communication network environment with which one or more illustrative embodiments may be implemented.

[0017] FIG. 2 illustrates an intra-domain authentication procedure for accessing an application programming interface in a communication network environment with which one or more illustrative embodiments may be implemented.

[0018] FIG. 3 illustrates an inter-domain authentication procedure for accessing an application programming interface in a communication network environment according to another illustrative embodiment.

[0019] FIG. 4 illustrates an inter-domain authentication procedure for accessing an application programming interface in a communication network environment according to another illustrative embodiment.

[0020] FIG. 5 illustrates entities with which one or more illustrative embodiments may be implemented.

[0021] Detailed Description

[0022] Embodiments will be illustrated herein in conjunction with example communication network environments and associated techniques for security management in communication network environments. It should be understood, however, that the scope of the claims is not limited to particular types of communication network environments and / or processes disclosed. Embodiments can be implemented in a wide variety of other types of systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing the 3rd Generation Partnership Project (3GPP) system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems such as 6G communication systems.

[0023] In accordance with illustrative embodiments, one or more 3 GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements / functions and / or operations that may interact with parts of the inventive solutions, e.g., TS 23.222 entitled “Technical Specification Group Services and System Aspects; Functional Architecture and Information Flows to Support Common API Framework for 3GPP Northbound APIs; Stage 2,” TS 33.122 entitled, “Technical Specification Group Services and System Aspects; Security Aspects of Common API Framework (CAPIF) for 3 GPP Northbound APIs,” TS 29.222 entitled, “Technical Specification Group Core Network and Terminals; Common API Framework for 3GPP Northbound APIs,” TR 23.700-22 entitled, “Technical Specification Group Services and System Aspects; Study on CAPIF Phase 3,” and M. Jones, et al., Internet Engineering Task Force (IETF) Request for Comments: 7519, “JSON Web Token (JWT),” the disclosures of which are incorporated by reference herein in their entireties. Note that 3GPP TS / TR documents are non-limiting examples of communication network standards (e.g., specifications, procedures, reports, requirements, recommendations, and the like). However, while well-suited for 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

[0024] FIG. 1 illustrates a communication network environment 100 with which one or more illustrative embodiments may be implemented. As shown, communication network environment 100 includes a plurality of networks 102-1, 102-2, 102-3, ...., 102-N operatively coupled to one another via one or more communication networks 104. As mentioned above, communication network environments, such as communication network environment 100, can have a wide variety of different types of networks (e.g., 5G core networks, 5G radio access networks, cloud computing networks, edge computing networks, public networks, private networks, and the like), e.g., networks 102-1, 102-2, 102-3, ...., 102-N, interconnected to enable entities (e.g., users, applications, user equipment, network functions, and the like) to communicate with one another for some purpose within and / or across the different types of networks. Each network 102-1, 102-2, 102-3, 102-N may be considered as having or representing a domain, however, in some embodiments, one or more of networks 102-1, 102- 2, 102-3, . . . 102-N may have or represent multiple domains therein. By way of example only, a domain can be a logical and / or physical grouping of one or more network services, one or more network components, one or more network functions, and / or the like, that have a common purpose or common purposes.

[0025] Accordingly, an entity may need to access a service of another entity in one of the domains of one or more of the networks 102-1, 102-2, 102-3, ...., 102-N, e.g., one application program may need to communicate with another application program. As further mentioned, access to a given application program is facilitated through an API. However, an entity may first need to gain access to the API of the application program for which it seeks to utilize its corresponding service.

[0026] In an effort to manage the many APIs that could exist across communication network environments, e.g., communication network environment 100, the 3 GPP defined a Common API Framework (CAPIF). See, e.g., the above-referenced TS 23.222, TS 33.122, and TS 29.222. More particularly, CAPIF includes logic and processes used to manage APIs exposed by 3GPP networks, e.g., networks 102-1, 102-2, 102-3, ...., 102-N, in their northbound interfaces. By way of example, a northbound interface is an API that enables a lower-level network layer or component to communicate with a higher-level network layer or component, while a southbound interface enables a higher-level network layer or component to communicate with a lower-level network layer or component.

[0027] 3GPP specifications for CAPIF define three types of entities:

[0028] (i) an API provider which is the entity exposing one or more APIs, e.g., also referred to as an API exposing function or AEF (e.g., in a 5G network, an AEF may be implemented by a network exposure function or NEF);

[0029] (ii) an API invoker which is the entity that consumes one or more APIs; and

[0030] (iii) a CAPIF core function or CCF which manages interactions between the AEFs and API invokers.

[0031] It is realized that procedures should exist for ensuring security (e.g., communication privacy, identity verification, and the like) for API access in a communication network environment that implements CAPIF functionalities. FIG. 2 illustrates an authorization procedure 200 that utilizes an access token mechanism supported by CAPIF. An access token can be more generally referred to herein as a “security object” usable to gain access to some secure service or function. See, e.g., the above-referenced TS 33.122. As shown, authorization procedure 200 involves an API invoker 202, a CAPIF core function (CCF) 204, and an API exposing function (AEF) 206. Steps 1-8 of authorization procedure 200 will now be described.

[0032] 1. CAPIF-le authentication and secure session establishment is performed as specified in the above-referenced TS 33.122.

[0033] 2. After successful establishment of a Transport Layer Security (TLS) session over CAPIF-le, as described in the above-referenced TS 33.122, the API invoker 202 sends an Access Token Request message to the CCF 204 as per the open authorization protocol OAuth 2.0 specification.

[0034] 3. The CCF 204 verifies the Access Token Request message per the OAuth 2. Ospecifi cation.

[0035] 4. If the CCF 204 successfully verifies the Access Token Request message, the CCF 204 generates an access token specific to the API invoker 202 and returns it to the API invoker 202 in an Access Token Response message.

[0036] Steps 1 to 4 of authorization procedure 200 may be skipped if the API invoker 202 is already in possession of a valid OAuth access token. In this case, the API invoker 202 begins the procedure at step 5.

[0037] The API invoker 202 may include an API invoker Identifier (ID), assigned by the CCF 204, and an Onboard Secret in the OAuth access token request message for the CCF 204 to validate the access token request.

[0038] 5. On CAPIF-2e, the API invoker 202 authenticates to the AEF 206 by establishing a TLS session with the AEF 206 based on an authentication and authorization method (e.g., Server (AEF) side certificate authentication or certificate-based mutual authentication) as indicated by the CCF 204. The following procedure is performed prior to establishment of the TLS session:

[0039] (i) The API invoker 202 sends an Authentication Initiation Request to the AEF 206, including the API invoker ID.

[0040] (ii) The AEF 206 requests security information from the CCF 204 to perform authentication and secure interface establishment with the API invoker 202. The CCF 204 provides the security information related to the chosen security method (e.g., TLS with OAuth token) to the AEF 206 over the CAPIF-3 reference point. The CCF 204 may return the root certification authority (CA) certificate of the API invoker 202 for the AEF 206 to validate.

[0041] (iii) After fetching the relevant security information for the authentication, the AEF 206 sends an Authentication Initiation Response message to the API invoker 202 to initiate the TLS session establishment procedure.

[0042] 6. With successful authentication to the AEF 206 on CAPIF-2e, the API invoker 202 initiates invocation of a 3GPP northbound API with the AEF 206. The access token received from the CCF 204 is sent along with the northbound API invocation request as per the OAuth 2.0 specification.

[0043] 7. The AEF 206 validates the access token. The AEF 206 verifies the integrity of the access token by verifying the signature of the CCF 204. If validation of the access token is successful, the AEF 206 verifies the Northbound API invocation request for the API invoker 202 against the authorization claims in the access token, ensuring that the API Invoker 202 has access permission for the requested service API.

[0044] 8. After successful verification of the access token and authorization claims of the API invoker 202, the requested northbound API is invoked and the appropriate response is returned to the API invoker 202.

[0045] However, it is realized that a procedure to obtain an access token by an API invoker in case of CAPIF interconnection (e.g., CAPIF-6 / 6e) is not necessarily defined by authorization procedure 200. CAPIF interconnection can be defined, by way of example, as a use case when the AEF is in a different domain than the API invoker. Recall in FIG. 1 that each network 102- 1, 102-2, 102-3, . . . ., 102-N may be considered to have or represent a domain, however, in some embodiments, one or more of networks 102-1, 102-2, 102-3, . . . ., 102-N may have or represent multiple domains therein.

[0046] FIG. 3 illustrates an authorization procedure 300 for a CAPIF interconnection use case according to an illustrative embodiment. As shown, authorization procedure 300 involves an API invoker 302, a CAPIF core function in a domain B (CCF-B) 304, and a CAPIF core function in a domain A (CCF-A) 306. It is assumed that an AEF (not expressly shown) with which the API invoker 302 seeks to interact is in a different domain (e.g., a domain associated with CCF-A 306) than the domain of the API invoker 302 (e.g., CCF-B 304). Steps 1-3 of authorization procedure 300 include the following: 1. The API invoker 302 sends a request to obtain service API access authorization to the CCF-B 304.

[0047] 2. The CCF-B 304 obtains the service API access authorization from the CCF-A 306.

[0048] 3. The CCF-B 304 sends a service API access authorization response to the API invoker 302.

[0049] Thus, in the CAP IF interconnection use case depicted in FIG. 3, the API invoker 302 and the CCF-B 304 are assumed to belong to one domain, while the AEF (not expressly shown) and the CCF-A 306 belong to another domain. Additionally, the CCF-A 306 and the CCF-B 304 are connected to each other, and are assumed to have an agreement for service API authorization. The CCF-A 306 is the authorization function for service API access on the AEF.

[0050] In some embodiments, API invoker 302 can optionally send a client credentials assertion (CCA) token, generated using its private key during onboarding to the CCF-B 304 while sending the access token request to the CCF-B 304 which will be further forwarded to the CCF-A 306 along with the API invoker 302 certificate for the CCF-A 306 to ensure that the request is initiated by the API invoker 302.

[0051] CCA is a concept introduced in 5G for authentication of the service consumer in service-based interface (SBI) service or subscription requests. The assumption is that crossdomain certification is enabled which allows the CCF-A 306 to verify the signature of the requesting API invoker 302 onboarded in the CCF-B 304.

[0052] After validating the access token request received from the API invoker 302, the CCF- B 304 proceeds to perform the following steps before forwarding the access token request towards the CCF-A 306:

[0053] (i) Remove the Onboard Secret received from the API invoker 302 to prevent any potential leakage of the secret outside the domain;

[0054] (ii) Replace the client id in the access token request with the CCF-B 304 identifier to prevent validation failure at the CCF-A 306 when verifying the client id with that of the client details received during the mutual TLS procedure with the CCF-B 304.

[0055] (iii) Include a new parameter referred to as sourceAPIInvokerlD, which is set with the identity of the API invoker 302 (APIInvokerlD) in the Access Token Request towards the CCF- A 306. This parameter helps the CCF-A 306 to identify the API invoker 302 for authorization purposes. The CCF-A 306 information is known to the CCF-B 304 via an Interconnection API Publish Request as described in the above-referenced TS 23.222; and

[0056] (iv) Reuse all remaining parameters. If the CCA token is received, the CCF-B 304 will retrieve the certificate for the API invoker 302 stored locally and forward the same to the CCF-A 306.

[0057] The CCF-A 306, after receiving the Access Token Request and CCA token (optional), verifies the Access Token Request message as per the OAuth 2.0 specification. Assuming cross-domain certification, the CCF-A 306 verifies the CCA token if available using the API invoker certificate to ensure that the request is originated from the API invoker 302 set in the request and to authenticate the API invoker 302, and generates an access token response specific to the API invoker 302, as follows:

[0058] (i) The Access Token Claims in the access token response includes the client id as APIInvokerlD (same as sourceAPIInvokerlD received in the request). This ensures that when the API invoker 302 presents the access token to the AEF (not expressly shown) during the service request, the AEF can validate the API invoker 302 before providing the service (the APIInvokerlD details present in the TLS certificate should match with APIInvokerlD used in the access token).

[0059] The CCF-A 306 sends the access token response to the CCF-B 304, which further sends the access token response to the API invoker 302.

[0060] The API invoker 302 uses the access token to get the service from the AEF and the AEF verifies the token of CCF-A 306 (containing new field sourceAPIInvokerlD) before providing the service. As per the OAuth 2.0 specification, the client id should refer to the TLS client who initiated the TLS connection. When the API invoker 302 initiated the TLS connection towards the CCF-B 304 for sending access token request, the client id is the ID of the API invoker 302. But when the CCF-B 304 establishes a TLS connection for sending the access token request to the CCF-A 306, the client id is the ID of the CCF-B 304. In this case, for the AEF in the domain of the CCF-A 306 to know the source APIInvokerlD which actually initiated the connection, the CCF-B 304 adds the sourceAPIInvokerlD in the request.

[0061] In a resource owner-aware northbound API access (RNAA) case (e.g., see the functional model description to support RNAA in the above-referenced 3.222), if resource owner (RO) consent is required for utilizing a service, a user consent procedure can be used. In some embodiments, where the API invoker resides on user equipment (UE - e.g., 5G network or otherwise), the RO can be an owner of the UE.

[0062] More particularly, FIG. 4 illustrates an authorization procedure 400 which is a more detailed representation of the authorization procedure 300 with the above-described functionalities. As shown, authorization procedure 400 involves a first domain (domain B) 410 with which an API invoker 412 and a CCF in a domain B (CCF-B) 414 are associated, and a second domain (domain A) 420 with which a CCF in a domain A (CCF- A) 422, a RO 424, and an AEF 426 are associated. Steps 1-14 of authorization procedure 400 include the following:

[0063] 1. CAPIF-le authentication and secure session establishment is performed between the API invoker 412 and the CCF-B 414. In some embodiments, the API invoker 412 can reside on 5G or other UE, while in other embodiments, the API invoker 412 can reside outside the UE (e.g., reside on an application function or AF).

[0064] 2. After successful establishment of a TLS session over CAPIF-le, the API invoker 412 sends an Access Token Request message and optionally a CCA token (signed using its private key) to the CCF-B 414 as per the OAuth 2.0 specification.

[0065] Note that the API invoker 412 may include the CAPIF core function assigned API invoker ID and the Onboard Secret in the OAuth access token request message for the CAPIF core function to validate the access token request.

[0066] Note also that, in some embodiments, the CCA token is compliant with the abovereferenced Json Web Token IETC RFC 7519 and includes the APIInvokerlD, CCF ID, timestamp (iat), and the expiry time (exp). The lifetime of the CCA token is expected to be smaller than the expiry time associated with the O-auth access token. The CCA token when received at the CCF-A 422 ensures the request is originated by the API invoker 412.

[0067] 3. The CCF-B 414 verifies the Access Token Request message per the OAuth 2.0 specification. In FIG. 4, RO (resource owner ) 424 is shown as part of the second domain 420 of the CCF-A 422. Instead, if RO 424 is part of the first domain 410 of the CCF-B 414, then the CCF-B 414 may trigger a consent capture at this point using RNAA (and consent is the applicable legal basis).

[0068] 4. After the CCF-B 414 successfully verifies the Access Token Request message from the API invoker 412, the CCF-B 414 creates a new Access Token request using the Access Token Request it received from the API invoker 412.

[0069] The CCF-B 414 creates a new Access Token Request with:

[0070] (i) Onboard Secret received in step 2 removed, and the remaining parameters in step 2 are reused;

[0071] (ii) A new parameter “source APIInvokerlD” is added and is set to the value of client id received in step2 (APIinvokerlD);

[0072] (iii) client id is set to the CCF-B 414 identifier; (iv) If RO 424 is part of the first domain 410 of CCF-B 414 (which it is not in the FIG. 4 embodiment) and consent was retrieved, then the CCF-B 414 may also include the consent information;

[0073] (v) If RO 424 is part of the second domain 420 of the CCF-A 422 (as shown in the FIG. 4 embodiment), and consent needs to be captured, then the CCF-B 414 includes information about the identity of API invoker 412 (e.g., sourceAPIInvokerlD) as well as consent-specific parameters (e.g., purpose of the data processing, etc.), so the RO 424 can identify the party requesting access to the protected resources and the reason for that request; and

[0074] (vi) The certificate of the API invoker 412 is retrieved locally as one or more additional information elements (IES).

[0075] 5. The CCF-B 414 sends the updated / new OAuth token request to the CCF-A 422 along with the CCA token provided by the API invoker 412 and the API invoker 412 certificate retrieved locally in the API invoker 412 profile.

[0076] 6. The CCF-A 422 verifies the Access Token Request as per the OAuth 2.0 specification.

[0077] 7. The CCF-A 422 then:

[0078] (i) Verifies if the CCF-B 414 is authorized for the service;

[0079] (ii) Validates the CCA token with the received API invoker 412 certificate;

[0080] (iii) Validates that the sourceAPIInvokerlD and the CCF-B 414 ID in the CCA token are matching with the Access Token Request received;

[0081] (iv) Verifies that the CCA token verification ensures the Access Token Request is originated from API invoker 412 and also to authenticate the API invoker at the CCF- A 422;

[0082] (v) Verifies that the API invoker 412 is authorized for the service; and

[0083] (vi) If the RO 424 is part of the CCF-A 422 domain, verifies that consent is applicable, and obtains the consent from the RO 424 using RNAA.

[0084] 8. After successful validation, the CCF-A 422 generates the access token response with a token including client id in AccessTokenClaims set to sourceAPIInvokerlD present in step 4.

[0085] 9. The CCF-A 422 sends the access token response to the CCF-B 414.

[0086] 10. The CCF-B 414 forwards the access token response to the API invoker 412.

[0087] 11-12. With successful authentication to the AEF 426 on CAPIF-2e, the API invoker 412 initiates invocation of a 3GPP northbound API with the AEF 426. The access token received from the CCF-B 414 is sent along with the northbound API invocation request.

[0088] 13. The AEF 426 validates the access token. The AEF 426 verifies the integrity of the access token by verifying the CCF-B 414 signature. If validation of the access token is successful, the AEF 426 verifies the northbound API invocation request of the API invoker 412 against the authorization claims in the access token, ensuring that the API invoker 412 has access permission for the requested service API.

[0089] 14. After successful verification of the access token and authorization claims of the API invoker 412, the requested northbound API is invoked and the appropriate response is returned to the API invoker 412.

[0090] FIG. 5 is a block diagram illustrating computing architectures for various participants in methodologies according to illustrative embodiments. More particularly, system 500 is shown comprising entities 502-1, . . . . , 502-N. For example, in illustrative embodiments and with reference back to FIG. 4, entities 502-1, . . . . , 502-N can respectively the API invoker 412, the CCF-B 414, the CCF-A 422, the RO 424, and the AEF 426. It is to be appreciated that the entities 502-1, . . . . , 502-N are configured to interact to provide security management and other techniques described herein.

[0091] Each of the entities 502-1, . . . . , 502-N (individually or collectively referred to herein as 502) comprises a processor 522 (522-1, . . . , 522-N) coupled to a memory 526 (526-1, . . . , 526-N) and interface circuitry 520 (520-1, . . . , 520-N). Each processor 522 of each entity 502 includes a security management processing module 524 (524-1, . . . , 524-N) that may be implemented at least in part in the form of software executed by the processor 522. The security management processing module 524 performs security management operations described in conjunction with subsequent figures and otherwise herein. Each memory 526 of each entity 502 includes a security management storage module 528 (528-1, . . . , 528-N) that stores data generated or otherwise used during security management operations.

[0092] The processors 522 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

[0093] The memories 526 may be used to store one or more software programs that are executed by the respective processors 522 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 522.

[0094] A given one of the memories 526 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a computer or processor readable (non-transitory or storage) medium that has executable program code embodied therein. Other examples of computer or processor readable media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other computer or processor readable media.

[0095] Further, the memories 526 may more particularly comprise, for example, electronic random-access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, nonvolatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC- RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

[0096] The interface circuitries 520 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

[0097] It is apparent from FIG. 5 that the plurality of entities 502 are configured for communication with each other as security management participants via their respective interface circuitries 520. This communication involves each participant sending data to and / or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, security management messages, registration request / response messages and data, request / response messages, authorization and / or authentication request / response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

[0098] It is to be appreciated that the particular arrangement of components shown in FIG. 5 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given entity 502 can be configured to incorporate additional or alternative components and to support other communication protocols.

[0099] Also, entities such as third-party applications and network operators can participate in methodologies described herein via computing devices configured to include components such as a processor, memory and network interface. These elements and devices need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

[0100] More generally, FIG. 5 can be considered to represent processing devices configured to provide respective security management functionalities and operatively coupled to one another in a communication network environment. By way of example only, all or parts of each of the plurality of entities 502 (e.g., processor and memory) can be considered examples of means for performing one or more operations, one or more steps, one or more functions, one or more processes, etc. as described herein.

[0101] It is to be appreciated that the particular processing operations and other system functionality described in conjunction with the diagrams described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another.

[0102] It should again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, authorization processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

CLAIMS1. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive a request from a first entity in a first domain of a communication network environment to obtain a security object usable to gain access to an interface of a service in a second domain of the communication network environment, wherein the apparatus is in the first domain with the first entity; modify the request to generate a modified request, wherein modifying the request comprises changing an existing parameter in the received request from an identifier of the first entity to an identifier of the apparatus, and adding an additional parameter to the received request that specifies the identifier of the first entity; send the modified request to a second entity in the second domain for verification; receive a response with the security obj ect upon verification of the request by the second entity; and send the response with the security object to the first entity to enable the first entity to gain access to the interface of the service in the second domain.

2. The apparatus of claim 1, wherein modifying the request further comprises removing a secret value associated with the first entity from the request.

3. The apparatus of claim 1, wherein when the received request includes a credential assertion object digitally signed by the first entity, the apparatus is further caused to send the credential assertion object to the second entity with the modified request.

4. The apparatus of claim 3, wherein when the received request includes the credential assertion object digitally signed by the first entity, the apparatus is further caused to: obtain a certificate associated with the first entity from a certification authority; and send the certificate to the second entity along with credential assertion object to enable the second entity to verify that the first entity initiated the request.

5. The apparatus of claim 1, wherein the security object comprises an access token.

6. The apparatus of claim 1, wherein the security object is configured in accordance with an open authentication protocol.

7. The apparatus of claim 1, wherein the apparatus is configured to operate in accordance with a common application programing interface framework (CAPIF) to provide inter-domain connection functionality in conjunction with the second entity.

8. A method comprising: receiving, at a first entity, a request from a second entity, the first entity and the second entity being in a first domain of a communication network environment, to obtain a security object usable to gain access to an interface of a service of a third entity in a second domain of the communication network environment; modifying, by the first entity, the request to generate a modified request, wherein modifying the request comprises changing an existing parameter in the received request from an identifier of the second entity to an identifier of the first entity, and adding an additional parameter to the received request that specifies the identifier of the second entity; sending, from the first entity, the modified request to a fourth entity in the second domain for verification; receiving, at the first entity from the fourth entity, a response with the security object upon verification of the request by the fourth entity; and sending, from the first entity, the response with the security object to the second entity to enable the second entity to gain access to the interface of the service of the third entity in the second domain.

9. The method of claim 8, wherein the security object comprises an access token.

10. The method of claim 8, wherein the security object is configured in accordance with an open authentication protocol.1711. The method of claim 8, wherein the first entity is configured to operate in accordance with a common application programing interface framework (CAPIF) to provide inter-domain connection functionality in conjunction with the fourth entity.

12. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive a request from a first entity in a first domain of a communication network environment to obtain a security object on behalf of a second entity in the first domain usable by the second entity to gain access to an interface of a service in a second domain of the communication network environment; verify the request; verify that the first entity is authorized to request access for the service on behalf of the second entity; in response to successful verifications of the request and the first entity, generate the security object for the second entity, wherein the security object includes an identifier of the second entity; and send a response with the security object to the first entity to enable the first entity to forward the security object to the second entity.

13. The apparatus of claim 12, wherein when the request includes a credential assertion object digitally signed by the second entity and a certificate associated with the second entity from a certification authority, the apparatus is further caused to use the credential assertion object and the certificate to verify the request.

14. The apparatus of claim 12, wherein the security object comprises an access token.

15. The apparatus of claim 12, wherein the security object is configured in accordance with an open authentication protocol.1816. The apparatus of claim 12, wherein the apparatus is configured to operate in accordance with a common application programing interface framework (CAPIF) to provide inter-domain connection functionality in conjunction with the first entity.

17. The apparatus of claim 12, wherein the apparatus is further caused to obtain consent from an owner associated with the second entity.

18. A method comprising: receiving, at a first entity, a request from a second entity in a first domain of a communication network environment to obtain a security object on behalf of a third entity in the first domain usable by the third entity to gain access to an interface of a service of a fourth entity, wherein the first entity and the fourth entity are in a second domain of the communication network environment; verifying, by the first entity, the request; verifying, by the first entity, that the second entity is authorized to request access for the service on behalf of the third entity; in response to successful verifications of the request and the second entity, generating, by the first entity, the security object for the third entity, wherein the security object includes an identifier of the third entity; and sending, from the first entity, a response with the security object to the second entity to enable the second entity to forward the security object to the third entity.

19. The method of claim 18, wherein when the request includes a credential assertion object digitally signed by the third entity and a certificate associated with the third entity from a certification authority, the first entity uses the credential assertion object and the certificate to verify the request.

20. The method of claim 18, wherein the security object comprises an access token.

21. The method of claim 18, wherein the security object is configured in accordance with an open authentication protocol.1922. The method of claim 18, wherein the first entity is configured to operate in accordance with a common application programing interface framework (CAPIF) to provide inter-domain connection functionality in conjunction with the second entity.

23. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: generate a request to obtain a security object usable by the apparatus to gain access to an interface of a service of a first entity in a first domain of a communication network environment, wherein the apparatus is in a second domain of the communication network environment; send the request to a second entity in the second domain with a credential assertion object digitally signed by the apparatus; receive a response from the second entity with the security object upon verification of the request by a third entity in the first domain; and send the security object to the first entity to gain access to the interface of the service in the first domain.

24. The apparatus of claim 23, wherein the apparatus is part of user equipment.

25. The apparatus of claim 23, wherein the apparatus is part of an application function.

26. The apparatus of claim 23, wherein the apparatus is configured to operate in accordance with a common application programing interface framework (CAPIF) in an interdomain connection use case.

Images