[QUESTION] Run KVS WebRTC using CredentialProvider

[Lionel223]

We intend to use a CredentialProvider with KVS WebRTC. Upon reviewing the documentation, we found that the createLwsIotCredentialProvider function can be utilized.

createLwsIotCredentialProvider(
            "xxxxxxxxxxxxx.credentials.iot.us-west-2.amazonaws.com",  // IoT credentials endpoint
            "/Users/username/Downloads/iot-signaling/certificate.pem",  // path to iot certificate
            "/Users/username/Downloads/iot-signaling/private.pem.key", // path to iot private key
            "/Users/username/Downloads/iot-signaling/cacert.pem", // path to CA cert
            "KinesisVideoSignalingCameraIoTRoleAlias", // IoT role alias
            channelName, // iot thing name, recommended to be same as your channel name
            &pSampleConfiguration->pCredentialProvider));

freeIotCredentialProvider(&pSampleConfiguration->pCredentialProvider);

While using the path to obtain the IoT certificate and private key works fine, our current situation prevents us from obtaining the file paths for the IoT certificate and private key, we can only retrieve the string of the certificate and private key, and furthermore, we want to avoid writing out the key in a text file. After examining the source code, it appears that the relevant CredentialProvider functions only accept file paths for the certificate and private key. In this context, is there a solution to address our scenario?

[disa6302]

@Lionel223 ,

We do have an implementation that allows passing in the file contents directly. The file paths get set as part of the LWS library we depend on, so we do not have control over this. While setting up IoT, the certs get downloaded as files automatically, so I am wondering how you can directly get the string.

[Lionel223]

@disa6302 ,

We use AWS IoT Fleet Provision to obtain certificates, and according to the documentation (Device provisioning MQTT API - AWS IoT Core), we receive strings for privateKey and certificatePem. These strings are then stored in the TrustZone. When needed, we use an API to extract the relevant strings.

Currently, our workaround involves implementing CredentialProvider where we convert the certificate into accessKeyId, secretAccessKey, and sessionToken. We then execute the createStaticCredentialProvider function. However, this approach requires us to handle the expiration mechanism ourselves.