US9270771B2 - System and method for performing a delegation operation - Google Patents

System and method for performing a delegation operation Download PDF

Info

Publication number
US9270771B2
US9270771B2 US11/796,466 US79646607A US9270771B2 US 9270771 B2 US9270771 B2 US 9270771B2 US 79646607 A US79646607 A US 79646607A US 9270771 B2 US9270771 B2 US 9270771B2
Authority
US
United States
Prior art keywords
client
delegated
delegating
server
request message
Prior art date
Legal status (The legal status 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 status listed.)
Active, expires
Application number
US11/796,466
Other versions
US20070261106A1 (en
Inventor
Jae-Kwon Oh
Wuk Kim
Sang-Kyung Sung
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Assigned to SAMSUNG ELECTRONICS CO., LTD. reassignment SAMSUNG ELECTRONICS CO., LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KIM, WUK, OH, JAE-KWON, SUNG, SANG-KYUNG
Publication of US20070261106A1 publication Critical patent/US20070261106A1/en
Application granted granted Critical
Publication of US9270771B2 publication Critical patent/US9270771B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H04L67/24—
    • 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
    • H04L67/28—
    • H04L67/2819—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • 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

Definitions

  • the aggregation proxy server 422 performs a process for authenticating the requesting client according to OMA XDM V1.0 Enabler using a requesting client ID included in the X-XCAP-Asserted-Identity header, i.e., an ID of the XDMC 410 , as in step 301 of FIG. 3 . If the authentication is successful, the aggregation proxy server 422 forwards the XCAP request message to the XDMS 424 corresponding to the target system.
  • the UAC 510 includes its ID in the P-Preferred-Identity header according to RFC 3325.
  • the UAC 510 generates an SIP request message in which an ID of the delegating client 500 is included in the P-Intended-Delegated-Identity header and then sends the SIP request message to the target UAS 524 through an SIP proxy server 522 according to RFC 3261.
  • the SIP proxy server 522 forwards the received SIP response message to the UAC 510 corresponding to the delegated client according to RFC 3261.

Abstract

A method in which a delegated client sends a request message containing operation information, a delegated client identity (ID), and a delegating client ID at the time of sending an operation request to a target system. The target system receives the request message and delegation-authorizes the delegated client by examining whether the delegating client is authorized to perform the operation requested by the request message and also whether the delegating client has delegated the authority to perform the operation to the delegated client sending the request message using the delegating client ID included in the request message. A new header is provided which includes ID information of the delegating client in the request message. When receiving the request message, the target system performs a procedure for authenticating and authorizing not only the delegated client but also the delegating client using the delegating client ID.

Description

PRIORITY
This application claims priority under 35 U.S.C. §119 to an application filed in the Korean Intellectual Property Office on Apr. 28, 2006 and assigned Serial No. 2006-39051, the contents of which are incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to a system and method for performing a delegation operation, and more particularly to a system and method for performing a delegation operation that can authorize a delegated client for requesting an operation and a delegating client for delegating authority to the delegated client in a target system.
2. Description of the Related Art
Two cases based on an eXtensible Markup Language (XML) Configuration Access Protocol (XCAP), draft-ietf-simple-xcap, J. Rosenberg, and a Session Initiation Protocol (SIP), RFC 3261, J. Rosenberg, in a conventional Open Mobile Alliance (OMA) message service environment will be described with reference to FIGS. 1A and 1B. FIGS. 1A and 1B show examples of a conventional OMA messaging service system.
An example of OMA XDM V1.0 Enabler, openmobilealliance.org, messaging service system based on the XCAP will be described with reference to FIG. 1A. A general client 110 sends an XCAP PUT request to an XML Document Management Server (XDMS) 120. In OMA XDM V1.0 Enabler, only the client 110 of a user possessing an associated document can access and modify a document stored in the XDMS 120.
An example of OMA Presence SIMPLE V1.0 Enabler, openmobilealliance.org, messaging service system based on the SIP will be described with reference to FIG. 1B. A general client 110 sends an SIP PUBLISH message to a presence server 130. In OMA Presence V1.0 Enabler, only the client 110 representing the user whose presence information is of concern can generate the publication request.
Technology for sending an operation request from the general client to a particular target system is being used in the current OMA message service environment. A delegation operation is required in this OMA message service environment. That is, a delegation operation system is required in which a delegated client can send a particular operation request to an associated target system in place of a delegating client when authority is delegated between clients.
SUMMARY OF THE INVENTION
Therefore, the present invention provides a system and method for performing a delegation operation.
In accordance with an aspect of the present invention, there is provided a system for performing a delegation operation, the system including a delegated client for sending a request message for requesting that a target system should perform an operation, the request message including an identity (ID) of the delegated client and an ID of a delegating client; a proxy server for examining whether the delegated client requesting the operation is authentic using the delegated client ID included in the request message when receiving the request message and forwarding the request message to the target system when the delegated client is authenticated; and the target system for examining whether the delegating client is authorized to perform the operation requested by the request message and also whether the delegating client has delegated the authority to perform the operation to the delegated client sending the request message using the delegating client ID included in the request message when receiving the request message.
In accordance with another aspect of the present invention, there is provided a method for performing a delegation operation in a delegation operation system, the delegation operation system including a delegated client, a delegating client for delegating authority to the delegated client, a proxy server for authenticating the delegated client and then routing the received operation request to the target system when receiving the operation request from the delegated client, and a target system for authorizing the delegated client whether the delegated client is delegated with the authority to perform the operation on behalf of the delegating client and then performing the requested operation, the method including sending, from the delegated client, a request message for requesting that the target system should perform an operation, the request message including an ID of the delegated client and an ID of the delegating client; examining whether the delegated client requesting the operation is authentic using the delegated client ID included in the request message when the proxy server receives the request message and forwarding the request message to the target system when the delegated client is authenticated; and examining whether the delegating client is authorized to perform the operation requested by the request message and also whether the delegating client has delegated the authority to perform the operation to the delegated client sending the request message using the delegating client ID included in the request message when the target system receives the request message.
In accordance with another aspect of the present invention, there is provided a system for performing a delegation operation, the system including a requesting client for sending a request message for requesting that a target system should perform an operation; a proxy server for examining whether the requesting client is authentic when receiving the request message and forwarding the request message to the target system when the requesting client is authenticated; and the target system for determining whether the requesting client is a general client or a delegated client to which a delegating client has delegated authority when receiving the request message, and examining whether the delegating client is authorized to perform the operation requested by the request message and also whether the delegating client has delegated the authority to perform the operation to the delegated client sending the request message using a delegating client ID included in the request message when the requesting client is the delegated client, executing the requested operation when the delegated client is successfully delegation-authorized, and reporting the execution results to the requesting client.
In accordance with yet another aspect of the present invention, there is provided a method for performing a delegation operation in a delegation operation system, the method including sending, from a requesting client, a request message for requesting that a target system should perform an operation; examining whether the requesting client is authentic when a proxy server receives the request message and forwarding the request message to the target system when the requesting client is authenticated; and determining whether the requesting client is a general client or a delegated client to which a delegating client has delegated authority when the target system receives the request message, and examining whether the delegating client is authorized to perform the operation requested by the request message and also whether the delegating client has delegated the authority to perform the operation to the delegated client sending the request message using a delegating client ID included in the request message when the requesting client is the delegated client, executing the requested operation when the delegated client is successfully delegation-authorized, and reporting an execution result to the requesting client.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and other features and advantages of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
FIGS. 1A and 1B illustrate a conventional Open Mobile Alliance (OMA) messaging service system;
FIG. 2 illustrates a structure of a system for performing a delegation operation to authenticate and authorize a delegating client and a delegated client in accordance with the present invention;
FIG. 3 is a flowchart illustrating a process for performing a delegation operation to authenticate and authorize the delegating client and the delegated client in accordance with the present invention;
FIG. 4 illustrates a structure of a system for processing an Extensible Markup Language (XML) Configuration Access Protocol (XCAP) request when the delegated client sends the XCAP request to a target system in accordance with the present invention; and
FIG. 5 illustrates a structure of a system for processing a Session Initiation Protocol (SIP) request when the delegated client sends the SIP request to a target system in accordance with the present invention.
 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The present invention provides a method and system that can efficiently authenticate and authorize not only a delegated client but also a delegating client for delegating authority to the delegated client when the delegated client sends an operation request to a particular target system on behalf of the delegating client in an Open Mobile Alliance (OMA) messaging system.
In particular, the present invention provides a method in which a delegated client sends a request message containing operation information, a delegated client identity (ID), and a delegating client ID at the time of sending an operation request to a target system and the target system receives the request message and examines whether the delegating client is authorized to perform the operation requested by the request message and also the delegating client has delegated the authority to perform the operation to the delegated client sending the request message using a delegating client ID included in the request message. For this, the present invention provides a new header including ID information of the delegating client in the request message. When receiving the request message, the target system performs a procedure for authenticating and authorizing not only the delegated client but also the delegating client using the delegating client ID.
The present invention will be described below with reference to the accompanying drawings. FIG. 2 shows a system for authenticating and authorizing a delegated client in accordance with the present invention.
The delegated client 210 is the client to which the delegating client 200 has delegated the authority to perform an operation. The delegated client 210 can send an operation request to the target system 220 in place of the delegating client 200. When the delegated client 210 sends a request message to the target system 220, the request message contains operation information, a delegated client ID, and a delegating client ID.
When receiving the request message containing the above-described information, the target system 220 examines whether the associated delegated client is authentic. If the delegated client is authenticated, the target system 220 verifies whether the delegating client 200 is authorized to make the operation request and the delegated client 210 is authorized to delegate the authority to make the operation request on behalf of the delegating client 200.
An operation in which the target system 220 receives and processes the operation request message from the delegated client 210 will be described with reference to FIG. 3. FIG. 3 shows an operation for processing an operation request when the target system receives the operation request from a requesting client in accordance with the present invention.
When receiving the operation request message in step 300, the target system 220 proceeds to step 301 to authenticate the requesting client corresponding to the sender of the request message.
If the requesting client is authenticated, the target system 220 proceeds to step 302 to store in the request message the information indicating that the requesting client has been authenticated with respect to the associated request message. The additional authentication process for the same request message within the same system or between trusted systems can be omitted by referencing this information in the same request message.
When proceeding from step 302 to step 303, the target system 220 determines whether the operation request is the request from the delegated client. That is, the target system 220 determines whether the requesting client is the general client or the delegated client to which the delegating client has delegated the authority to perform the operation request.
If the operation request is determined to be the request from the delegated client in step 303, the target system 220 proceeds to step 306. Otherwise, the target system 220 proceeds to step 304 to determine whether the requesting client is authorized to perform the requested operation. If the requesting client is authorized to perform the requested operation, the target system 220 proceeds to step 308. If it is determined that the requesting client is not authorized to request the operation, the target system 220 proceeds to step 305 to perform error processing. The authority is verified by a predefined system policy. For example, in a current OMA Extensible Markup Language (XML) Document Management (XDM) V1.0 Enabler, an owner of information stored in an XML Document Management Server (XDMS) can make all types of XML Configuration Access Protocol (XCAP) requests for accessing and modifying the information. Thus, with this policy, an authentication examination relating to the request needs to only consider whether the requesting client is an owner of the associated information.
If the operation request is determined to be the request from the delegated client in step 303, the target system 220 determines whether the delegating client is authorized to perform the requested operation and if so, whether the delegating client has delegated the authority to perform the requested operation to the delegated client in step 306. That is, if the associated operation request is the request from the delegated client rather than the general client, the target system 220 examines whether the delegating client is authorized to perform the requested operation according to the predefined system policy. Further, along with this authorization examination on the delegating client, the target system 220 performs an authorization examination as to whether the delegated client is authorized to perform the requested operation in place of the delegating client.
As the delegation of the authority to perform some operations to other clients is the unique right of the delegating client, there can be two kinds of authorization methods to verify such delegation, which are: proactive authorization and reactive authorization. In the proactive authorization method, an authorization procedure on the delegation is performed based on the authorization rules predefined in the system by the delegating client. Such authorization rules include the information about the delegating client delegating which authorities to which clients. When this information is described in XML, it can be stored in advance in an associated XDMS. In the reactive authorization method, the system directly inquires the delegating clients for the information about the authority assigned to the delegated client such that the delegation authorization can be verified.
If all conditions for the delegating client are verified in step 306, the target system 220 proceeds to step 308 to execute the requested operation and then proceeds to step 309 to report an execution result to the requesting client through a response message.
In the present invention, the delegated client 210 includes operation information, a delegated client ID, and a delegating client ID in the request message and sends the request message to the target system 220. When receiving the request message, the target system 220 can authenticate and authorize not only the delegated client but also the delegating client using the operation information, the delegated client ID, and the delegating client ID contained in the request message.
When the delegated client 210 sends a particular operation request to the target system 220, the ID of the delegated client 210 and requested operation information are included and transmitted in a header of the request message. In the present invention, the header of the request message to be transmitted further includes the delegating client ID for identifying the delegating client in addition to the delegated client ID and the operation information. Thus, the present invention provides a new header to include three types of information.
The header including the client ID and the requested operation information to be transmitted will be described with reference to Table 1 when the general client issues an operation request.
TABLE 1
Headers that deliver the Requestor
Identity (These Headers deliver
Delegated User Identity in case of
Delegated Request)
XCAP Legacy X-XCAP-Asserted-Identity
request Network
IMS Network X-3GPP-Intended-Identity, or
X-3GPP-Asserted-Identity
SIP request Legacy P-Preferred-Identity, or
Network P-Asserted-Identity
IMS Network P-Preferred-Identity, or
P-Asserted-Identity
Table 1 shows the conventional headers for transmitting ID information of a requesting client in the XCAP and SIP requests in the legacy network and the Internet Protocol (IP) Multimedia Subsystem (IMS) network.
The X-XCAP-Asserted-Identity header is an extension of a Hyper Text Transfer Protocol (HTTP) header defined in OMA XDM V1.0 Enabler and is used to transmit the ID information of the requesting client from an XML Document Management Client (XDMC) to an XDMS in the legacy network. The transmitted requesting client ID information is used for authenticating and authorizing the requesting client sending an associated XCAP request.
Further, the X-3GPP-Intended-Identity or X-3GPP-Asserted-Identity header is an extension of an HTTP header defined in 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 24.109 “Technical Specification Group Core Network and Terminals: Bootstrapping interface (Ub) and network application function interface (Ua): Protocol details (Release 6)”, and is used to transmit the ID information of the requesting client relating to an HTTP request (or an XCAP request implemented based on the HTTP request) from an HTTP client to an HTTP server in the IMS network. Similarly, the transmitted ID information of the requesting client is used for authenticating and authorizing the requesting client sending an associated HTTP request. The X-3GPP-Intended-Identity header is used to transmit the ID information of the requesting client that the requesting client wishes to use for the authentication and authorization in the system on the requesting client. On the other hand, the X-3GPP-Asserted-Identity header is used to transmit an authenticated requesting client ID provided from the system when an client ID desired by the requesting client has not been transmitted, i.e., the X-3GPP-Intended-Identity header has not been used.
Further, the P-Preferred-Identity or P-Asserted-Identity header is an extension of an SIP header defined in Request For Comments (RFC) 3325 “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks”, and is used to transmit the requesting client ID information of the SIP request from a User Agent Client (UAC) to a User Agent Server (UAS) in the legacy network and the IMS network. The transmitted requesting client ID information is used for authenticating and authorizing the requesting client sending an associated SIP request. At this time, the P-Preferred-Identity header is used to transmit requesting client ID information that has not yet been authenticated in the system. The requesting client ID information that has been successfully authenticated in the system is transmitted in the P-Asserted-Identity header.
The header shown in Table 1 is used to transmit ID information of the requesting client, or the delegated client in case of the delegated request message. Thus, the above-described method does not transmit, to the system, ID information of the delegating client that has delegated the authority to the delegated client.
Thus, the present invention provides a header for transmitting the ID information of the delegating client to the system. For this, header extensions to be used for the XCAP and SIP requests in the legacy network and the IMS network are shown in Table 2. Table 2 is based on the technology of Table 1. The header including the delegating client ID information is referred to as Delegation Header in this invention. The Delegation Header will be described with reference to Table 2.
TABLE 2
Header that delivers Delegating User
Identity
XCAP Legacy X-XCAP-Intended-Delegated-Identity
request Network
IMS Network X-3GPP-Intended-Delegated-Identity
SIP request Legacy P-Intended-Delegated-Identity
Network
IMS Network P-Intended-Delegated-Identity
The X-XCAP-Intended-Delegated-Identity header of Table 2 is mapped to the X-XCAP-Asserted-Identity header of Table 1, and is an extension of an HTTP header. When the delegated client sends an XCAP request to the system in the legacy network, the X-XCAP-Intended-Delegated-Identity header is used to transmit the ID information of the delegating client from an XDMC to an XDMS. The target system uses the transmitted delegating client ID to authenticate and authorize the delegating client with respect to the XCAP request from the associated delegated client as in step 306 of FIG. 3.
Further, the X-3GPP-Intended-Delegated-Identity header of Table 2 is mapped to the X-3GPP-Intended-Identity header of Table 1, and is an extension of an HTTP header in the IMS network. The X-3GPP-Intended-Delegated-Identity header is used to transmit the ID information of the delegating client from an HTTP client to an HTTP server when an HTTP request (or an XCAP request implemented based on the HTTP request) is transmitted from the delegated client to the system. The transmitted delegating client ID is used as information for authenticating and authorizing the delegating client according to the HTTP request from the associated delegated client to the system as in step 306 of FIG. 3.
Further, the P-Intended-Delegated-Identity header of Table 2 is mapped to the P-Preferred-Identity header of Table 1, and is an extension of the SIP header. The P-Intended-Delegated-Identity header is used to transmit the ID information of the delegating client from the UAC to the UAS in the legacy network and the IMS network. The transmitted delegating client ID is used as information for authenticating and authorizing the delegating client according to the SIP request from the associated delegated client to the system as in step 306 of FIG. 3.
When the delegated client sends a particular operation request to the associated target system, the ID of the delegating client is provided to the target system by including the header of Table 2 in a request message. After receiving the request message, the target system can authenticate and authorize not only the delegated client but also the delegating client when an associated operation is performed. Below are descriptions of examples when the delegated client sends operation requests, such as the XCAP request and the SIP request, to the target system in the present invention.
When the delegated client sends the XCAP request to the target system will now be described. An procedures in which the target system processes an associated operation in the XCAP request will be described with reference to FIGS. 3 and 4 when the delegated client is the XDMC and the XDMC sends the XCAP request to the XDMS.
The case where the underlying network is the legacy network will be described with reference to FIG. 4. The XDMC 410 includes its ID in the X-XCAP-Asserted-Identity header according to OMA XDM V1.0 Enabler. In accordance with the present invention, the XDMC 410 generates an XCAP request message in which an ID of the delegating client 400 is included in the X-XCAP-Intended-Delegated-Identity header and then sends the XCAP request message to an aggregation proxy server 422 coupled to the XDMS 424 corresponding to the target system. Further, when the underlying network is the IMS network, the XDMC 410 includes its ID in the X-3GPP-Intended-Identity header according to OMA XDM V1.0 Enabler. In accordance with the present invention, the XDMC 410 generates an XCAP request message in which the ID of the delegating client 400 is included in the X-3GPP-Intended-Delegated-Identity header, and then sends the XCAP request message to the aggregation proxy server 422 coupled to the XDMS 424 corresponding to the target system.
Then, when the underlying network is the legacy network, the aggregation proxy server 422 performs a process for authenticating the requesting client according to OMA XDM V1.0 Enabler using a requesting client ID included in the X-XCAP-Asserted-Identity header, i.e., an ID of the XDMC 410, as in step 301 of FIG. 3. If the authentication is successful, the aggregation proxy server 422 forwards the XCAP request message to the XDMS 424 corresponding to the target system. Further, when the underlying network is the IMS network, the aggregation proxy server 422 performs a process for authenticating the requesting client according to OMA XDM V1.0 Enabler using a requesting client ID included in the X-3GPP-Intended-Identity header, i.e., the ID of the XDMC 410, as in step 304 of FIG. 3. If the authentication is successful, the aggregation proxy server 422 forwards the XCAP request message to the XDMS 424 corresponding to the target system. If the X-3GPP-Intended-Identity header is not included in the request message received by the aggregation proxy server 422, the aggregation proxy server 422 adds in the request message the X-3GPP-Asserted-Identity header with the value set to the authenticated ID of the delegated client 410 after successful authentication of the delegated client 410, and then forwards the request message to the associated target XDMS 424 according to OMA XDM V1.0 Enabler.
Then, by observing in the forwarded XCAP request message the occurrence of the X-XCAP-Intended-Delegated-Identity header or the X-3GPP-Intended-Delegate d-Identity header, the XDMS 424 corresponding to the target system determines that the forwarded XCAP request is a delegated request as in step 303 of FIG. 3, and then authorizes the delegated client 410 and the delegating client 400 using the forwarded XCAP request message as in step 306 of FIG. 3. That is, the XDMS 424 examines whether the ID of the delegating client 400 included in the X-XCAP-Intended-Delegated-Identity header or the X-3GPP-Intended-Delegated-Identity header has the authority to perform the requested operation in the forwarded XCAP request message against the target resource. Further, the XDMS 424 examines whether the ID of the delegated client 410 included in the X-XCAP-Asserted-Identity header or the X-3GPP-Intended-Identity header has been delegated by the delegating client 400 with the authority to perform the requested operation in the forwarded XCAP request message. This delegation authorization can be performed by referring to a delegation rules predefined in the XDMS 424 or other place in the system, or by using the reactive delegation authorization.
When successfully authenticating and authorizing the delegating client 400 and the delegated client 410 as to the delegated operation request in the delegated XCAP request message, the XDMS 424 executes according to OMA XDM V1.0 Enabler the requested XCAP operation for the target resource, and then reports the execution results to the aggregation proxy server 422.
Then, the aggregation proxy server 422 forwards the received XCAP response message to the XDMC 410 corresponding to the delegated client according to OMA XDM V1.0 Enabler.
When the delegated client sends the SIP request to the target system will now be described. An procedures in which the target system processes an associated operation will be described with reference to FIGS. 3 and 5 when the delegated client is the UAC and the UAC sends the SIP request to the UAS.
The case where the underlying network is the legacy network or the IMS network will be described with reference to FIG. 5. The UAC 510 includes its ID in the P-Preferred-Identity header according to RFC 3325. The UAC 510 generates an SIP request message in which an ID of the delegating client 500 is included in the P-Intended-Delegated-Identity header and then sends the SIP request message to the target UAS 524 through an SIP proxy server 522 according to RFC 3261.
Then, when receiving the SIP request message, the SIP proxy server 522 for the target UAS 524 examines whether a requesting client is authentic using the ID of the delegated client, i.e., the UAC 510, included in the P-Preferred-Identity header according to RFC 3325. If the UAC 510 corresponding to the requesting client is successfully authenticated, the SIP proxy server 522 removes the P-Preferred-Identity header from the SIP request message according to RFC 3325, generates an SIP request message to which the P-Asserted-Identity header with an ID value of the authenticated requesting client has been added, and forwards the SIP request message to the target UAS 524 according to RFC 3261.
Then, by observing in the forwarded SIP request message the occurrence of the P-Intended-Delegated-Identity header, the target UAS 524 corresponding to the target system determines that the forwarded SIP request is a delegated request as in step 303 of FIG. 3, and then authorizes the delegated client 510 and the delegating client 500 using the forwarded SIP request message as in step 306 of FIG. 3. That is, for the authorization examination relating to the request, the UAS 524 examines whether the associated delegating client 500 whose ID is included in the P-Intended-Delegated-Identity has, the authority to perform the requested operation in the forwarded SIP request message according to a predefined policy. Further, for the authorization examination relating to the delegation, the UAS 524 examines whether the delegating client of the ID included in the P-Intended-Delegated-Identity header has delegated the authority to perform an associated SIP request, to the UAC 510 mapped to the delegated client ID included in the P-Asserted-Identity header. This delegation authorization can be performed by referring to a delegation rules predefined in the system, or by using the reactive delegation authorization.
When successfully authenticating and authorizing the delegating client 500 and the delegated client 510 as to the delegated operation request in the delegated SIP request message, the UAS 524 executes the requested SIP operation according to RFC 3261 and then reports the execution results to the SIP proxy server 522.
Then, the SIP proxy server 522 forwards the received SIP response message to the UAC 510 corresponding to the delegated client according to RFC 3261.
As is apparent from the above description, the present invention provides a new header in which ID information of a delegating client can be transmitted when a delegated client sends a particular operation request to a system. When the delegated client sends the particular operation request to the target system, the delegated client can transmit not only its own ID but also ID information of the delegating client in a request message.
Further, the target system can authenticate and authorize not only the delegated client but also the delegating client by referring to the delegating client ID and the delegated client ID included in the request message according to the particular operation request from the delegated client, thereby protecting the authority of the delegating client and effectively executing a requested operation.
Although preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions, and substitutions are possible, without departing from the scope of the present invention. Therefore, other possible embodiments and modifications without departing from the principle of the present invention may fall into the protected scope of the present invention.

Claims (12)

What is claimed is:
1. A server for performing a delegation operation, the server comprising:
a non-transitory memory; and
a processor configured for:
receiving, from a delegated client, a request message for requesting that the server should execute an operation for a resource, the request message including an identity (ID) of the delegated client, an ID of a delegating client, and information of the requested operation;
determining whether at least one authorization rule is stored in the memory based on the delegating client ID, the at least one authorization rule including information about the delegating client delegating which authority to which client;
when determining that the at least one authorization rule is stored in the memory, determining whether the delegating client has delegated authority to the delegated client for requesting execution of the operation based on the delegated client ID and the information about the delegating client delegating which authority to which client;
when determining that the at least one authorization rule is not stored in the memory, requesting, from the delegating client, the information about the delegating client delegating which authority to which client, and determining whether the delegating client has delegated authority to the delegated client for requesting the execution of the operation based on the delegated client ID and the information about the delegating client delegating which authority to which client; and
executing the requested operation when determining that the delegating client has delegated authority to the delegated client for requesting the execution of the operation,
wherein the execution of the operation comprises providing the delegated client with access to a document owned by the delegating client and stored on the server, and permitting the delegated client to modify the document, and
wherein the server reports the execution results to the delegated client.
2. The server of claim 1, wherein the request message comprises:
a first header including the delegated client ID; and
a second header including the delegating client ID.
3. The server of claim 1, wherein the server stores information indicating that the delegated client has been authenticated with respect to the request message when determining the delegating client has delegated authority to the delegated client for requesting the execution of the operation.
4. The server of claim 1, wherein the server is an Extensible Markup Language (XML) Document Management Server (XDMS).
5. A method for performing a delegation operation in a delegation operation system by a server, the method comprising the steps of:
receiving, from a delegated client, a request message including an identity (ID) of a delegated client, an ID of a delegating client, and information of a requested operation for requesting that the server execute the requested operation for a particular resource from the delegated client;
determining whether at least one authorization rule is stored in the server based on the delegating client ID, the at least one authorization rule including information about the delegating client delegating which authority to which client;
when the at least one authorization rule is stored in the server, determining whether the delegating client has delegated authority to the delegated client for requesting execution of the operation based on the delegated client ID and the information about the delegating client delegating which authority to which client;
when the at least one authorization rule is not stored in the server, requesting, from the delegating client, the information about the delegating client delegating which authority to which client, and determining whether the delegating client has delegated authority to the delegated client for requesting the execution of the operation based on the delegated client ID and the information about the delegating client delegating which authority to which client;
executing the requested operation when the delegated client is authenticated when determining the delegating client has delegated authority to the delegated client for requesting the execution of the operation; and
reporting the execution results to the delegated client;
wherein the execution of the operation comprises providing the delegated client with access to a document owned by the delegating client and stored on the server, and permitting the delegated client to modify the document.
6. The method of claim 5, wherein the request message comprises:
a first header including the delegated client ID; and
a second header including the delegating client ID.
7. The method of claim 5, wherein the server stores information indicating that the delegated client has been authenticated with respect to the request message when the determining delegating client has delegated authority to the delegated client for requesting the execution of the operation.
8. The method of claim 5, wherein the server is an Extensible Markup Language (XML) Document Management Server (XDMS).
9. The server of claim 1, wherein the server comprises:
a proxy server for authenticating the delegated client as a requesting client of the request message, and
a target system for authenticating the delegating client and the delegated client and executing the requested operation.
10. The server of claim 9, wherein the proxy server authenticates the delegated client as the requesting client of the request message and forwards the request message received from the delegated client to the target system, and the target system determines whether the delegating client has delegated authority to the delegated client.
11. The method of claim 5, wherein the server comprises:
a proxy server for authenticating the delegated client as a requesting client of the request message, and
a target system for authenticating the delegating client and the delegated client and executing the requested operation.
12. The method of claim 11, wherein the proxy server authenticates the delegated client as the requesting client of the request message and forwards the request message received from the delegated client to the target system, and the target system determines whether the delegating client has delegated authority to the delegated client.
US11/796,466 2006-04-28 2007-04-27 System and method for performing a delegation operation Active 2030-12-13 US9270771B2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR20060039051 2006-04-28
KR39051/2006 2006-04-28
KR10-2006-0039051 2006-04-28

Publications (2)

Publication Number Publication Date
US20070261106A1 US20070261106A1 (en) 2007-11-08
US9270771B2 true US9270771B2 (en) 2016-02-23

Family

ID=38655742

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/796,466 Active 2030-12-13 US9270771B2 (en) 2006-04-28 2007-04-27 System and method for performing a delegation operation

Country Status (3)

Country Link
US (1) US9270771B2 (en)
KR (1) KR101326403B1 (en)
WO (1) WO2007126272A1 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1863172B (en) * 2005-09-30 2010-08-25 华为技术有限公司 Method and system for issuing and presenting information
CN101321136B (en) * 2007-06-05 2012-08-08 华为技术有限公司 Transmission-receiving proxy method for conversation initial protocol message and corresponding processor
WO2011032577A1 (en) * 2009-09-15 2011-03-24 Nokia Siemens Networks Oy Methods and systems for delegating authorization
US20110314293A1 (en) * 2010-06-17 2011-12-22 Yu Chun-Ta Method of Handling a Server Delegation and Related Communication Device
US20120131168A1 (en) * 2010-11-22 2012-05-24 Telefonaktiebolaget L M Ericsson (Publ) Xdms for resource management in m2m
KR20150031225A (en) 2012-06-22 2015-03-23 엘지전자 주식회사 Method and device for enabling or disabling server in wireless communication system
KR20150020350A (en) * 2013-08-12 2015-02-26 삼성전자주식회사 Apparatus and method for delegating a multimedia content in communication system
CN110443054B (en) * 2019-08-07 2021-07-16 中国建设银行股份有限公司 System and method for transmitting data file on line

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5249291A (en) 1990-11-20 1993-09-28 International Business Machines Corporation Method and apparatus for consensual delegation of software command operations in a data processing system
US6584567B1 (en) 1999-06-30 2003-06-24 International Business Machines Corporation Dynamic connection to multiple origin servers in a transcoding proxy
US20040117370A1 (en) * 2002-12-12 2004-06-17 International Business Machines Corporation System and method for accessibility data maintenance and privilege authorization
WO2004080030A1 (en) 2003-03-06 2004-09-16 International Business Machines Corporation System and method for publish/subscribe messaging
US20050198380A1 (en) 2002-02-26 2005-09-08 Citrix Systems, Inc. A persistent and reliable session securely traversing network components using an encapsulating protocol
KR20060022092A (en) 2004-09-06 2006-03-09 주식회사 케이티프리텔 A communication method using a proxy server in an wireless mobile communication network
US20060225132A1 (en) * 2000-01-24 2006-10-05 Microsoft Corporation System and Method of Proxy Authentication in a Secured Network
US20070136475A1 (en) * 2005-12-09 2007-06-14 Arto Leppisaari Limiting access to network functions based on personal characteristics of the user
US20070234364A1 (en) * 2006-03-30 2007-10-04 Daniel Lipton Post-processing phase in a distributed computing system
US20070245414A1 (en) * 2006-04-14 2007-10-18 Microsoft Corporation Proxy Authentication and Indirect Certificate Chaining

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5249291A (en) 1990-11-20 1993-09-28 International Business Machines Corporation Method and apparatus for consensual delegation of software command operations in a data processing system
US6584567B1 (en) 1999-06-30 2003-06-24 International Business Machines Corporation Dynamic connection to multiple origin servers in a transcoding proxy
US20060225132A1 (en) * 2000-01-24 2006-10-05 Microsoft Corporation System and Method of Proxy Authentication in a Secured Network
US20050198380A1 (en) 2002-02-26 2005-09-08 Citrix Systems, Inc. A persistent and reliable session securely traversing network components using an encapsulating protocol
US20040117370A1 (en) * 2002-12-12 2004-06-17 International Business Machines Corporation System and method for accessibility data maintenance and privilege authorization
WO2004080030A1 (en) 2003-03-06 2004-09-16 International Business Machines Corporation System and method for publish/subscribe messaging
KR20060022092A (en) 2004-09-06 2006-03-09 주식회사 케이티프리텔 A communication method using a proxy server in an wireless mobile communication network
US20070136475A1 (en) * 2005-12-09 2007-06-14 Arto Leppisaari Limiting access to network functions based on personal characteristics of the user
US20070234364A1 (en) * 2006-03-30 2007-10-04 Daniel Lipton Post-processing phase in a distributed computing system
US20070245414A1 (en) * 2006-04-14 2007-10-18 Microsoft Corporation Proxy Authentication and Indirect Certificate Chaining

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Bootstrapping interface (Ub) and Network Application Function interface (Ua); Protocol Details (Release 6), 3GPP TS 24.109 V6.5.0, Dec. 2005.
Jennings et al., "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", Network Working Group, Nov. 2002.
Rosenberg et al., "SIP: Session Initiation Protocol", Network Working Group, Jun. 2002.
XML Document Management (XDM) Specification Candidate Version 1.0, Open Mobile Allicance OMA-TS-XDM-Core-V1-0-20060314-C, Mar. 14, 2006.

Also Published As

Publication number Publication date
KR20070106461A (en) 2007-11-01
US20070261106A1 (en) 2007-11-08
WO2007126272A1 (en) 2007-11-08
KR101326403B1 (en) 2013-11-20

Similar Documents

Publication Publication Date Title
US10785037B2 (en) Managing secure content in a content delivery network
EP3251324B1 (en) Secure access to cloud-based services
US9270771B2 (en) System and method for performing a delegation operation
US11012437B2 (en) Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials
US9866556B2 (en) Common internet file system proxy authentication of multiple servers
US8646057B2 (en) Authentication and authorization of user and access to network resources using openid
US9356928B2 (en) Mechanisms to use network session identifiers for software-as-a-service authentication
US9646309B2 (en) Method for authentication and assuring compliance of devices accessing external services
JP5714690B2 (en) Pluggable token provider model that enforces authentication across multiple web services
US8978100B2 (en) Policy-based authentication
US20100100950A1 (en) Context-based adaptive authentication for data and services access in a network
US8136144B2 (en) Apparatus and method for controlling communication through firewall, and computer program product
CN112367666B (en) Method, device and system for allowing pNF in 5G core network to pass NRF authentication cNF
CN112087412B (en) Service access processing method and device based on unique token
US8881241B2 (en) Method of and system for implementing privacy control
Damaggio Internet-Draft B. Raymor Intended status: Standards Track Microsoft Expires: September 7, 2015 March 6, 2015
Skvortsov et al. Backplane Identity Scenario
Saint-Andre Internet-Draft Cisco Systems, Inc. Obsoletes: 6122 (if approved) April 14, 2012 Intended status: Standards Track Expires: October 16, 2012

Legal Events

Date Code Title Description
AS Assignment

Owner name: SAMSUNG ELECTRONICS CO., LTD., KOREA, REPUBLIC OF

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OH, JAE-KWON;KIM, WUK;SUNG, SANG-KYUNG;REEL/FRAME:019274/0411

Effective date: 20070427

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8