5 The eXtensible Markup Language (XML) Configuration Access Protocol (XCAP)

24.4233GPPExtensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating NGN PSTN/ISDN Simulation ServicesPSTN/ISDN simulation servicesRelease 8TISPANTS

5.1 Introduction

For the purpose of manipulating data stored in an application server the XML Configuration Access Protocol (XCAP) [8] is used. XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub‑trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP [1]. XCAP uses the HTTP methods PUT, GET, and DELETE to operating on XML documents stored in the server.

In the case of PSTN/ISDN simulation services, the data stored in a server is related to the execution of that given service. The present document defines a new XCAP Application Usage for the purpose of allowing a client to manipulate data related to PSTN/ISDN simulation services.

XCAP [8] defines two logical roles: XCAP client and XCAP servers. An XCAP client is an HTTP/1.1 compliant client. Similarly an XCAP server is an HTTP/1.1 compliant server. The XCAP server acts as a repository of XML documents that customize and modify the execution of NGN PSTN/ISDN simulation services. Figure 3 depicts the XCAP architecture where an XCAP client sends an HTTP/1.1 request to an XCAP server. The server replies with an HTTP/1.1 response.

Figure 3: XCAP architecture

According to XCAP [8], each application that makes use of XCAP defines its own XCAP application usage. The present document defines an NGN PSTN/ISDN simulation services XCAP application usage in clause 6. This application usage defines the XML schema [2] for the data used by the application, along with other key pieces of information.

XCAP focuses on the definition of XML documents that are compliant with the XML schema and constrains defined for a particular XCAP application usage. XCAP allows application to provide XML documents that are common for all users or XML documents that affect the service of a given user.

Central to XCAP is the construction of the HTTP URI that points to particular XML document or certain components of it. A component in an XML document can be an XML element, attribute, or the value of it.

5.2 Functional entities

5.2.1 User Equipment (UE)

5.2.1.1 General

The UE implements the role of an XCAP client, as described in clause 5.3.1.

For systems where Generic Authentication Architecture [6] is used, the UE shall support the authentication mechanisms specified in 3GPP TS 33.222 [6] and 3GPP TS 24.109 [5].

For systems where Generic Authentication Architecture [6] is not used, the UE shall support RFC 2617 [3] and RFC 2246 [4] according to ETSI TS 183 038 [12].

On sending an HTTP request, the UE may indicate the user’s identity intended to be used with the AS by adding a HTTP X‑3GPP‑Intended‑Identity header (TS 124 109 [5]) to the outgoing HTTP request.

5.2.1.2 Subscription for notification of state changes in XML document

In order to keep the simulation services state synchronized with the network elements and other terminals that the user might be using, the UE should subscribe to changes in the XCAP simserv documents by generating a SUBSCRIBE request in accordance with RFC 5875 [11].

5.2.2 Authentication Proxy (AP)

5.2.2.1 Introduction

An Authentication Proxy is an HTTP/1.1 [1] compliant server whose main purpose is to authenticate the user requests. The Authentication Proxy is used to separate the authentication procedure and the Application Server (AS) specific application logic to different logical entities.

The AP is configured as a HTTP reverse proxy, i.e. the FQDN of the AS is configured to the AP such a way that the IP traffic intended to the AS is directed to the AP by the network. The AP performs the authentication of the UE. After the authentication procedure has been successfully completed, the AP assumes the typical role of a reverse proxy, i.e. the AP forwards HTTP requests originating from the UE to the correct AS, and returns the corresponding HTTP responses from the AS to the originating UE.

The AP allows authorized users to manipulate services when they are connected to an IMS network or when they are connected to a non‑IMS network (e.g. the public Internet). Authentication details can differ in both situations. Provisioning of credentials to authenticate the user is outside the scope of the present document. TS 187 003 [9] provides further architectural authentication details.

5.2.2.2 Authentication

On receiving an HTTP request, the AP shall first determine the mechanism used to authenticate the user. If the Generic Authentication Architecture [6] is used, the AP shall attempt to authenticate the user via the mechanisms specified in TS 133 222 [6] and the AP shall follow the procedures indicated in clause 5.2.2.2.1. For systems where Generic Authentication Architecture [6] is not used, the AP shall attempt to authenticate the user according to RFC 2617 [3] and ETSI TS 183 038 [12] provides guidelines for the Authentication Proxy.

5.2.2.2.1 Authentication based on the generic authentication architecture

On receiving an HTTP request that contains the Authorization header field, the AP shall:

  1. use the value of that username parameter of the Authorization header field to authenticate the user;
  2. apply the procedures specified in RFC 2617 [3] for authentication;
  3. if the HTTP request contains an X‑3GPP‑Intended‑Identity header field (TS 124 109 [5]), then the AP may verify that the user identity belongs to the subscriber. This verification of the user identity shall be performed dependant on the subscriber’s application specific or AP specific user security settings;
  4. if authentication is successful, remove the Authorization header field from the HTTP request;
  5. insert an HTTP X‑3GPP‑Asserted‑Identity header field (TS 124 109 [5]) that contains the asserted identity or a list of identities; and
  6. forward the HTTP request to the appropriate AS.

On receiving an HTTP response for the previous request, the AP shall:

  1. add an Authentication‑Info header field in accordance to the procedures described in TS 133 222 [6]; and
  2. forward the response to the XCAP client.

