A.3 Signalling flows for registration
24.3713GPPProtocol specificationRelease 17Stage 3TSWeb Real-Time Communications (WebRTC) access to the IP Multimedia (IM) Core Network (CN) subsystem (IMS)
A.3.1 Void
A.3.2 WIC registration of individual public user identity based on web authentication
Figure A.3.2-1 shows the registration signalling flow for the scenario when the user has a subscription with an individual public user identity, but uses a web identity and authentication scheme, e.g. OAuth 2.0, to authenticate with the WWSF or the WAF.
Figure A.3.2-1: WIC registration of individual public user identity based on web authentication
1. Download WIC and obtain access token
The user accesses a WebRTC URI to the WWSF. The browser downloads and initializes the WIC from the WWSF. The WAF or WWSF, depending on the authorization flow (e.g. OAuth 2.0) used, authenticates the user via "web credentials", i.e. credentials as commonly used for access to web based services, for example a username and password. The user’s web identity is mapped to the corresponding IMS subscriber identity (i.e. private user identity and public user identity). The WWSF forwards the access token and the IMS identity to the WIC.
2. Establishment of secure connection between WIC and eP-CSCF
The WIC opens a WSS (secure Web Socket) connection to the eP-CSCF. The TLS connection provides one-way authentication of the server based on the server certificate.
3. REGISTER request (WebRTC IMS Client to eP-CSCF)
The WebRTC IMS Client sends a REGISTER request to eP-CSCF. The REGISTER request includes an Authorization header field with the Bearer scheme containing the access token, which the WebRTC IMS Client has previously obtained.
Table A.3.2-1: Authorization header field in the REGISTER request (WIC to eP-CSCF)
Authorization: Bearer access_token="O91G451HZ0V83opz6udiSEjchPynd2Ss9……"
Authorization: It carries the authorization token previously obtained from WWSF/WAF in the web authentication procedure, and the type of the authorization token (i.e. "Bearer" OAuth access token type (defined in RFC 6750 [10]) in this example).
4. Validation of security token at eP-CSCF
The eP-CSCF extracts from the Authorization header field the access token and validates it in some unspecified manner ensuring that only an authorized source can have the generated access token. If the access token is valid the eP-CSCF obtains the associated authorization information, including the private user identity and public user identity of the associated user, the WWSF identity, and the access token scope.
5. REGISTER request (eP-CSCF to S-CSCF)
The eP-CSCF proceeds if the previous step has provided it with private user identity and public user identity(s) of the user requesting registration, an assurance that the user is authorised to use this private user identity and public user identity, and an identity of the WWSF and WAF. Then, the eP-CSCF generates an Authorization header field and forwards the request to the S-CSCF (via the I-CSCF).
Table A.3.2-2: Authorization header field in the REGISTER request (eP-CSCF to I/S-CSCF)
Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:registrar.home1.net", response="", integrity-protected="auth-done"
Authorization: It contains the user’s private user identity, an "integrity-protected" header field set to "auth-done ", and an empty "response" header field.
6. S-CSCF Registration
Based on the presence of the "integrity-protected" directive set to indicate that authentication has already been performed, the S-CSCF knows that user’s authorization has already been validated by the Trusted Node. The S-CSCF informs the HSS that the user has been registered. Upon being requested by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF. If the S-CSCF receives the identity of the WAF in the Authorization header field, the S-CSCF shall further checks whether the identity of the authorization entity received from the eP-CSCF, if any, is not barred, as described in 3GPP TS 33.203 [9] Annex U.
7. 200 (OK) response (S-CSCF to eP-CSCF)
The S-CSCF sends a 200 (OK) response to the eP-CSCF (via I-CSCF) indicating that Registration was successful.
When TLS is used between WIC and eP-CSCF, then, similar to the registration procedure for SIP Digest with TLS, the eP-CSCF associates the private user identity and all successfully registered public user identitis with the TLS Session ID when the 200 (OK) is received.
8. 200 (OK) response (eP-CSCF to UE)
The eP-CSCF forwards the 200 (OK) response to the WebRTC IMS Client indicating that Registration was successful.