7 Authentication Proxy

24.1093GPPBootstrapping interface (Ub) and network application function interface (Ua)Protocol detailsRelease 17TS

7.1 Introduction

The use of authentication proxy (AP) is specified in 3GPP TS 33.222 [5]. The AP in GAA is used to separate the GAA specific 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 GAA authentication of the UE. After the GAA 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.

7.2 Authentication

The authentication of the UE shall be based on GAA as specified in clause 5.

The AP shall remove the "Authorization" header from the HTTP requests that are forwarded from the UE to the AS. The AP shall add the "Authentication-Info" header to the HTTP responses that are forwarded to the UE from the AS.

The UE may indicate the user identity intended to be used with the AS by adding a HTTP header to the outgoing HTTP requests. The HTTP header name shall be "X-3GPP-Intended-Identity" and it shall contain the user identity surrounded by quotation marks ("). If the HTTP header has been added, the AP may verify that the user identity belongs to the subscriber. In case the AP supports this check of the user identity then it shall be performed dependant on the subscriber’s application specific or AP specific user security settings.

7.3 Authorization

The AP shall be able to decide whether particular subscriber, i.e. the UE, is authorized to access a particular AS. The granularity of the authorization procedures is specified in 3GPP TS 33.222 [5].

The AP may indicate an asserted identity or a list of identities to the AS by adding a HTTP header to the HTTP requests coming from the UE and forwarded to the AS. The HTTP header name shall be "X-3GPP-Asserted-Identity" and it shall contain a list of identities separated by comma (,) and each identity is 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 header to the HTTP requests coming from the UE and forwarded to the AS. The HTTP header name shall be "X-3GPP-Authorization-Flags" and it 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.

Annex A (informative):
Signalling flows of bootstrapping procedure