On receiving an HTTP request that does not contain the Authorization header field, the AP shall:

  1. challenge the user by generating a 401 Unauthorized response according to the procedures specified in TS 133 222 [6] and RFC 2617 [3]; and
  2. forward the 401 Unauthorized response to the sender of the HTTP request.
5.2.2.2.2 Void

5.2.2.3 Authorization

The AP shall be able to decide whether particular subscriber, i.e. the UE, is authorized to access a particular AS. On doing so, the AP may use the User Security Settings specified in TS 124 109 [5].

The AP may indicate an asserted identity or a list of identities to the AS by adding an HTTP X‑3GPP‑Asserted‑Identity header field to the HTTP requests prior to forwarding the request to the AS. In case of multiple identities, they shall be separated by comma (,) and each identity shall be surrounded by quotation marks ("). Whether the AP supports this handling of an asserted identity or a list of identities then it shall depend on local policy in the AP. In addition the subscriber’s application specific or AP specific user security settings may be considered.

The AP may indicate an authorization flag or a list of authorization flags from the application specific user security settings (USS) to the AS by adding a HTTP X‑3GPP‑Authorization‑Flags header field to the HTTP request prior to forward it to the XCAP server. The HTTP X‑3GPP‑Authorization‑Flags header field shall contain a list of authorization flags separated by comma (,) and each authorization flag is surrounded by quotation marks ("). In case the AP supports this handling of authorization flags from USS then it shall depend on local policy in the AP.

5.2.3 Application Server (AS)

5.2.3.1 General

An Application Server implements the role of an XCAP server as described in clause 5.3.2.

For systems where Generic Authentication Architecture [6] is used, the AS shall support the authentication mechanisms specified in 3GPP TS 33.222 [6] and 3GPP TS 24.109 [5].

For systems where Generic Authentication Architecture [6] is not used, the AS shall support RFC 2617 [3] and RFC 2246 [4] according to ETSI TS 183 038 [12].

5.2.3.2 Authentication and authorization

If an Authentication Proxy (AP) is provided in the path of the HTTP request, then the AS receives an HTTP request from a trusted source (the AP) and contains an HTTP X‑3GPP‑Asserted‑Identity header (TS 124 109 [5]) that includes an asserted identity of the user. In this case the AS does not need to authenticate the user, but just provide authorization to access the requested resource.

If an HTTP X‑3GPP‑Asserted‑Identity header (TS 124 109 [5]) is not present in the HTTP request or if the request is received from a non‑trusted source, then the AS needs to authenticate the user prior to providing authorization to the XCAP resource by applying the procedures of authentication mechanisms specified in 3GPP TS 33.222 [6] and 3GPP TS 24.109 [5] in case Generic Authentication Architecture is supported, or as described in clause 5.2.3.2.1 otherwise.

5.2.3.2.1 HTTP digest authentication

On receiving an HTTP request that does not contain an Authorization header the AS shall:

  1. challenge the user by generating a 401 Unauthorized response that contains the proper Digest authentication parameters (e.g. realm), according to RFC 2617 [3]. Provisioning of credentials to authenticate the user is outside the scope of the present document; and
  2. forward the 401 Unauthorized response to the sender of the HTTP request.

On receiving an HTTP request that contains an Authorization header, the AS shall:

  1. apply the authentication procedures defined in RFC 2617 [3]; and
  2. authorize or deny authorization depending on the authenticated identity.

5.2.3.3 Subscription acceptance and notification of state changes in XML document

When the AS receives a SUBSCRIBE request having the Event header field value set to "xcap-diff", the AS shall first authenticate the source of the SUBSCRIBE request and then perform authorization. Afterwards, the AS shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 5875 [11].

5.3 Roles

5.3.1 XCAP client

5.3.1.1 Introduction

The XCAP client is a logical function as defined in draft-ietf-simple-xcap-08.txt [8]. The XCAP client provides the means to manipulate the general data, such as configuration settings related to NGN PSTN/ISDN simulation services.

The UE implementing the role of an XCAP client can be provisioned with an XCAP Root URI as specified in Appendix C in OMA-TS-XDM_Core-V1_1-20080627-A [14] or can be preconfigured with an XCAP Root URI.

NOTE 1: Additional discovery mechanisms for the XCAP Root URI are outside the scope of the present document.

NOTE 2: In order to be able to manipulate XCAP resources stored on the XCAP server, the XCAP client needs to know the user’s directory name. It is assumed that this value is pre‑provisioned or the UE uses some means to discover it. Discovery mechanisms are outside the scope of the present document.

5.3.1.2 Manipulating NGN PSTN/ISDN simulation services

When the XCAP client intends to manipulate a resource list, it shall generate an HTTP PUT, HTTP GET or
HTTP DELETE request in accordance with draft-ietf-simple-xcap-08.txt [8] and the NGN PSTN/ISDN simulation services application usage specified in clause 6.

5.3.2 XCAP server

5.3.2.1 Introduction

The XCAP server is a logical function as defined in draft-ietf-simple-xcap-08.txt [8]. The XCAP server can store data related to the configuration of NGN PSTN/ISDN simulation services. The XCAP server shall provide or deny authorization to access XCAP resources by authenticated users.

5.3.2.2 Manipulation acceptance

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching a resource list, the XCAP server shall first authenticate the request and then perform authorization. Clause 5.2.2 provides more details on the authentication and authorization of HTTP requests.

Afterwards the XCAP server shall perform the requested action and generate a response in accordance with
draft-ietf-simple-xcap-08.txt [8] and the NGN PSTN/ISDN simulation services application usage specified in clause 6.