The nature of a 3DStreamingToolkit deployment implies a complex authentication setup. This page captures the data needed to understand what components are in play, and how to configure them. It is based off of this issue. 🔐

Authentication Architecture Overview

Prework:

  1. Create an AAD Tenant
  2. Create an AAD B2C Application (used for client login)
  3. Create a Normal AAD Application (used for server login)
  4. Record tenant name and app id’s for use below
  5. (optional) setup TURN if you need to support advanced NAT traversal scenarios. We have an article about how we did this here
  6. (optional) record TURN postgres credential information

Setup Signaling Authentication:

This secures transmission of sdp messages, which are the session establishment messages. It’s how our clients find servers, and vice versa.

  1. deploy signaling to azure. This is simple, just click the deploy button.
  2. in App Settings set the following (note: these are defined in the readme):
    • AAD_TENANT_ID your aad tenant info. ex: 3dtoolkit.onmicrosoft.com
    • AAD_B2C_CLIENT_APPLICATION_ID your add client app id. ex: aacf1b7a-104c-4efe-9ca7-9f4916d6b66a
    • AAD_B2C_POLICY_NAME your aad b2c policy name. ex: b2c_1_signup
    • AAD_RENDERING_SERVER_APPLICATION_ID your aad server app id. ex: 5b4df04b-e3bb-4710-92ca-e875d38171b3

Setup Identity Management:

This secures TURN such that short lived temporary credentials are used, and further ensures that only AAD authenticated users can retrieve said credentials. If you aren’t using TURN in production, you don’t need this.

  1. deploy identity management to azure.
  2. in App Settings set the following:
    • PGUSER your TURN postgres username
    • PGDATABASE your TURN postgres database name
    • PGPASSWORD your TURN postgres password
    • PGHOST your TURN postgres hostname/fqdn
    • PGPORT your TURN postgres port
    • AAD_TENANT_ID your aad tenant info
    • AAD_B2C_CLIENT_APPLICATION_ID your add client app id
    • AAD_B2C_POLICY_NAME your aad b2c policy name
    • AAD_RENDERING_SERVER_APPLICATION_ID your aad server app id
    • AAD_B2C_CLIENT_APPLICATION_SECRET your aad client app secret
    • AAD_B2C_REDIRECT_URI your aad client app redirect uri (should be identity management service site with a specific path. ex: <siteName>.azurewebsites.net/device/login)

Setup OAuth24D:

This hands out credentials to clients, using short-lived device tokens and a user device to login. We have an article about how we did this, and why it exists here.

  1. modify app.js to use a real passportjs strategy, likely passport-azure-ad (no public example yet, see https://github.com/bengreenier/oauth24d/issues/2).
  2. deploy the modified oauth24d to azure.
  3. in App Settings set the following:
    • AUTH_URI the user facing authentication url (should be oauth24d service site with a specific path. ex: <siteName>.azurewebsites.net/login)
    • Optional settings exist, please see the readme for more info

Configuration:

See webrtcConfig for more info

For the client, we need to point it to the oauth24d service. This requires two urls in the authentication config section in webrtcConfig.json:

"authentication": {
    "codeUri": "<siteName>.azurewebsites.net/new",
    "pollUri": "<siteName>.azurewebsites.net/poll"
}

This tells the client to use the oauth24d authentication flow to direct a user to a uri to login, and give the application a token it can use to authenticate to the other services.

For the server, we need to point it to azure ad. This requires a few values in the authentication config section in webrtcConfig.json:

"authentication": {
    "authority": "<an oauth2 authority uri, tested against aadv1>",
    "resource": "<the oauth2 resource, commonly the same as clientId>",
    "clientId": "<the oauth2 authority application id>",
    "clientSecret": "<the oauth2 authority application secret>"
}

These are the same values as observed in setup above, with one caveat - authority maps to https://login.microsoftonline.com/<AAD_TENANT_ID>.onmicrosoft.com/oauth2/token. For instance, https://login.microsoftonline.com/3dtoolkit.onmicrosoft.com/oauth2/token. This tells the server to use client_credentials aad grant to get a token it can use to authenticate to other services.

Realtime data:

Realtime data channel messaging is encrypted using DTLS by default. Please note that if you’re using TURN, data will be decrypted on the TURN node, while it is handed off to the other peer (effectively exposing MITM potential on that node). Realtime video channel communications are encrypted using SRTP by default. You can learn more here.

Resources