6 Authentication procedures

24.4823GPPMission Critical Services (MCS) identity managementProtocol specificationRelease 17TS

6.1 General

6.2 Identity management client procedures

6.2.1 User authentication

Upon an indication from the MC service client to initiate MC service user authentication, the IdM client shall perform the user authentication procedure according to 3GPP TS 33.180 [17] with the following clarifications:

1) shall establish a TLS tunnel to the authorisation endpoint of the IdM server as specified in 3GPP TS 33.180 [17] using the configured URL of the authorisation endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSAuthEndpoint" leaf node defined in 3GPP TS 24.483 [11] and the clarifications in annex A;

2) shall generate an OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP GET request method according to IETF RFC 7231 [24];

b) shall include the configured parameter IdM client id as the client_id parameter specified in 3GPP TS 33.180 [17] in the query component of the authorization endpoint’s URI using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and

NOTE 1: The configuration of client_id is specified in 3GPP TS 24.483 [11].

c) shall include the remaining required parameters as specified in 3GPP TS 33.180 [17] in the query component of the authorization endpoint’s URI using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and

3) shall send the HTTP GET request method towards the IdM server.

NOTE 2: The OpenID Connect 1.0 [6] specification allows for an alternative mechanism for sending the OIDC Authentication request message using an HTTP POST request method which can be used in place of steps 1, 2, and 3 above.

Upon receipt of an HTTP 200 (OK) response from the IdM server, the IdM client:

1) shall prompt the MC service user for their username and password;

NOTE 3: Other types of authentication are supported and are not defined by the OIDC specifications. 3GPP TS 33.180 [17] has defined username and password as a mandatory authentication method to be supported, hence a procedure to realize that method is included here.

2) shall generate an HTTP POST request method containing the MC service user’s username and password; and

3) shall send the HTTP POST request method towards the IdM server.

Upon receipt of an OIDC Authentication Response message, the IdM client:

1) shall establish a TLS tunnel to the token endpoint of the IdM server as specified in 3GPP TS 33.180 [17] using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node defined in 3GPP TS 24.483 [11] and the clarifications in annex A;

2) shall generate an OIDC Token Request message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP POST request method according to IETF RFC 7231 [24]; and

b) shall include the grant_type parameter set to a value of "authorization_code" and the other required parameters in the entity body of the HTTP POST request method using the using the "application/x-www-form-urlencoded" format as specified in 3GPP TS 33.180 [17]; and

3) shall send the HTTP POST request method towards the IdM server.

Upon receipt of an OIDC Token Response message, the IdM client:

1) shall validate the id_token, access_token and refresh token in the received OIDC Token Response message as specified in the OpenID Connect 1.0 [6] specification; and

2) shall provide the id_token and access_token in the received OIDC Token Response message to the MC service client.

NOTE 4: The method in which the IdM client provides the id_token and access_token to the MC service client is implementation specific.

The MC UE may repeat the entire procedure in this subclause as needed to obtain the necessary authorisation tokens for the MC service clients, depending on the scope parameter in the Authentication Request message as specified in 3GPP TS 33.180 [17].

6.2.2 Token exchange procedure

Upon an indication from the MC service client to acquire a security token for authentication of the MC service user with a partner IdM server, the IdM client:

1) shall establish a TLS tunnel to the token endpoint of the home IdM server as specified in 3GPP TS 33.180 [17] using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node of the MCS UE initial configuration MO defined in 3GPP TS 24.483 [11] and the clarifications in annex A;

2) shall generate a Token Exchange Request message as specified in 3GPP TS 33.180 [17] and IETF RFC 8693 [18] with the following clarifications:

a) shall generate an HTTP POST request method according to IETF RFC 7231 [24];

b) shall include the following parameters in the in the entity body of the HTTP POST request method using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]:

i) the grant_type parameter set to a value of "urn:ietf:params:oauth:grant-type:token-exchange" as specified in subclause B.7.2 of 3GPP TS 33.180 [17]; and

ii) the other required parameters as specified in subclause B.7.2 of 3GPP TS 33.180 [17]; and

3) shall send the HTTP POST request method towards the IdM server.

Upon receipt of a Token Exchange Response message as specified in 3GPP TS 33.180 [17] and IETF RFC 8693 [18], the IdM client:

1) shall extract the security token contained in the access_token parameter of the received Token Exchange Response message; and

2) shall temporarily store the extracted security token.

NOTE 1: The security token can be used by the procedures of subclause 6.2.3 to obtain access tokens from the partner systems indicated by the resource parameter included in the Token Exchange Request message for access to the resources of that partner system.

NOTE 2: The security token only needs to be stored until it’s lifetime has expired or until it is replaced by a newly acquired security token.

6.2.3 Token request to a partner system IdM server

Upon an indication from the MC service client to acquire an access token from a partner IdM server to authorise the MC service user to access the resources of a partner system, the IdM client:

1) shall obtain a valid security token appropriate for inclusion in a Token Request message to be sent to the targeted partner IdM server by the procedures specified in subclause 6.2.2 if the IdM client has not already done so; and

2) shall generate a Token Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall establish a TLS tunnel to the configured URL of the token endpoint of the partner system IdM server as specified in the MC service user profile MO with the following clarifications:

i) for MCPTT, use the token endpoint defined in the "/<x>/<x>/OnNetwork/GroupServerInfo/IDMSTokenEndpointList/<x>/Entry/IDMSTokenID" leaf node as defined in the MCPTT service user profile MO 3GPP TS 24.483 [11];

ii) for MCData, use the token endpoint defined in the "/<x>/<x>/OnNetwork/MCDataGroupList/<x>/Entry/IdMSTokenEndPointList/<x>/IdMSTokenEndPoint" leaf node as defined in the MCData service user profile MO 3GPP TS 24.483 [11]; and

iii) for MCVideo, use the token endpoint defined in the "/<x>/<x>/OnNetwork/MCVideoGroupList/<x>/Entry/IdMSTokenEndPointList/<x>/IdMSTokenEndPoint" leaf node as defined in the MCVideo service user profile MO 3GPP TS 24.483 [11];

NOTE 1: The specific IDM token endpoint can be found by finding the server information for a particular MC service group.

NOTE 2: The specific IDM token endpoint can also be found in the respective MC service user profile document (see 3GPP TS 24.483 [11]) in the parameters corresponding to those identified in steps i), ii) and iii) above.

b) shall generate an HTTP POST request method according to IETF RFC 7231 [24] including in the entity body the following parameters using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]:

i) the grant_type parameter set to value of "urn:ietf:params:oauth:grant-type:jwt-bearer" as specified in subclause B.7.4 of 3GPP TS 33.180 [17] and IETF RFC [19]; and

ii) all other required parameters specified in subclause B.7.4 of 3GPP TS 33.180 [17]; and

c) shall send the HTTP POST request method towards the token endpoint of the partner system IdM server.

6.3 Identity management server procedures

6.3.1 User authentication

Upon receipt of an OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5] via a secure TLS tunnel between the identity management client and the authorisation endpoint of the IdM server, the IdM server:

1) shall validate the received OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5];

2) shall generate an HTTP 200 (OK) response according to IETF RFC 7231 [24] including form data to prompt the MC service user for their username and password credentials; and

NOTE 1: The username will be the MC service user’s MC ID.

3) shall send the HTTP 200 (OK) response towards the IdM client.

Upon receipt of an HTTP POST request method from the IdM client containing the MC service user’s username and password, the IdM server authenticates the MC service user and:

NOTE 2: Other methods of authentication can be used by the MC service provider and are not defined by the OIDC specifications. 3GPP TS 33.180 [17] has defined username and password as a mandatory authentication method to be supported for MC services, hence a procedure to realize that method is included here.

1) shall generate an OIDC Authentication Response message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP 302 (FOUND) response according to IETF RFC 7231 [24]; and

b) shall include the required parameters including the authorization_code as specified in 3GPP TS 33.180 [17] in the query component of the redirection URI contained in the Location header field of the HTTP FOUND request method using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and

2) shall send the HTTP 302 (FOUND) response towards the IdM client.

Upon receipt of an OIDC Token Request message via a secure TLS tunnel established between the identity management client and the token endpoint of the IdM server, the IdM server:

1) shall validate the OIDC Token Request message and if valid shall generate an OIDC Token Response message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP 200 (OK) response according to IETF RFC 7231 [24];

b) shall based on the received MC ID obtained from the received user authentication credentials, determine the MC service ID of the MC service user;

c) shall include an id_token, access_token and refresh_token and MC service ID as specified in 3GPP TS 33.180 [17]; and

d) shall include the other required parameters as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5]; and

2) shall send the HTTP 200 (OK) response towards the IdM client.

6.3.2 Token exchange procedure

Upon receipt of a Token Exchange Request message as specified in IETF RFC 8693 [18] via a secure TLS tunnel between the identity management client and the token endpoint of the IdM server, the IdM server:

1) shall validate the received Token Exchange Request message as specified in IETF RFC 8693 [18];

2) shall generate a Token Exchange Response message as specified in IETF RFC 8693 [18] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP 200 (OK) response to the received Token Exchange Request message according to IETF RFC 7231 [24]; and

b) include the parameters specified in subclause B.7.3 of 3GPP TS 33.180 [17] serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 8693 [18] and IETF RFC 7159 [20] with the following clarification:

i) include the parameters specified in subclause B.8 of 3GPP TS 33.180 [17] in the security token included in the access_token parameter specified in subclause B.7.3 of 3GPP TS 33.180 [17]; and

3) shall send the HTTP 200 (OK) response towards the IdM client.

6.3.3 Token request from an IdM client to a partner system

Upon receipt of an OIDC Token Request message via a secure TLS tunnel established between the identity management client and the token endpoint of the IdM server, the IdM server:

1) shall validate the Token Request message and the included security token as specified in subclause B.11.3 of 3GPP TS 33.180 [17] and if valid shall generate a Token Response message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

NOTE: The access token referred to in step 1) is the security token provided by the home IdM server by the procedures of subclause 6.3.2.

a) shall generate an HTTP 200 (OK) response according to IETF RFC 7231 [24];

b) shall include an id_token, access_token and refresh_token and MCPTT ID as specified in 3GPP TS 33.180 [17]; and

c) shall include the other required parameters as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5]; and

2) shall send the HTTP 200 (OK) response towards the IdM client.