WO2012129934A1 - 一种实现cdn互通的认证方法、装置与系统 - Google Patents

一种实现cdn互通的认证方法、装置与系统 Download PDF

Info

Publication number
WO2012129934A1
WO2012129934A1 PCT/CN2011/083908 CN2011083908W WO2012129934A1 WO 2012129934 A1 WO2012129934 A1 WO 2012129934A1 CN 2011083908 W CN2011083908 W CN 2011083908W WO 2012129934 A1 WO2012129934 A1 WO 2012129934A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
cdn1
cdn2
token
parameter
Prior art date
Application number
PCT/CN2011/083908
Other languages
English (en)
French (fr)
Inventor
李金成
和晓艳
钟剑锋
曹力争
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2012129934A1 publication Critical patent/WO2012129934A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to an authentication method, apparatus, and system for implementing CDN (Content Dilivery Network) interworking.
  • CDN Content Dilivery Network
  • FIG. 1 shows the use of C-S (Client-Server) mode by Content Provider (CP) / Service Provider (Service Provider,
  • CP Content Provider
  • Service Provider Service Provider
  • the content source server provides a schematic diagram of the content service for the terminal.
  • the deployment model shown in Figure 1 exposes some issues.
  • these servers are often deployed at a higher level of the network (such as the backbone layer, the aggregation layer, and so on) to achieve a larger coverage.
  • the bandwidth of the backbone and aggregation layer is occupied.
  • Network bandwidth is putting a lot of pressure.
  • the user experience is not ideal.
  • the CDN service provider provides services to users by deploying a large number of edge cache nodes on the edge of the network to save network bandwidth and improve user service experience.
  • telecom operators have begun to deploy CDN systems themselves, on the one hand to accelerate their own business, and at the same time can be provided to other content providers.
  • the emergence of the CDN system allows content providers to deploy a small number of content source servers to complete service provisioning. At the same time, when the number of users grows, the CDN system handles traffic, and content providers do not need to expand the network. Use the CDN system to provide end users with internal The network model of the service is shown in Figure 2.
  • CDN operators and telecom operators choose to deploy CDN systems in different regions according to their business development plans.
  • the coverage of CDN systems varies from manufacturer to manufacturer, and there may be overlaps in coverage areas.
  • the CDN system has not been standardized.
  • the CDN systems of various manufacturers are self-contained and operate independently of each other. There is no cooperation, which makes the capabilities of each CDN system unable to complement each other.
  • the first content distribution network CDN1 covers Beijing and Shanghai; the second content distribution network CDN2 covers Xi'an and Shenzhen.
  • a content provider CP wants its users to be accessible to users in Beijing, Shanghai, Xi'an, and Shenzhen, neither CDN1 nor CDN2 can meet the requirements of the content provider separately, and thus between CDNs is required. Interoperability. Since CP is contracted with CDN1, CDN1 and CDN2 are contracted, and CP is not contracted with CDN2, CDN2 cannot perform security authentication for CP. Summary of the invention
  • an embodiment of the present invention provides an authentication method, apparatus, and system for implementing CDN interworking.
  • CDN1 is contracted with CDN2
  • CDN2 is implemented to the CP. Certification.
  • an embodiment of the present invention provides an authentication method for implementing CDN interworking, the method comprising: receiving, by a second content distribution network CDN2, a service request from a first content distribution network CDN1 or a terminal; the CDN2 acquiring by a content provider An authentication parameter and a token provided by the CP, the CP is contracted with the CDN1, the CDN1 is contracted with the CDN2, and the CP is not contracted with the CDN2; the CDN2 is based on the authentication parameter and the token pair The CP performs authentication; the CDN2 returns a service response to the CDN1 or the terminal according to the authentication result.
  • the embodiment of the present invention provides an authentication device for implementing CDN interworking, the device is located in the second content distribution network CDN2, and the device includes: a receiving unit, configured to receive the CDN1 or the terminal from the first content distribution network. a service request; an obtaining unit, configured to acquire an authentication parameter and a token provided by a content provider CP; the CP signing with the CDN1, The CDN1 is contracted with the CDN2, and the CP is not contracted with the CDN2; an authentication unit is configured to authenticate the CP according to the authentication parameter and the token acquired by the acquiring unit; The authentication result of the authentication unit returns a service response to the CDN1 or the terminal.
  • an embodiment of the present invention provides an authentication system for implementing CDN interworking, where the system includes: a security function device SF2 located in the second content distribution network CDN2 and a security function device SF1 located in the first content distribution network CDN1; Said SF2, for receiving a service request from the SF1 or the terminal; acquiring an authentication parameter and a token provided by the content provider CP, the CP signing with the CDN1, the CDN1 signing with the CDN2, The CP does not sign the CDN2; the CP is authenticated according to the authentication parameter and the token; and the service response is returned to the SF1 or the terminal according to the authentication result.
  • the method, the device and the system of the embodiment of the present invention when the CP is contracted with the CDN1, the CDN1 is contracted with the CDN2, and the CP is not contracted with the CDN2, the authentication parameter and the token of the CP are obtained by the CDN2, and the acquired authentication parameters and tokens are obtained.
  • the CP is authenticated to ensure the security of the interworking between CDN1 and CDN2, so that CDN2 only serves the CP that is contracted with CDN1.
  • FIG. 1 is a schematic diagram of a prior art providing a content service by a content source server of a CP/SP in a C-S mode;
  • FIG. 2 is a network model diagram of a prior art using a CDN system to provide content services to end users;
  • FIG. 3 is a functional architecture diagram of a CDN system according to an embodiment of the present invention.
  • 4a is a flowchart of an authentication method for implementing CDN interworking according to an embodiment of the present invention
  • 4b is a functional block diagram of an apparatus for implementing CDN interworking according to an embodiment of the present invention.
  • FIG. 4c is a schematic diagram of a connection relationship of an authentication system for implementing CDN interworking according to an embodiment of the present invention
  • FIG. 5 is a flowchart of an authentication process of a CDN2 to a CP according to an embodiment of the present invention
  • 6 is a second flowchart of CDN2 authentication to a CP according to an embodiment of the present invention
  • FIG. 7 is a third flowchart of the authentication of the CDN2 to the CP according to the embodiment of the present invention.
  • FIG. 9 is a fifth flowchart of a CDN2 authentication process for a CP according to an embodiment of the present invention.
  • FIG. 10 is a sixth flowchart of the authentication of the CDN2 to the CP according to the embodiment of the present invention. detailed description
  • the embodiment of the invention provides an authentication method, device and system for implementing CDN interworking.
  • CDN interworking can promote complementary capabilities between CDN systems, such as the expansion of coverage capabilities, and load sharing when CDN system traffic increases.
  • Security is one of the key issues in CDN interoperability.
  • CDN2 and CDN1 are interoperable, it must be ensured that CDN2 only serves CDN1 with which it has an interworking relationship.
  • the technical solution of the embodiment of the present invention can solve the security problem when the CDN is intercommunicated, and promote interworking between different CDN systems.
  • the functional architecture of the CDN system in the embodiment of the present invention is as shown in FIG. 3.
  • CP/SP can deploy content sources on its own or choose to store content in third-party storage systems.
  • Content stored in the content source can be injected into the CDN system through the content injection process (more specifically, injected into the content storage entity, or content delivery entity).
  • the CDN system can also actively request content from content sources when necessary.
  • the storage control selects the appropriate content store to retrieve the content from the content source; and selects the appropriate content delivery to obtain the content from the specified content store.
  • the storage control functions include: Understanding the load status of the content storage, such as CPU usage, memory usage, and input and output bandwidth; understanding the content storage capability information, such as supported content injection protocols (such as HTTP, FTP), content distribution Protocol (HTTP, FTP), etc.; responsible for routing of content requests, such as content injection requests, content distribution requests, etc. (3) Delivery Control: Delivery Controller
  • Delivery Control Selects the content delivery entity to deliver media content to the terminal.
  • the functions of the delivery control entity include: Understanding the load status of content delivery, such as CPU usage, memory usage, input and output bandwidth; understanding of content delivery capabilities, such as supported content injection protocols (eg HTTP, FTP), content Delivery protocols (such as RTSP, HTTP, SilverLight, Flash), etc.; responsible for routing of content-related requests, such as content injection, content distribution.
  • Understanding the load status of content delivery such as CPU usage, memory usage, input and output bandwidth
  • understanding of content delivery capabilities such as supported content injection protocols (eg HTTP, FTP), content Delivery protocols (such as RTSP, HTTP, SilverLight, Flash), etc.
  • content injection protocols eg HTTP, FTP
  • content Delivery protocols such as RTSP, HTTP, SilverLight, Flash
  • the storage control and delivery control are collectively referred to as content routing.
  • content routing is not specifically divided into storage control and delivery control, and only the content routing entity is used to describe the related embodiments.
  • the security function is a logical functional entity, which may be located in the control layer or the resource layer. It can be set up independently or integrated into a content routing or content delivery entity.
  • the functions of the SF include: management of CP security information (such as shared key, authentication method, etc.); delivery of CP security information, such as SF1 of CDN1 to deliver CP security information to SF2 of CDN2; completion of authentication of CP, or Authentication for a CP-specific portal; Optionally, it also includes authentication between CDNs, such as CDN2 authentication CDN1 is a contracted CDN.
  • CP security information such as shared key, authentication method, etc.
  • delivery of CP security information such as SF1 of CDN1 to deliver CP security information to SF2 of CDN2
  • completion of authentication of CP or Authentication for a CP-specific portal
  • it also includes authentication between CDNs, such as CDN2 authentication CDN1 is a contracted CDN.
  • the CSG obtains and stores the original content from the content source and distributes it to the content delivery entity.
  • the CSG can also pre-process the content, such as content fragmentation and transcoding.
  • the CD obtains content from the content storage and distributes it to the terminal; optionally, the CD can also perform content rate conversion, file format conversion, fragmentation, and the like on the content.
  • the embodiment of the present invention is described by taking two CDN interworkings as an example.
  • a typical scenario applicable to the solution is shown in FIG. 4: It is assumed that CDN1 covers area 1, and CDN2 covers area 2.
  • CP hopes to provide services for users in Area 1 and Area 2, CP only contracts with CDN1, and CDN1 and CDN2 sign up.
  • the CP only contracts with CDN1, so the content is considered to be injected into the content storage entity of CDN1.
  • the content delivery request first arrives at the content route of CDN1.
  • CDN system interoperability involves the following business processes: content distribution process, content delivery process.
  • CDN2 obtains content from CDN1, including CDN1 to push content to CDN2, or CDN2 requests content from CDN1.
  • CDN2 requests content from CDN1.
  • the terminal obtains media content from CDN2.
  • Embodiment 1 describes the complete process of CDN security interworking
  • Embodiment 2 describes the security interworking process of the content distribution process
  • Embodiment 3-6 describes the security interworking process of the content delivery process
  • Embodiment 7 applies to the content distribution and content delivery process. .
  • FIG. 4a is a flowchart of the method in the embodiment. As shown in FIG. 4a, the method includes:
  • the CDN2 receives a service request from the CDN1 or the terminal.
  • CDN2 acquires an authentication parameter and a token provided by the CP, the CP is contracted with the CDN1, the CDN1 is contracted with the CDN2, and the CP is not contracted with the CDN2;
  • the CDN2 authenticates the CP according to the authentication parameter and the token.
  • the CDN2 returns a service response to the CDN1 or the terminal according to the authentication result.
  • the S402 specifically includes: the CDN2 obtains the authentication parameter and the token provided by the CP from the service request; or the CDN2 obtains the authentication parameter provided by the CP from the service request, and obtains the authentication parameter obtained by the CP.
  • the token provided by the CP further includes: CDN2 receiving the security information sent by the CDN1, where the security information includes at least a shared key of the CP and the CDN1; correspondingly, the S403 specifically includes: the CDN2 according to the authentication parameter and the shared secret The key generates a token, and compares whether the generated token is consistent with the obtained token. If they are consistent, the authentication passes.
  • the S403 specifically includes:
  • the CDN 2 provides the authentication parameter and token to the CDN1, which authenticates the CP according to the shared key of the CP and CDN1, the authentication parameter and the token; and receives the authentication result returned by the CDN1.
  • the method further includes: converting the protocol and/or the message format between the CDN1 and the CDN2 through the security gateway.
  • the execution body of the method is: a security function device in the CDN2.
  • FIG. 4b is a functional block diagram of the device, as shown in FIG. 4b, 40 includes: a receiving unit 401, configured to receive a service request from the CDN1 or the terminal; an obtaining unit 402, configured to acquire an authentication parameter and a token provided by the CP, where the CP is contracted with the CDN1, the CDN1 and the CDN1 The CDN2 is contracted, and the CP is not contracted with the CDN2; the authentication unit 403 is configured to authenticate the CP according to the authentication parameter and the token acquired by the acquiring unit, and the sending unit 404 is configured to use the authentication unit according to the authentication unit.
  • the result of the authentication returns a business response to CDN1 or the terminal.
  • the obtaining unit 402 is specifically configured to obtain an authentication parameter and a token provided by the CP from the service request, or obtain an authentication parameter provided by the CP from the service request, and pass the The authentication process obtains the token provided by the CP.
  • the receiving unit 401 is further configured to receive the security information that is sent by the CDN1, where the security information includes at least a shared key of the CP and the CDN1.
  • the authentication parameter obtained by the unit and the shared key generation token are compared, and the generated token is compared with the obtained token. If they are consistent, the authentication is passed.
  • the authentication unit 403 is specifically configured to provide the authentication parameter and the token to the CDN1, according to the shared key of the CD and the CDN1 by the CDN1.
  • the authentication parameter and the token authenticate the CP; and receive the authentication result returned by the CDN1.
  • the embodiment further provides an authentication system for implementing CDN interworking, and the system is applied to the scenario shown in FIG. 4;
  • FIG. 4c is a schematic diagram of the system connection relationship of the embodiment.
  • the system of this embodiment includes: a security function device SF2 located at CDN2 and a security function device SF1 located at CDN1; the SF2, for receiving a service request from the SF1 or the terminal; acquiring the authentication provided by the CP a parameter and a token, the CP is contracted with the CDN1, the CDN1 is contracted with the CDN2, the CP is not contracted with the CDN2; the CP is authenticated according to the authentication parameter and the token; As a result, a service response is returned to SF1 or the terminal.
  • the SF2 is specifically configured to obtain an authentication parameter and a token provided by the CP from the service request, or obtain an authentication parameter provided by the CP from the service request, and pass the authentication process with the CP. Get the token provided by the CP.
  • the SF2 is further configured to receive security information sent by the CDN1, where the security information includes at least a shared key of the CP and the CDN1; and the token is generated according to the authentication parameter and the shared key, and the generated token is compared. Whether the token is consistent with the obtained token. If they are consistent, the authentication is passed.
  • the SF2 is further configured to provide the authentication parameter and the token to the SF1, and the SF1 authenticates the CP according to the shared key of the CP and the CDN1, the authentication parameter and the token; and receives The result of the authentication returned by SF1.
  • the system further includes: a security gateway (not shown) located between SF1 and SF2; and the security gateway is configured to implement protocol and/or message format conversion between CDN1 and CDN2.
  • a security gateway located between SF1 and SF2; and the security gateway is configured to implement protocol and/or message format conversion between CDN1 and CDN2.
  • safety function device SF1 sends safety information to the safety function device SF2.
  • the specific content of the security information depends on the security information shared by the CP and CDN1, including the authentication method, the shared key between the CP and CDN1, and the authentication scheme.
  • CDN1 and CDN2 may have multiple subscriptions, for example, different CPs have different subscriptions, or multiple different subscriptions under the same CP.
  • the CDN logo and the subscription identifier are generally used to identify these subscriptions, and thus the CDN identification (CDN ID) and the subscription ID (Profile ID) may be issued simultaneously with the security information.
  • CDN2 can uniquely identify a specific contract for a particular CDN through the CDN logo and subscription logo.
  • symmetric key authentication There are two types of authentication methods: symmetric key authentication and asymmetric key authentication.
  • symmetric key authentication the key in the security information is the shared key of CP and CDN1.
  • asymmetric key (public key) authentication method is used, the key in the security information is the public key of the CP.
  • This embodiment uses a shared key as an example for description.
  • the authentication scheme corresponds to different digest algorithms, such as MD5 (message digest 5), SHA1 (secure hash algorithm 1), or other digest algorithms.
  • MD5 messages digest 5
  • SHA1 secure hash algorithm 1
  • the embodiment of the present invention can use the security information as part of the subscription information, and the contract information stores the service agreement of the contracting parties and the necessary sharing information, which is the basis of the service.
  • Examples of subscription information in the embodiments of the present invention are as follows: CDN identification, subscription identification, security information (authentication mode, key, authentication scheme), and other subscription information.
  • the contract information and the security information of the embodiment of the present invention may also adopt other organization manners, and these organization manners do not affect the implementation of the scheme. 5501.
  • the content routing device CR1 sends a service request to SF1.
  • the URL of the service request message is as follows:
  • the service request message may also carry other service-specific parameters through the URL, the HTTP message header field or the message body, which is not limited by the embodiment of the present invention.
  • the SF1 sends a service request to the SF2, where the authentication parameter is carried.
  • the step can specifically include:
  • SF1 After receiving the service request message, SF1 performs the subsequent process if it determines that the request is from the contracted CP, otherwise rejects the request;
  • SF1 further determines whether the request message has carried the token
  • SF1 can execute: sub-step 1) directly forward the service request to SF2; or sub-step 2) add new authentication parameters, such as CDN ID and/or profile ID, recalculate the token, and then Send the modified service request to SF2.
  • new authentication parameters such as CDN ID and/or profile ID
  • the authentication parameters in this embodiment include: request URIJ domain name, CDN identifier, subscription identifier, authentication method, and authentication scheme. Among them, the signing logo, the authentication method, and the authentication scheme are optional.
  • the service request message URL is as follows, where TOKEN is a token:
  • the manner in which the above information is carried is not limited.
  • the authentication parameters can also be used as an order. Part of the card.
  • the message header field can be used to carry the token.
  • SF2 authenticates the service request.
  • the SF2 determines the corresponding security information according to the CDN ID and the Profile ID.
  • the SF2 calculates the token based on the key in the security information and the authentication parameter in the service request. The newer calculated token is consistent with the token carried in the service request. If they are consistent, the authentication is passed, otherwise the authentication fails.
  • the SF2 sends a service request to the CR2 according to the authentication result.
  • CR2 returns a service response to SF2.
  • the CR2 performs different processing for different service requests, and the specific processing depends on the operator policy.
  • the specific processing procedure is not limited in the embodiment of the present invention.
  • the SF2 sends a service response to the SF1.
  • SF1 sends a service response to CR1.
  • the CDN1 carries the authentication parameters and tokens required for the CP authentication, and the CDN2 recalculates the token according to the authentication parameters and the key shared with the CDN1, and compares the generated token with the received token, and further Complete the certification of the CP.
  • Embodiment 3 Based on the scenario of FIG. 4, this embodiment implements CDN2 authentication to the CP during content delivery. The specific authentication process is as shown in FIG. 6:
  • Security function SF1 sends security information to SF2. See S500 in Figure 5 for the specific process of this step.
  • the terminal browses a navigation portal of the CP, and carries the authentication parameter and the token in the response message returned by the CP.
  • Authentication parameters and tokens can be returned via a URL, for example:
  • the authentication parameters include: request URIJ domain name, CDN identifier, subscription identifier, client identifier, Authentication method, certification scheme.
  • the CDN identifier, the contract identifier, the client identifier, the authentication method, and the authentication scheme are optional.
  • the authentication parameter adds the client ID. By adding this flag, other clients can be prevented from resending the message.
  • the CP portal can use the IP address of the browsing request message as the client identifier.
  • the CDN identifier, the contract identifier, the client identifier, the authentication method, and the authentication scheme are optional.
  • S602-S603 The terminal initiates a service request to CR1, and CR1 notifies the terminal to redirect the service request to CR2 through the service response message.
  • the request carries an authentication parameter and a token.
  • the service request message is as follows:
  • the authentication parameters include: request URIJ domain name, CDN identifier, subscription identifier, client identifier, authentication method, and authentication scheme.
  • the CDN identifier, the contract identifier, the client identifier, the authentication method, and the authentication scheme are optional. If they are available on the CP portal, they can be carried.
  • the CDN identifier, the contract identifier, the client identifier, the authentication method, and the authentication scheme are optional.
  • the authentication parameter adds the client ID. Since different clients have different IP or MAC addresses, by adding this identifier, other clients can be prevented from resending the message.
  • the client address can be an IP address or a MAC address.
  • the token can be calculated by using the URL, or the domain name in the URL, and the SHA1 is taken as an example.
  • the token SHA1 (request URL/domain name, CDN identifier, subscription identifier, client identifier, authentication method, authentication scheme, key) ).
  • the terminal sends the service request information to CR2.
  • the terminal initiates a service request to CR2 according to the service response message received in S603.
  • the service request carries authentication parameters and tokens.
  • S605 and CR2 send a service request to the SF2, and the service request carries the authentication parameter and the token.
  • the SF2 authenticates the service request, and returns a service response to CR2.
  • the step may include:
  • A. SF2 determines the corresponding security information according to CDNID or ProfilelD. If the CDNID and Profile1D are not carried in the authentication parameters, the corresponding security information can be determined according to the CP domain name.
  • the SF2 calculates the token according to the key in the security information and the authentication parameter in the service request. The token is compared with the token carried in the service request. If the token is consistent, the authentication is passed, otherwise the authentication is not Pass
  • the CDN2 when the CDN1 has issued the security information to the CDN2, the CDN2 obtains the key from the security information, and obtains the authentication parameter and the token provided by the CP from the service request, and authenticates the CP. .
  • the CP only needs to have a contract with CDN1. It only needs to know the CDN1 system, such as configuration, reporting system, and so on. This solution greatly simplifies the work of the CP.
  • Example 4 In this embodiment, based on the scenario of FIG. 4, the CDN2 authenticates the CP in the content delivery process. This embodiment assumes that the CDN1 does not send security information to the CDN2. Therefore, CDN2 needs to interact with CDN1 to complete the authentication of the service request. The specific authentication process is shown in Figure 7.
  • S701-S704 is the same as S602-S605 of the second embodiment.
  • the authentication parameters and the tokens in the service request sent by the terminal in the S701 are also obtained by the CP.
  • the specific process refer to the description of S601 in the embodiment 2, and the description is not repeated here.
  • CR1 may add routing information of CDN1 to the redirect message, so that SF2 can send the service request to CDN1 in step S705.
  • the routing information may directly carry the URL or IP address of the SF1; or carry the CDN1 identifier and/or the subscription identifier, so that the SF2 determines the destination of the route according to the identifier, for example, obtains the URL or IP address of the SF1 from the local configuration information.
  • the SF2 sends a service request to the SF1.
  • SF2 can determine to which address to send a service request message according to the routing information in the message. As described in S702.
  • This embodiment indicates that SF2 directly sends a service request message to SF1, and the message can also be forwarded through CR1.
  • the SF1 authenticates the service request, and returns a service response to the SF2.
  • the step may include:
  • SFl determines the corresponding security information according to CDNID or ProfilelD. If the CDNID and Profile1D are not carried in the authentication parameters, the corresponding security information can be determined according to the CP domain name.
  • B. SF1 calculates a token according to the key in the security information and the authentication parameter in the service request; compares the newly calculated token with the token carried in the service request, and if they are consistent, the authentication passes, otherwise the authentication fails;
  • S801-S804 is the same as S602-S605 of the second embodiment.
  • the authentication parameters and the tokens in the service request sent by the terminal in the S801 are also obtained by the CP in the embodiment.
  • the specific process refer to the description of S601 in the embodiment 2, and the description is not repeated here.
  • CR1 may add routing information to the redirect message, so that CR2 in S806 can send the service request to CDN1.
  • the routing information may directly carry the URL or IP address of the SF1, or carry the CDN2 identifier and/or the subscription identifier, so that the SF2 determines the destination of the route according to the identifier, for example, obtains the URL or IP address of the SF1 from the local configuration information.
  • the SF2 redirect service requests to CR2.
  • CR2 sends a service request to SF1.
  • CR2 can determine which address to send the service request message according to the routing information in the message. As described in step 2.
  • the SF1 authentication service request returns a service response to CR2.
  • the step may include: A. SF1 determines corresponding security information according to CDNID or ProfilelD. If the CDNID and ProfilelD are not carried in the authentication parameters, the corresponding security information may be determined according to the CP domain name.
  • the SF1 calculates the token according to the key in the security information and the authentication parameter in the service request. The token is compared with the token carried in the service request. If the token is consistent, the authentication is passed, otherwise the authentication is not Pass
  • S900 and SF1 send security information to SF2.
  • This step is the same as S500 of Embodiment 1.
  • This step is optional.
  • CDN1 sends security information to CDN2
  • local authentication can be completed by CDN2.
  • CDN1 will complete the authentication process for CDN2.
  • the terminal initiates a service request to CR1, and CR1 notifies the terminal to redirect the service request to CR2 through the service response message.
  • the request did not carry a token.
  • the service request message is as follows: http ://www. sina. com/movie/hero . fl v
  • the terminal sends the request information to CR2.
  • the terminal initiates a service request to CR2 according to the redirect message received in step S902.
  • CR2 sends a service request to SF2.
  • SF2 sends an authentication request to SF1.
  • the SF2 determines that the token is not carried in the service request.
  • the SF2 sends an authentication request to the SF1.
  • the authentication request may carry the SF2 constructed authentication parameter.
  • HTTP POST Take HTTP POST as an example:
  • the CDN ID is the identifier of CDN1;
  • the Profile ID is the subscription identifier of CDN1 and CDN2.
  • the authentication parameters of the above request message may also be through an HTTP message header field, or a message body (eg,
  • the SF1 sends an authentication request to the content carrier CP (specifically, the content entity's security entity).
  • SF1 replaces the Profile ID with the subscription ID between CDN1 and CP. If the CDN1 is sent to the security information of CDN2 and the subscription identifier between CP and CDN1 is used directly, then SF1 does not need to replace the value of the subscription identifier.
  • the authentication parameters of the above request message may also be carried through an HTTP message header field or a message body (such as XML).
  • CP (specifically the security entity of the content carrier) returns the authentication response.
  • the security entity of the CP calculates the token according to the authentication parameter, and carries the token in the authentication response and returns it to SF1.
  • the authentication response message may optionally carry an authentication parameter, and the authentication parameter received in the authentication request.
  • the authentication parameters and tokens can also be carried through the HTTP message header field or the message body (such as XML).
  • S908 and SF1 perform local verification. This step is optional. If S900 is executed, it does not need to execute this step but executes S910. Otherwise, this step is required. Specifically, SF1 generates a token according to the authentication parameter and the shared key, and compares whether the generated token is consistent with the token returned from the CP, and if they match, the authentication passes.
  • SF1 returns an authentication response to SF2. If S908 is not executed, the step is also omitted. This message is the same as the authentication response message in S907.
  • SF2 performs local verification. This step is optional. If S900 is executed, this step is required. Otherwise, step S908 is performed. SF2 calculates the token based on the authentication parameters and the key, and compares the calculated token with the token returned from the CP. If they are consistent, the authentication is passed; otherwise, the authentication fails.
  • SF2 If the authentication is passed, SF2 returns 200 OK; otherwise it returns 401 (unauthorized).
  • S912 CR2 returns a service response to the terminal.
  • SF2 sends an authentication request to the CP (specifically, the security entity of the content carrier) through SF1.
  • SF2 can also send an authentication request directly to the CP.
  • SF2 may also return 401 (unauthorized) to the UE.
  • the UE sends an authentication request to the CP, and forwards the authentication response returned by the CP to the SF2, and the SF2 verifies the returned authentication response.
  • the token information of the CP response is obtained by initiating a CP authentication request, so that the CDN2 can authenticate the CP according to the obtained authentication parameter and the token information.
  • the CDN2 is authenticated to the CP.
  • the CP only has a contractual relationship with the CDN1, which greatly simplifies the system operation, maintenance, statistics, monitoring, etc. of the CP. Work.
  • the ⁇ In this embodiment, based on the scenario of FIG. 4, the CDN2 is authenticated to the CP, and CDN1 and CDN2 adopt different security schemes and communicate through the gateway.
  • the method of this embodiment can be applied to both the content distribution process and the content delivery process.
  • the request/service response processed by CDN1 and CDN2 can be converted through the security gateway. Thereby successfully completing the certification of the business request.
  • the authentication request/authentication response processed by CDN1 and CDN2 can also be converted by the security gateway.
  • the security gateway When the security gateway is implemented, it can be implemented as part of the security function.
  • S100 SF2 sends a service request to the security gateway.
  • the security gateway processes the received service request.
  • the security gateway verifies that the service request is legal and converts the service request into a format that SF1 can process.
  • the security gateway sends the converted service request to SF1.
  • SF1 returns a service response to the security gateway.
  • the service request received by SF1 authentication returns the service response, and the service response carries the token.
  • the specific authentication process refer to the authentication process of the security function in the above embodiment.
  • the security gateway processes the received service response.
  • the security gateway verifies that the service response is legal and converts the service response to a format that SF2 can handle.
  • the security gateway sends the converted service response to SF2.
  • the security gateway processes the authentication request and the authentication response in the same way. For details, see S1101-S1106, and details are not mentioned here.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种实现CDN互通的认证方法、装置与系统，所述方法包括：第二内容分发网络CDN2接收来自第一内容分发网络CDN1或终端的业务请求；所述CDN2获取由内容提供商CP提供的认证参数和令牌，所述CP与所述CDN1签约，所述CDN1与所述CDN2签约，所述CP未与所述CDN2签约；所述CDN2根据所述认证参数和令牌对所述CP进行认证；所述CDN2根据认证结果，向所述CDN1或所述终端返回业务响应。本发明实施例的方法、装置与系统，通过CDN2对CP进行认证，保证了CDN1和CDN2之间互通的安全性，使CDN2只为和CDN1签约的CP提供服务。

Description

一种实现 CDN互通的认证方法、 装置与系统 本申请要求于 2011 年 03 月 31 日提交中国专利局、 申请号为 201110080623.0、 发明名称为 "一种实现 CDN互通的认证方法、 装置与系 统" 的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信技术领域， 特别涉及一种实现 CDN (Content Dilivery Network, 内容分发网络） 互通的认证方法、 装置与系统。 背景技术
内容提供商为了扩展自己的数据业务 （如上网业务， 视频业务等）， 往 往需要部署大量的服务器， 供用户访问。 图 1为采用 C-S (客户端-服务器) 模式由内容提供商 （Content Provider, CP) /业务运营商 （Service Provider,
SP) 的内容源服务器为终端提供内容服务的示意图。
随着业务访问的增多， 图 1所示的部署模式暴露出一些问题。 首先， 这些服务器往往部署在网络的较高位置 （如骨干层， 汇聚层等）， 以达到较 大的覆盖范围， 但当海量用户访问时， 将会导致骨干、 汇聚层带宽的大量 占用， 对网络带宽造成很大压力。 其次， 由于服务器位置较高， 用户请求 有较大时延， 造成用户体验不理想。
针对上述问题， 出现了独立的 CDN服务提供商。 CDN服务提供商通 过在网络边缘部署大量边缘缓存节点组成的 CDN系统，就近为用户提供服 务， 从而达到节省网络带宽， 提升用户业务体验的目的。 同时， 电信运营 商也开始自己部署 CDN系统， 一方面为自己的业务加速， 同时可以提供给 其他内容提供商使用。
CDN系统的出现，使得内容提供商可以仅仅部署少量的内容源服务器， 就可以完成业务提供。 同时， 当用户数量增长时， CDN系统负责处理业务 流量， 而内容提供商无需进行网络扩容。采用 CDN系统为终端用户提供内 容服务的网络模型如图 2所示。
CDN运营商、 电信运营商根据自己的业务发展规划， 选择在不同的地 区部署 CDN系统。 各厂家的 CDN系统之间覆盖范围不同， 同时也可能存 在覆盖区域的重叠。 但目前 CDN系统还没有标准化， 各个厂家的 CDN系 统自成体系， 相互之间独立运作， 没有合作， 造成各个 CDN系统之间能力 无法互补。
比如， 第一内容分发网络 CDN1覆盖了北京、 上海； 第二内容分发网 络 CDN2覆盖了西安、深圳。此时如果某个内容提供商 CP希望其内容在北 京、 上海、 西安、 深圳四地的用户都可以访问， 则无论 CDN1还是 CDN2 都无法单独满足该内容提供商的要求， 因而需要 CDN 之间的互通。 由于 CP与 CDN1签约、 CDN1与 CDN2签约，而 CP未与 CDN2签约，此时 CDN2 无法对 CP进行安全认证。 发明内容
为了克服现有技术的缺陷，本发明实施例提供一种实现 CDN互通的认 证方法、 装置与系统， 当 CP与 CDN1签约、 CDN1与 CDN2签约， 而 CP 未与 CDN2签约时， 实现 CDN2对 CP的认证。
一方面， 本发明实施例提供一种实现 CDN互通的认证方法， 所述方法 包括： 第二内容分发网络 CDN2接收来自第一内容分发网络 CDN1或终端 的业务请求；所述 CDN2获取由内容提供商 CP提供的认证参数和令牌，所 述 CP与所述 CDN1签约，所述 CDN1与所述 CDN2签约， 所述 CP未与所 述 CDN2签约； 所述 CDN2根据所述认证参数和令牌对所述 CP进行认证； 所述 CDN2根据认证结果， 向所述 CDN1或所述终端返回业务响应。
另一方面， 本发明实施例提供一种实现 CDN互通的认证装置， 所述装 置位于第二内容分发网络 CDN2 中， 所述装置包括： 接收单元， 用于接收 来自第一内容分发网络 CDN1 或终端的业务请求； 获取单元， 用于获取由 内容提供商 CP提供的认证参数和令牌； 所述 CP与所述 CDN1签约， 所述 CDNl与所述 CDN2签约， 所述 CP未与所述 CDN2签约； 认证单元， 用于 根据所述获取单元获取到的认证参数和令牌对所述 CP进行认证； 发送单 元， 用于根据所述认证单元的认证结果， 向所述 CDN1 或所述终端返回业 务响应。
又一方面， 本发明实施例提供一种实现 CDN互通的认证系统， 所述系 统包括： 位于第二内容分发网络 CDN2的安全功能装置 SF2和位于第一内 容分发网络 CDN1的安全功能装置 SF1 ; 所述 SF2, 用于接收来自所述 SF1 或终端的业务请求； 获取由内容提供商 CP提供的认证参数和令牌， 所述 CP与所述 CDN1签约， 所述 CDN1与所述 CDN2签约， 所述 CP未与所述 CDN2签约；根据所述认证参数和令牌对所述 CP进行认证；根据认证结果， 向所述 SF1或所述终端返回业务响应。
本发明实施例的方法、 装置与系统， 当 CP与 CDN1签约、 CDN1与 CDN2签约， 而 CP未与 CDN2签约时， 由 CDN2获取 CP的认证参数和令 牌， 并根据获取的认证参数和令牌对所述 CP进行认证， 保证了 CDN1和 CDN2之间互通的安全性， 使 CDN2只为和 CDN1签约的 CP提供服务。 附图说明
图 1为现有技术采用 C-S模式由 CP/SP的内容源服务器为终端提供内 容服务的示意图；
图 2为现有技术采用 CDN系统为终端用户提供内容服务的网络模型 图；
图 3为本发明实施例的 CDN系统功能架构图；
图 4为本发明实施例的典型应用场景图；
图 4a为本发明实施例实现 CDN互通的认证方法流程图；
图 4b为本发明实施例实现 CDN互通的认证装置功能框图；
图 4c为本发明实施例实现 CDN互通的认证系统连接关系示意图； 图 5为本发明实施例 CDN2对 CP的认证流程图之一； 图 6为本发明实施例 CDN2对 CP的认证流程图之二；
图 7为本发明实施例 CDN2对 CP的认证流程图之三；
图 8为本发明实施例 CDN2对 CP的认证流程图之四；
图 9为本发明实施例 CDN2对 CP的认证流程图之五；
图 10为本发明实施例 CDN2对 CP的认证流程图之六。 具体实施方式
本发明实施例提供了一种实现 CDN 互通的认证方法、 装置和系统。 CDN互通可以促进 CDN系统之间的能力互补， 如覆盖能力的扩展， 以及 CDN系统流量增大时的负荷分担等。 安全是 CDN互通的关键问题之一， 当 CDN2和 CDN1互通时，必须确保 CDN2只为与之存在互通关系的 CDN1 提供服务。本发明实施例的技术方案，可以解决 CDN互通时的安全性问题， 促进不同 CDN系统之间的互通。
本发明实施例的 CDN系统功能架构如图 3所示。
( 1 ) 内容源： Content Source (CS )
存储原始内容， 并把内容传送到 CDN系统。 CP/SP可以自己部署内容 源， 也可以选择把内容存储在第三方存储系统。
存储在内容源的内容可以通过内容注入过程注入到 CDN系统（更具体 些， 是注入到内容存储实体， 或者内容交付实体）。 CDN系统也可以在必要 的时候主动向内容源请求内容。
(2) 存储控制： Storage Controller
存储控制选择合适的内容存储从内容源获取内容； 以及选择合适的内 容交付从指定的内容存储获取内容。
存储控制的功能具体包括： 了解内容存储的负载状态，如 CPU使用率、 内存使用情况、 输入输出带宽情况； 了解内容存储的能力信息， 如支持的 内容注入协议 （如 HTTP, FTP) , 内容分发协议 （HTTP, FTP) 等； 负责 内容请求的路由， 如内容注入请求， 内容分发请求等。 (3 ) 交付控制： Delivery Controller
交付控制选择内容交付实体为终端传送媒体内容。
交付控制实体的功能具体包括： 了解内容交付的负载状态， 如 CPU使 用率、 内存使用情况、 输入输出带宽情况； 了解内容交付的能力信息， 如 支持的内容注入协议 （如 HTTP, FTP) , 内容交付协议 （如 RTSP, HTTP, SilverLight, Flash)等； 负责内容相关请求的路由， 如内容注入， 内容分发。
(4) 内容路由： Content Route (CR)
本发明实施例中， 将存储控制和交付控制统称为内容路由。 为了简化 起见， 本发明下述实施例中， 内容路由不具体区分为存储控制和交付控制， 只采用内容路由实体描述相关实施例。
(5 ) 安全功能： Security Fucntion ( SF)
本发明实施例中， 安全功能是一个逻辑功能实体， 可以位于控制层， 或者资源层。 可以独立设置， 或者集成到内容路由或内容交付实体中。
SF的功能具体包括： CP安全信息（如共享密钥，认证方法等）的管理； CP安全信息的传递，比如 CDN1的 SF1传递 CP的安全信息给 CDN2的 SF2; 完成对 CP的认证， 或者说对 CP特定门户的认证； 可选地， 还包括 CDN 之间的认证， 比如 CDN2认证 CDN1是签约的 CDN。
(6) 内容存储： Content Storage (CSG)
CSG从内容源获取、 存储原始内容， 并分发给内容交付实体； 可选地， CSG还可以对内容进行预处理， 如内容分片， 转码。
(7) 内容交付： Content Delivery (CD)
CD从内容存储获取内容， 并分发给终端； 可选地， CD还可以对内容 进行码率转换， 文件格式转换， 分片等处理。
本发明实施例以 2个 CDN互通为例进行说明，该方案适用的典型场景 如图 4所示： 假设 CDN1覆盖区域 1， CDN2覆盖区域 2。 CP希望在区域 1 和区域 2为用户提供服务， CP只和 CDN1签约， CDN1和 CDN2签约。 由 于 CP只和 CDN1签约， 因此认为内容注入到 CDN1 的内容存储实体。 同 时， 由于 CP只与 CDN1签约， 因而内容交付请求先到达 CDN1的内容路 由。
CDN系统互通涉及到如下业务流程： 内容分发流程， 内容交付流程。 通过内容分发流程， CDN2从 CDN1获取内容， 包括 CDN1向 CDN2推送 内容， 或者 CDN2向 CDN1请求内容。 通过内容交付流程， 终端从 CDN2 获取媒体内容。
实施例 1描述了 CDN安全互通的完整流程，实施例 2描述了内容分发 流程的安全互通过程，实施例 3-6描述内容交付流程的安全互通过程，实施 例 7适用于内容分发以及内容交付流程。
为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本 发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描 述， 显然， 所描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有做出创造性劳动前提 下所获得的所有其他实施例， 都属于本发明保护的范围。 实施例 1 :
本实施例首先提供一种实现 CDN互通的认证方法， 该方法应用于图 4 所示的场景； 图 4a为本实施例的方法流程图， 如图 4a所示， 该方法包括：
S401、 CDN2接收来自 CDN1或终端的业务请求；
S402、CDN2获取由 CP提供的认证参数和令牌，所述 CP与所述 CDN1 签约， 所述 CDN1与所述 CDN2签约， 所述 CP未与所述 CDN2签约；
5403、 CDN2根据所述认证参数和令牌对所述 CP进行认证；
5404、 CDN2根据认证结果， 向 CDN1或所述终端返回业务响应。 可选地， S402具体包括： CDN2从所述业务请求中获取由 CP提供的 认证参数和令牌;或者 CDN2从所述业务请求中获取由 CP提供的认证参数， 并通过与 CP的认证过程获取由 CP提供的令牌。 可选地， 所述方法还包括： CDN2接收 CDN1发送的安全信息， 所述 安全信息至少包括 CP与 CDN1的共享密钥；相应地， S403具体包括： CDN2 根据所述认证参数和所述共享密钥生成令牌， 比较生成的令牌与获取的令 牌是否一致， 如果一致则认证通过。
可选地， 当 CDN1没有将安全信息下发给 CDN2时， S403具体包括：
CDN2将所述认证参数和令牌提供给 CDN1 , 由 CDN1根据 CP与 CDN1的 共享密钥、所述认证参数和令牌对所述 CP进行认证； 并接收由 CDN1返回 的认证结果。
可选地， 所述方法还包括： CDN1与 CDN2之间通过安全网关进行协 议和 /或消息格式的转换。
可选地， 所述方法的执行主体为： CDN2中的安全功能装置。
对应于图 4a的方法， 本实施例还提供一种实现 CDN互通的认证装置， 所述装置位于第二内容分发网络 CDN2中； 图 4b为该装置的功能框图， 如 图 4b所示， 该装置 40包括： 接收单元 401， 用于接收来自 CDN1或终端的 业务请求； 获取单元 402，用于获取由 CP提供的认证参数和令牌，所述 CP 与所述 CDN1签约，所述 CDN1与所述 CDN2签约，所述 CP未与所述 CDN2 签约； 认证单元 403， 用于根据所述获取单元获取到的认证参数和令牌对所 述 CP进行认证；发送单元 404，用于根据所述认证单元的认证结果，向 CDN1 或所述终端返回业务响应。
可选地， 所述获取单元 402， 具体用于从所述业务请求中获取由 CP提 供的认证参数和令牌； 或者从所述业务请求中获取由 CP提供的认证参数， 并通过与 CP的认证过程获取由 CP提供的令牌。
可选地， 所述接收单元 401， 还用于接收 CDN1发送的安全信息， 所述 安全信息至少包括 CP与 CDN1的共享密钥； 相应地， 所述认证单元 403， 具体用于根据所述获取单元获取到的认证参数和所述共享密钥生成令牌， 比较生成的令牌与获取的令牌是否一致， 如果一致则认证通过。 可选地， 当接收单元 401未从 CDN1接收到安全信息时， 所述认证单 元 403， 具体用于将所述认证参数和令牌提供给 CDN1 , 由 CDN1根据 CP 与 CDN1 的共享密钥、 所述认证参数和令牌对所述 CP进行认证； 接收由 CDN1返回的认证结果。
对应于图 4a的方法以及图 4b的装置， 本实施例还提供一种实现 CDN 互通的认证系统， 所述系统应用于图 4所示的场景； 图 4c为本实施例系统 连接关系示意图。
如图 4c所示， 本实施例的系统包括： 位于 CDN2的安全功能装置 SF2 和位于 CDN1的安全功能装置 SF1 ; 所述 SF2 , 用于接收来自 SF1或终端 的业务请求； 获取由 CP提供的认证参数和令牌， 所述 CP与所述 CDN1签 约， 所述 CDN1与所述 CDN2签约， 所述 CP未与所述 CDN2签约； 根据 所述认证参数和令牌对所述 CP进行认证；根据认证结果， 向 SF1或所述终 端返回业务响应。
可选地， 所述 SF2, 具体用于从所述业务请求中获取由 CP提供的认证 参数和令牌； 或者从所述业务请求中获取由 CP提供的认证参数， 并通过与 CP的认证过程获取由 CP提供的令牌。
可选地， 所述 SF2, 还用于接收 CDN1发送的安全信息， 所述安全信 息至少包括 CP与 CDN1的共享密钥；根据所述认证参数和所述共享密钥生 成令牌， 比较生成的令牌与获取的令牌是否一致， 如果一致则认证通过。
可选地， 所述 SF2, 还用于将所述认证参数和令牌提供给 SF1 , 由 SF1 根据 CP与 CDN1的共享密钥、 所述认证参数和令牌对所述 CP进行认证； 并接收由 SF1返回的认证结果。
可选地， 所述系统还包括： 位于 SF1和 SF2之间的安全网关 （图中未 示）； 所述安全网关， 用于实现 CDN1与 CDN2之间的协议禾口 /或消息格式 转换。
本发明实施例的方法、 装置与系统， 当 CP与 CDN1签约、 CDN1与 CDN2签约， 而 CP未与 CDN2签约时， CDN2通过获取 CP的认证参数和 令牌， 实现了 CDN2对 CP进行认证， 保证了 CDN1和 CDN2之间互通的 安全性， 使 CDN2只为和 CDN1签约的 CP提供服务。 实施例 2: 本实施例基于图 4的场景，实现了内容分发过程中 CDN2对 CP的认证。 该场景下， CDN1 根据特定分发规则主动进行内容分发即主动把内容从 CDN1推送到 CDN2。 具体认证过程如图 5所示：
S500、 安全功能装置 SF1下发安全信息给安全功能装置 SF2。
安全信息具体内容取决于 CP和 CDN1共享的安全信息，包括认证方式， CP与 CDN1之间的共享密钥， 认证方案等。
CDN1和 CDN2可能有多个签约，比如对应不同的 CP各自有不同的签 约， 或者同一个 CP下有多个不同的签约。 一般采用 CDN标识和签约标识 来标识这些签约，因而与安全信息同时下发的还可以有 CDN标识 (CDN ID) 和签约标识 （Profile ID)。 CDN2通过 CDN标识和签约标识， 可以唯一标 识某个特定 CDN的特定签约。
认证方式有对称密钥认证和非对称密钥认证两种。 当采用对称密钥认 证方式时，安全信息中的密钥为 CP和 CDN1的共享密钥。当采用非对称密 钥（公钥）认证方式时， 安全信息中的密钥为 CP的公钥。 本实施例以共享 密钥为例进行说明。
认证方案对应于不同的摘要算法， 如 MD5 (消息摘要 5)， SHA1 (安 全散列算法 1 )， 或者其他摘要算法。
本发明实施例可以把安全信息作为签约信息的一部分， 签约信息存储 签约双方的服务约定以及必要的共享信息， 是服务的基础。 本发明实施例 的签约信息示例如下： CDN标识、 签约标识、 安全信息（认证方式， 密钥， 认证方案）， 以及其他签约信息。 本发明实施例的签约信息和安全信息也可 以采用其他组织方式， 这些组织方式并不影响本方案的实现。 5501、 内容路由装置 CR1发送业务请求给 SF1。
以 HTTP请求为例， 该业务请求消息的 URL示意如下：
http：〃 www. sina.com/movie/hero.flv。 其中 www. sina.com为域名。
为了实现特定的业务， 业务请求消息还可能通过 URL, HTTP消息头 域或者消息体携带其他业务特定的参数， 本发明实施例对此不做限定。
5502、 SF1发送业务请求给 SF2， 其中携带认证参数。
该歩骤可以具体包括：
A、 SF1收到业务请求消息后， 如果判断该请求来自签约的 CP则进行 后续流程， 否则拒绝该请求；
B、 如果该请求来自签约的 CP, SF1进一歩判断该请求消息是否已经 携带了令牌；
C、 如果已经携带， SF1可以执行： 子歩骤 1 ) 直接转发该业务请求给 SF2; 或者子歩骤 2)增加新的认证参数， 如 CDN ID和 /或 Profile ID, 重新 计算令牌， 然后发送修改后的业务请求给 SF2。
D、 如果未携带令牌， SF1直接执行子歩骤 2)。
本实施例的认证参数包括： 请求 URIJ域名， CDN标识， 签约标识， 认证方式， 认证方案。 其中签约标识， 认证方式， 认证方案可选。
令牌由认证参数和密钥计算获得。 以 SHA1 为例， 令牌 =SHA1 (请求 URL/域名， CDN 标识， 签约标识， 认证方式， 认证方案， 密钥）。 其中签 约标识， 认证方式， 认证方案可选。
计算令牌时， 可以采用 URL， 或者 URL中的域名。
以 HTTP请求为例， 该业务请求消息 URL示意如下， 其中 TOKEN为 令牌：
http：〃 www.sina.com/movie/hero.flv?CDNID=1234&ProfileID=5678&Aut hMode=l &AuthAlgorithm=l &TOKEN=abcdefl23456.
具体实现时， 上述信息的携带方式不限。 比如认证参数也可以作为令 牌的部分内容。 同时， 可以用消息头域来携带令牌。
5503、 SF2对业务请求进行认证。
SF2根据CDN ID禾B/或Profile ID， 确定对应的安全信息。 SF2根据安 全信息中的密钥， 以及业务请求中的认证参数计算令牌； 比较新计算的令 牌和业务请求中携带的令牌是否一致； 如果一致， 则认证通过， 否则认证 不通过。
5504、 SF2根据认证结果， 发送业务请求给 CR2。
5505、 CR2返回业务响应给 SF2。
CR2 针对不同的业务请求执行不同的处理， 具体处理取决于运营商策 略， 本发明实施例对具体的处理过程不做限定。
5506、 SF2发送业务响应给 SF1。
5507、 SF1发送业务响应给 CR1。
本实施例中， CDN1携带 CP认证所需要的认证参数和令牌， CDN2根 据认证参数以及与 CDN1共享的密钥重新计算令牌， 通过比较生成的令牌 和收到的令牌是否一致， 进而完成对 CP的认证。 实施例 3: 本实施例基于图 4的场景，实现了内容交付过程中 CDN2对 CP的认证， 具体认证过程如图 6所示：
5600、安全功能 SF1下发安全信息给 SF2。该歩骤的具体过程参见图 5 的 S500。
5601、 终端浏览 CP的某个导航门户， 在 CP返回的响应消息中， 携带 认证参数和令牌。
认证参数和令牌可以通过 URL返回， 例如：
www.sina,com/mo\'ie/toO,'flv?CDNID=1234&ProfiteID==5678&C】ie:ntID== 10.144.111.11 & AutliMode^ 1 & AuthAlgorithm= 1 &TOKEN=abcdef 123456。
认证参数包括： 请求 URIJ域名， CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案。其中 CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案可选。
具体到上述响应消息： www. sina.com/mo vie/hero. flv为请求 URL, 其中 www.sina.com为域名; 1234为 CDN标识; 5678为签约标识; 10.144.111.11 为客户端标识， 此处以 IP 地址为例； AuthMode=l 代表认证方式， AuthAlgorithm=l代表认证方案。 TOKEN是计算所得到的令牌。
这里认证参数增加了客户端标识。 通过增加该标识， 可以防止其他客 户端重发该消息。 CP门户可以把浏览请求消息的 IP地址作为客户端标识。
令牌根据认证参数， 密钥计算得来。 以 SHA1 为例， 令牌 =SHA1 (请 求 URL/域名， CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案， 密钥）。 其中 CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案可 选。
S602-S603: 终端向 CR1发起业务请求， CR1通过业务响应消息通知终 端将业务请求重定向求到 CR2。
所述请求携带认证参数和令牌。 以 HTTP请求为例， 该业务请求消息 示意如下：
http：〃 www.sina.com/movie/hero.flv?CDNID=1234&ProfileID=5678&Clie ntID= 10.144.111.11 & AuthMode= 1 & AuthAlgorithm= 1 &TOKEN=abcdef 12345 6.
认证参数包括： 请求 URIJ域名， CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案。其中 CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案可选， 如果 CP门户上有， 可以携带。
所述令牌根据认证参数， 密钥计算得来。 以 SHA1 为例， 令牌 =SHA1 (请求 URL/域名， CDN标识， 签约标识， 客户端标识， 认证方式， 认证方 案， 密钥）。 其中 CDN标识， 签约标识， 客户端标识， 认证方式， 认证方 案可选。 这里认证参数增加了客户端标识。 由于不同客户端的 IP或者 MAC地 址不同， 通过增加该标识， 可以防止其他客户端重发该消息。 客户端地址 可以采用 IP地址或者 MAC地址。
本实施例可以采用 URL， 或者 URL 中的域名来计算令牌， 以 SHA1 为例， 令牌 =SHA1 (请求 URL/域名， CDN标识， 签约标识， 客户端标识， 认证方式， 认证方案， 密钥）。
S604、 终端发送业务请求信息到 CR2。
终端根据 S603 中收到的业务响应消息， 向 CR2发起业务请求。 业务 请求携带认证参数和令牌。
S605、 CR2发送业务请求给 SF2， 业务请求携带认证参数和令牌。
S606、 SF2认证业务请求， 返回业务响应给 CR2。
具体地， 该歩骤可以包括：
A、 SF2根据 CDNID禾 或 ProfilelD, 确定对应的安全信息。 如果认证 参数中没有携带 CDNID和 ProfilelD, 可以根据 CP域名确定对应的安全信 息；
B、 SF2根据安全信息中的密钥， 以及业务请求中的认证参数， 计算令 牌； 比较新计算的令牌和业务请求中携带的令牌是否一致， 如果一致， 则 认证通过， 否则认证不通过；
C、 认证成功后， 返回业务响应。
S607、 CR2返回业务响应给终端。
本发明实施例的方案， 当在 CDN1 已经下发安全信息给 CDN2的情况 下， CDN2从安全信息中获得密钥， 以及从业务请求中获得由 CP提供的认 证参数和令牌， 对 CP进行认证。 此时 CP只需和 CDN1有签约关系， 只需 要了解 CDN1 的系统即可， 如配置， 报表系统等。 该方案大大简化了 CP 的工作。 实施例 4: 本实施例基于图 4的场景，实现了内容交付过程中 CDN2对 CP的认证， 本实施例假设 CDN1没有下发安全信息给 CDN2。因而 CDN2需要和 CDN1 进行交互， 完成对业务请求的认证。 具体认证过程如图 7所示。
S701-S704同实施例 2的 S602-S605。
同实施例 2—样， 本实施例中 S701中终端发送的业务请求中的认证参 数和令牌也是由 CP获取， 具体过程参见实施例 2中对 S601的相关描述， 此处不再展开描述。
其中，歩骤 S702中， CR 1可以在重定向消息中增加 CDN 1的路由信息， 以便歩骤 S705中 SF2能够把业务请求发送给 CDN1。路由信息可以直接携 带 SF1的 URL或者 IP地址；或者携带 CDN1标识和 /或签约标识，以便 SF2 根据标识确定路由的目的地，例如从本地配置信息中获取 SF1的 URL或者 IP地址。
5705、 SF2发送业务请求给 SF1。
SF2可以根据消息中的路由信息， 确定向哪个地址发送业务请求消息。 如 S702所述。
本实施例示意 SF2直接发送业务请求消息给 SF1 , 该消息也可以经过 CR1转发。
5706、 SFl认证业务请求， 返回业务响应给 SF2。
具体地， 该歩骤可以包括：
A、 SFl根据 CDNID禾 或 ProfilelD, 确定对应的安全信息。 如果认证 参数中没有携带 CDNID和 ProfilelD, 可以根据 CP域名确定对应的安全信 息；
B、 SFl根据安全信息中的密钥， 以及业务请求中的认证参数， 计算令 牌； 比较新计算的令牌和业务请求中携带的令牌， 如果一致， 则认证通过， 否则认证不通过；
c、 认证成功后， 返回业务响应。 本发明实施例的方法，在 CDN1没有下发安全信息给 CDN2的情况下， 通过将认证参数和令牌提供给 CDN1，由 CDN1代替 CDN2对 CP进行认证 后， 向 CDN2返回认证结果， 从而实现了 CDN2对 CP的认证。 此时 CP只 需和 CDN1有签约关系。 大大简化了 CP系统运营、 维护、 统计、 监控等工 作。 实施例 5: 本实施例基于图 4的场景，实现了内容交付过程中 CDN2对 CP的认证。 本实施例同样假设 CDN1没有下发安全信息给 CDN2。 因而 CDN2需要和 CDN1进行交互， 完成对业务请求的认证。 具体认证过程如图 8所示：
S801-S804同实施例 2的 S602-S605。
同实施例 2—样， 本实施例中 S801中终端发送的业务请求中的认证参 数和令牌也是由 CP获取， 具体过程参见实施例 2中对 S601的相关描述， 此处不再展开描述。
其中 S802中， CR1可以在重定向消息中增加路由信息， 以便 S806中 CR2能够把业务请求发送给 CDN1。其中路由信息可以直接携带 SF1的 URL 或者 IP地址，或者携带 CDN2标识和 /或签约标识， 以便 SF2根据标识确定 路由的目的地， 例如从本地配置信息中获取 SF1的 URL或者 IP地址。
5805、 SF2重定向业务请求给 CR2。
5806、 CR2发送业务请求给 SF1。
CR2可以根据消息中的路由信息， 确定向哪个地址发送业务请求消息。 如歩骤 2所述。
5807、 SF1认证业务请求， 返回业务响应给 CR2。
具体地， 该歩骤可以包括： A、 SF1根据 CDNID禾 或 ProfilelD, 确定对应的安全信息。 如果认证 参数中没有携带 CDNID和 ProfilelD, 可以根据 CP域名确定对应的安全信 息；
B、 SF1根据安全信息中的密钥， 以及业务请求中的认证参数， 计算令 牌； 比较新计算的令牌和业务请求中携带的令牌是否一致， 如果一致， 则 认证通过， 否则认证不通过；
c、 认证成功后， 返回业务响应。
S808、 CR2返回业务响应给终端。 本发明实施例的方法，在 CDN1没有下发安全信息给 CDN2的情况下， 通过将认证参数和令牌提供给 CDN1，由 CDN1代替 CDN2对 CP进行认证 后， 向 CDN2返回认证结果， 从而实现了 CDN2对 CP的认证。 此时 CP只 需和 CDN1有签约关系。 大大简化了 CP的系统运营、 维护、 统计、 监控等 工作。 实施例 6: 本实施例基于图 4的场景，实现了内容交付过程中 CDN2对 CP的认证， 具体认证流程如图 9所示：
S900、 SF1下发安全信息给 SF2。 该歩骤同实施例 1的 S500。 该歩骤 为可选歩骤， 而在 CDN1下发安全信息给 CDN2的情况下， 可以由 CDN2 完成本地认证，在 CDN1没有下发安全信息给 CDN2的情况下，将由 CDN1 为 CDN2完成认证过程。
S901-S902,终端向 CR1发起业务请求， CR1通过业务响应消息通知终 端将业务请求重定向求到 CR2。
请求没有携带令牌。 以 HTTP请求为例， 该业务请求消息示意如下： http ://www. sina. com/movie/hero . fl v
S903、 终端发送请求信息到 CR2。 终端根据歩骤 S902中收到的重定向消息， 向 CR2发起业务请求。
5904、 CR2发送业务请求给 SF2。
5905、 SF2发送认证请求给 SF1。
SF2判断业务请求中没有携带令牌。 SF2发送认证请求给 SF1 , 可选地 该认证请求中可以携带 SF2构造的认证参数。 以 HTTP POST为例：
http：〃 www.sina.com/movie/hero.flv?CDNID=1234&ProfileID=5678&Aut hMode= 1 & AuthAlgorithm= 1.
这里 CDN ID为 CDN1的标识； Profile ID为 CDN1和 CDN2的签约标 识。
上述请求消息的认证参数也可以通过 HTTP消息头域，或者消息体（如
XML) 携带。
具体路由同前述的实施例 S701-S704的描述。
5906、 SF1发送认证请求给内容运营商 CP (具体为内容运营商的安全 实体）。
以 HTTP POST为例：
http ://www. sina. com/mo vie/hero .flv?CDNID= 1234&ProfileID=6789&Aut hMode= 1 & AuthAlgorithm= 1.
SF1把 Profile ID替换成 CDN1和 CP之间的签约标识。 如果 CDN1下 发给 CDN2的安全信息中， 直接使用 CP和 CDN1之间的签约标识， 则此 处 SF1不用替换签约标识的值。
上述请求消息的认证参数也可以通过 HTTP消息头域，或者消息体（如 XML) 携带。
5907、 CP (具体为内容运营商的安全实体） 返回认证响应。
CP的安全实体根据认证参数， 计算令牌， 把令牌携带在认证响应中返 回给 SF1。
以 HTTP为例：
HTTP/1.1 200 OK Authorization: response=abcdefl 23456.
认证响应消息可选携带认证参数， 同认证请求中收到的认证参数。 其中， 认证参数， 令牌也可以通过 HTTP消息头域， 或者消息体 （如 XML) 携带。
S908、 SF1进行本地验证， 该歩骤为可选歩骤， 如果执行 S900则不需 要执行此歩骤而是执行 S910, 反之则需要执行此歩骤。 具体地， SF1根据 认证参数和共享密钥生成令牌，比较生成的令牌与从 CP返回的令牌是否一 致， 如果一致则认证通过。
5909、 SF1返回认证响应给 SF2。如果 S908不执行， 则该歩骤也省略。 该消息同 S907中的认证响应消息。
5910、 SF2进行本地验证， 该歩骤为可选歩骤， 如果执行 S900则需要 执行此歩骤， 反之则执行歩骤 S908。 SF2根据认证参数和密钥， 计算令牌， 将计算生成的令牌和从 CP返回的令牌进行比较。 如果一致， 则认证通过； 否则认证不通过。
S91 SF2返回业务响应给 CR2。
如果认证通过， SF2返回 200 OK; 否则返回 401(未授权)。
S912 CR2返回业务响应给终端。
该实施例中， SF2通过 SF1向 CP (具体为内容运营商的安全实体） 发 送认证请求。 SF2也可以直接发送认证请求给 CP。
另外， S912中， SF2也可以返回 401 (未授权）给 UE。 UE向 CP发送 认证请求， 并转发 CP返回的认证响应给 SF2， SF2对返回的认证响应进行 验证。
本实施例中， 当业务请求未携带令牌时， 通过发起一个 CP的认证请求 获得 CP响应的令牌信息，使 CDN2能够根据获取的认证参数和令牌信息对 CP进行认证。 通过上述过程， 实现了 CDN2对 CP的认证， 此时 CP只需 和 CDN1有签约关系， 大大简化了 CP的系统运营、 维护、 统计、 监控等工 作。
实施例 Ί: 本实施例基于图 4的场景， 实现了 CDN2对 CP的认证， 其中 CDN1 和 CDN2采用不同安全方案， 通过网关互通。 本实施例的方法既可以用于 内容分发过程， 也可以适用于内容交付过程。
当 CDN1和 CDN2处理的业务请求 /业务响应不同， 例如采用的协议不 同， 或者消息内容不同， 可以通过安全网关， 进行请求 /业务响应的转换。 从而顺利完成业务请求的认证。 同理， 当 CDN1和 CDN2处理的认证请求 / 认证响应不同， 也可以通过安全网关转换。 安全网关具体实现时， 可以作 为安全功能的一部分来实现。
本实施例的具体认证流程如图 10所示：
S100 SF2发送业务请求给安全网关。
51002、 安全网关处理收到的业务请求。
安全网关验证业务请求是否合法， 并转换该业务请求为 SF1可以处理 的格式。
51003、 安全网关发送转换后的业务请求给 SF1。
51004、 SF1返回业务响应给安全网关。
SF1认证收到的业务请求， 返回业务响应， 业务响应携带令牌。具体认 证过程参见上述实施例中安全功能的认证过程。
51005、 安全网关处理收到的业务响应。
安全网关验证业务响应是否合法， 并转换该业务响应为 SF2可以处理 的格式。
51006、 安全网关发送转换后的业务响应给 SF2。
安全网关对认证请求和认证响应的处理过程相同， 详见 S1101-S1106, 此处不再赘述。
本实施例可以适用于上述所有实施例。 本发明实施例技术方案带来的有益效果： 当 CP与 CDN1签约、 CDN1 与 CDN2签约， 而 CP未与 CDN2签约时， 由 CDN2获取 CP的认证参数和 令牌， 并根据获取的认证参数和令牌对所述 CP进行认证， 保证 CDN1和 CDN2之间互通的安全性， 保证 CDN2只为和 CDN1签约的 CP提供服务。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流 程， 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储 于一计算机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的 实施例的流程。 其中， 所述的存储介质可为磁碟、 光盘、 只读存储记忆体 (Read-Only Memory, ROM)或随机存储记忆体 ( Random Access Memory, RAM) 等。
以上实施例仅用以说明本发明实施例的技术方案， 而非对其限制； 尽 管参照前述实施例对本发明实施例进行了详细的说明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相 应技术方案的本质脱离本发明实施例各实施例技术方案的范围。

Claims

权利要求
1、 一种实现 CDN互通的认证方法， 其特征在于， 所述方法包括： 第二内容分发网络 CDN2接收来自第一内容分发网络 CDN1或终端的 业务请求；
所述 CDN2获取由内容提供商 CP提供的认证参数和令牌，所述 CP与 所述 CDN1签约，所述 CDN1与所述 CDN2签约，所述 CP未与所述 CDN2 签约；
所述 CDN2根据所述认证参数和令牌对所述 CP进行认证；
所述 CDN2根据认证结果， 向所述 CDN1或所述终端返回业务响应。
2、 根据权利要求 1所述的方法， 其特征在于， 所述 CDN2获取由内容 提供商 CP提供的认证参数和令牌包括：
所述 CDN2从所述业务请求中获取由所述 CP提供的认证参数和令牌； 或者
所述 CDN2从所述业务请求中获取由所述 CP提供的认证参数，并通过 与所述 CP的认证过程获取由所述 CP提供的令牌。
3、 根据权利要求 1或 2所述的方法， 其特征在于，
所述方法还包括： 所述 CDN2接收所述 CDN1发送的安全信息， 所述 安全信息至少包括所述 CP与所述 CDN1的共享密钥或所述 CP的公钥； 所述 CDN2根据所述认证参数和令牌对所述 CP进行认证包括： 所述 CDN2根据所述认证参数和所述共享密钥生成令牌，比较生成的令牌与获取 的令牌是否一致， 如果一致则认证通过。
4、 根据权利要求 1或 2所述的方法， 其特征在于， 所述 CDN2根据所 述认证参数和令牌对所述 CP进行认证包括：
所述 CDN2将所述认证参数和令牌提供给所述 CDN1 , 由所述 CDN1 根据所述 CP与所述 CDN1的共享密钥、所述认证参数和令牌对所述 CP进 行认证； 并接收由所述 CDN1返回的认证结果。
5、根据权利要求 1所述的方法，其特征在于，所述方法通过所述 CDN2 中的安全功能装置实现。
6、 根据权利要求 5所述的方法， 其特征在于， 所述 CDN2中的安全功 能装置通过所述 CDN2中的内容路由装置和 CDN1交互。
7、 一种实现 CDN互通的认证装置， 其特征在于， 所述装置位于第二 内容分发网络 CDN2中， 所述装置包括：
接收单元，用于接收来自第一内容分发网络 CDN1或终端的业务请求; 获取单元， 用于获取由内容提供商 CP 提供的认证参数和令牌； 所述 CP与所述 CDN1签约， 所述 CDN1与所述 CDN2签约， 所述 CP未与所述 CDN2签约；
认证单元， 用于根据所述获取单元获取到的认证参数和令牌对所述 CP 进行认证；
发送单元， 用于根据所述认证单元的认证结果， 向所述 CDN1或所述 终端返回业务响应。
8、 根据权利要求 7所述的装置， 其特征在于，
所述获取单元，具体用于从所述业务请求中获取由所述 CP提供的认证 参数和令牌； 或者从所述业务请求中获取由所述 CP提供的认证参数， 并通 过与所述 CP的认证过程获取由所述 CP提供的令牌。
9、 根据权利要求 7或 8所述的装置， 其特征在于，
所述接收单元， 还用于接收所述 CDN1发送的安全信息， 所述安全信 息至少包括所述 CP与所述 CDN1的共享密钥或所述 CP的公钥；
所述认证单元， 具体用于根据所述获取单元获取到的认证参数和所述 共享密钥生成令牌， 比较生成的令牌与获取的令牌是否一致， 如果一致则 认证通过。
10、 根据权利要求 7或 8所述的装置， 其特征在于，
所述认证单元，具体用于将所述认证参数和令牌提供给所述 CDN1 , 由 所述 CDNl根据所述 CP与所述 CDNl 的共享密钥、 所述认证参数和令牌 对所述 CP进行认证； 接收由所述 CDN1返回的认证结果。
11、 一种实现 CDN互通的认证系统， 其特征在于， 所述系统包括： 位 于第二内容分发网络 CDN2的安全功能装置 SF2和位于第一内容分发网络 CDN1的安全功能装置 SF1 ;
所述 SF2, 用于接收来自所述 SF1或终端的业务请求； 获取由内容提 供商 CP提供的认证参数和令牌， 所述 CP与所述 CDN1签约， 所述 CDN1 与所述 CDN2签约， 所述 CP未与所述 CDN2签约； 根据所述认证参数和 令牌对所述 CP进行认证；根据认证结果， 向所述 SF1或所述终端返回业务 响应。
12、 根据权利要求 11所述的系统， 其特征在于，
所述 SF2,具体用于从所述业务请求中获取由所述 CP提供的认证参数 和令牌； 或者从所述业务请求中获取由所述 CP提供的认证参数， 并通过与 所述 CP的认证过程获取由所述 CP提供的令牌。
13、 根据权利要求 11所述的系统， 其特征在于，
所述 SF2, 还用于接收所述 CDN1发送的安全信息， 所述安全信息至 少包括 CP与 CDN1的共享密钥；根据所述认证参数和所述共享密钥生成令 牌， 比较生成的令牌与获取的令牌是否一致， 如果一致则认证通过。
14、 根据权利要求 11所述的系统， 其特征在于，
所述 SF2, 还用于将所述认证参数和令牌提供给所述 SF1 , 由所述 SF1 根据所述 CP与所述 CDN1的共享密钥、所述认证参数和令牌对所述 CP进 行认证； 并接收由所述 SF1返回的认证结果。
15、 根据权利要求 11所述的系统， 其特征在于， 所述系统还包括： 位 于所述 SF1和所述 SF2之间的安全网关；
所述安全网关， 用于实现所述 CDN1与所述 CDN2之间的协议禾 或消息 格式的转换。
PCT/CN2011/083908 2011-03-31 2011-12-14 一种实现cdn互通的认证方法、装置与系统 WO2012129934A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110080623.0 2011-03-31
CN 201110080623 CN102143184B (zh) 2011-03-31 2011-03-31 一种实现cdn互通的认证方法、装置与系统

Publications (1)

Publication Number Publication Date
WO2012129934A1 true WO2012129934A1 (zh) 2012-10-04

Family

ID=44410406

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/083908 WO2012129934A1 (zh) 2011-03-31 2011-12-14 一种实现cdn互通的认证方法、装置与系统

Country Status (2)

Country Link
CN (1) CN102143184B (zh)
WO (1) WO2012129934A1 (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102143184B (zh) * 2011-03-31 2013-08-28 华为技术有限公司 一种实现cdn互通的认证方法、装置与系统
WO2012163055A1 (zh) * 2011-11-18 2012-12-06 华为技术有限公司 一种媒体内容的传输方法以及相关装置
CN103297337A (zh) * 2012-02-23 2013-09-11 中兴通讯股份有限公司 一种实现内容分发网络互联路由的方法及系统
CN102932358B (zh) * 2012-11-07 2015-10-21 网宿科技股份有限公司 基于内容分发网络的第三方文件改写加速分发方法和装置
CN105530226B (zh) * 2014-09-30 2019-01-15 中国电信股份有限公司 内容分发网络系统及其接入控制方法和系统
CN104320679B (zh) * 2014-10-11 2019-02-15 中兴通讯股份有限公司 一种基于hls协议的用户信息获取方法和服务器
CN112507320A (zh) * 2020-12-10 2021-03-16 东莞市盟大塑化科技有限公司 访问控制方法、装置、系统、电子设备和存储介质
CN115378878B (zh) * 2021-05-21 2023-11-14 北京字跳网络技术有限公司 Cdn的调度方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043337A (zh) * 2007-03-22 2007-09-26 中兴通讯股份有限公司 内容类业务的交互方法
CN102143184A (zh) * 2011-03-31 2011-08-03 华为技术有限公司 一种实现cdn互通的认证方法、装置与系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100479571C (zh) * 2006-12-12 2009-04-15 华为技术有限公司 一种防止异常接入终端接入的方法和接入网
CN101582768A (zh) * 2009-06-12 2009-11-18 中兴通讯股份有限公司 一种电子广告系统中的登录认证方法及系统
CN101964791B (zh) * 2010-09-27 2014-08-20 北京神州泰岳软件股份有限公司 客户端与web应用的通讯认证系统及认证方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043337A (zh) * 2007-03-22 2007-09-26 中兴通讯股份有限公司 内容类业务的交互方法
CN102143184A (zh) * 2011-03-31 2011-08-03 华为技术有限公司 一种实现cdn互通的认证方法、装置与系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
G. WATSON.: "CDN Interconnect Use Cases.", IETF, 6 January 2011 (2011-01-06), pages 6 - 8 *

Also Published As

Publication number Publication date
CN102143184A (zh) 2011-08-03
CN102143184B (zh) 2013-08-28

Similar Documents

Publication Publication Date Title
WO2012129934A1 (zh) 一种实现cdn互通的认证方法、装置与系统
JP5106682B2 (ja) マシン・ツー・マシン通信のための方法及び装置
JP5496907B2 (ja) セキュアな通信のための鍵管理
US8959238B2 (en) Systems, methods and computer program products for providing access to web services via device authentication in an IMS network
JP4722478B2 (ja) 関連するストリーミングプロトコル群に対するセキュリティパラメータの統合
EP1811744A1 (en) Method, system and centre for authenticating in End-to-End communications based on a mobile network
CA2571891A1 (en) Device authentication and secure channel management for peer-to-peer initiated communications
US8713634B2 (en) Systems, methods and computer program products supporting provision of web services using IMS
WO2008089698A1 (fr) Procédé et système permettant de distribuer des clés secrètes du flux multimédia
KR20080090534A (ko) 모바일 네트워크에서 재귀 인증을 위한 방법 및 시스템
WO2009012670A1 (fr) Procédé, dispositif et système permettant d'enregistrer un nouveau membre de groupe lors d'une gestion de clé multidiffusion
EP3366019B1 (en) Method and apparatus for secure content caching and delivery
WO2011056110A1 (en) System and methods for web-application communication
WO2008040213A1 (fr) Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication
WO2011038691A1 (zh) 鉴权方法及装置
Festijo et al. Software-defined security controller-based group management and end-to-end security management
WO2020025028A1 (zh) 数据保护方法、装置及计算机存储介质
US20090136043A1 (en) Method and apparatus for performing key management and key distribution in wireless networks
US11089561B2 (en) Signal plane protection within a communications network
Christakidis et al. Integrating P2P with Next Generation Networks
JP4992335B2 (ja) ポリシーファイルの分配方法およびコミュニティシステム
WO2023246753A1 (zh) 通信方法和装置
Festijo et al. An open horizontal model for group management and end-to-end security management suitable for group-based private systems
WO2024108900A1 (zh) 一种电子签名验证方法及装置
US20220132369A1 (en) Payload compression

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11862840

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11862840

Country of ref document: EP

Kind code of ref document: A1