Authorization Service isn't an OAuth Server. It's "just" an identity management glue between OAuth Server which usually companies host on their own. By Identity Management I mean component which links device to a user. This has nothing to do with an OAuth Server.
So in your case, Auth0 is an OAuth 2.0 Server with user management while this plgd authorization server is what links device to user entities managed by Auth0.
In the real production, there is no place for authorization service. It's just an example integration. In real production, authorization contracts shall be implemented by your identity management service, as user wants to manage his devices, share devices with other users and so on.
Okay, so the first group have devices based on the IoTivity-Lite - or this is what they will try to integrate? Integrate IoTivity-Lite and connect it to the cloud?
Second group want to "retrieve" devices from the plgd cloud testing instance over C2C or they want to "mirror" their devices to plgd cloud testing instance.
I have an issue making the cloud_server (from iotivity-lite project) works with plgd-dev cloud in secure mode.
Here is how I make this work with the UNSECURE configuration:
# Start UNSECURE cloud docker pull plgd/bundle:vnext docker container stop cloud ; docker container rm cloud ; \ docker run -d --network=host --name=cloud -t plgd/bundle:vnext \ -e COAP_GATEWAY_CLOUD_ID="00000000-0000-0000-0000-000000000001" \ -e COAP_GATEWAY_UNSECURE_PORT="5683" \ -e COAP_GATEWAY_UNSECURE_ADDRESS="0.0.0.0:5683" \ -e "coap+tcp://127.0.0.1:5683" && \ docker logs --follow cloud # Start unsecure device server git clone https://github.com/iotivity/iotivity-lite cd iotivity-lite/port/linux CLOUD=1 SECURE=0 make cloud_server ./cloud_server "cloud_server" "test" "coap+tcp://127.0.0.1:5683" "00000000-0000-0000-0000-000000000001" "test"
I get the following output from cloud_server:
Cloud Manager Status: -Registered -Token Expiry: 3599 Cloud Manager Status: -Registered -Token Expiry: 3599 -Logged In get_handler: get_handler:
But according to bundle/README.md, when it comes to secured device, the documentation says that the device must be owned, but I cannot discover the cloud_server device using onboarding_tool so, what am I supposed to do to own the cloud_server device?
It also says that Cloud CA must be set as TRUST CA with subject COAP_GATEWAY_CLOUD_ID in device. I don't know how I can achieve that, because I don't know what is the "Cloud CA" (I suppose it is stored within the container in /data/certs/) and how I should set it as TRUST CA.
Here is what I tried:
# Start SECURE cloud docker pull plgd/bundle:vnext docker container stop cloud ; docker container rm cloud ; \ docker run -d --network=host --name=cloud -t plgd/bundle:vnext \ -e COAP_GATEWAY_CLOUD_ID="00000000-0000-0000-0000-000000000001" \ -e COAP_GATEWAY_PORT="5684" \ -e COAP_GATEWAY_ADDRESS="0.0.0.0:5684" \ -e "coaps+tcp://127.0.0.1:5684" && \ docker logs --follow cloud git clone https://github.com/iotivity/iotivity-lite cd iotivity-lite/port/linux CLOUD=1 SECURE=1 PKI=1 make cloud_server docker exec -it cloud cat /data/certs/root_ca.crt > ./pki_certs/cloudca.pem ./cloud_server "cloud_server" "test" "coaps+tcp://127.0.0.1:5684" "00000000-0000-0000-0000-000000000001" "test"
And I get no output from cloud_server, it does not seems that the device fetch the cloud.
Please note that I am able to run the secured cloud_server device using "cloud-test".
Could you please help? Could you please elaborate the documentation to get me started with plgd-dev cloud using iotivity-lite cloud_server samples?
Thanks in advance,
@Ondrej, No, when I use the cloud_server tool provided by iotivity-lite project built with SECURE=0, I am not able to discover it with the iotivity-lite CLI onboarding_tool.
However, I am able to onboard cloud_server when built with CLOUD=1 SECURE=1 PKI=1, I though that onboarding_tool didn't work at all but it actually does work with secure cloud_server.
@Jozef, I am surpised that cloud_server works only for unsecure device, because I can make it work by applying the patch found at
./device-simulator/patches/devsim.diff, then build it with CLOUD=1 SECURE=1 PKI=1 (in the same way as in device-simulator), then it works fine with:
docker run \ --network=other \ -v $(pwd)/.tmp/certs:/certs \ -v $(pwd)/.tmp/home:/home \ --user $(id -u):$(id -g) \ -e HOME=/home \ -e DIAL_TYPE="file" \ -e DIAL_FILE_CA_POOL=/certs/root_ca.crt \ -e DIAL_FILE_CERT_DIR_PATH=/certs \ -e DIAL_FILE_CERT_NAME=http.crt \ -e DIAL_FILE_CERT_KEY_NAME=http.key \ -e LISTEN_TYPE="file" \ -e LISTEN_FILE_CA_POOL=/certs/root_ca.crt \ -e LISTEN_FILE_CERT_DIR_PATH=/certs \ -e LISTEN_FILE_CERT_NAME=http.crt \ -e LISTEN_FILE_CERT_KEY_NAME=http.key \ -e TEST_COAP_GW_OVERWRITE_LISTEN_FILE_CERT_NAME=coap.crt \ -e TEST_COAP_GW_OVERWRITE_LISTEN_FILE_KEY_NAME=coap.key \ -e TEST_CLOUD_SID=adebc667-1f2b-41e3-bf5c-6d6eabc68cc6 \ -e TEST_ROOT_CA_CRT=/certs/root_ca.crt \ -e TEST_ROOT_CA_KEY=/certs/root_ca.key \ -e ACME_DB_DIR=/home/certificate-authority \ cloud-test \ go test -mod=mod -race -p 1 -v ./... -covermode=atomic -coverprofile=/home/coverage.txt
Also, now that I know that onboarding_tool works, I can onboard and provision the device accordingly to https://github.com/iotivity/iotivity-lite#step-1-onboard-and-provision-the-server, then I retrieve the SECURE cloud certificate with
docker exec -it cloud cat /data/certs/root_ca.crt, then I feed the device with this cert using onboarding_tool
 Install new manufacturer trust anchor command. I see some progress, the device now displays a failure status code instead of nothing:
./cloud_server "cloud_server" "test" "coaps+tcp://127.0.0.1:5684" "00000000-0000-0000-0000-000000000001" "test" device_name: cloud_server auth_code: test cis : coaps+tcp://127.0.0.1:5684 sid: 00000000-0000-0000-0000-000000000001 apn: test Cloud Manager Status: -Failure
Am I doing it right? Did I actually "ACL for Cloud" with this previous steps? How can I configure cloud resources?
If cloud_server works only for unsecure device, which tool should I use?
Thank you both for your support
go test -mod=mod -race -p 1 -v ./... -covermode=atomic -coverprofile=/home/coverage.txtruns test's over the cloud and it uses OBT created at https://github.com/plgd-dev/cloud/blob/94017c96d583b787592fad384051921f07f1c1de/test/sdkclient.go#L42 and own the device over manufacturer ownership transfer method (https://openconnectivity.org/specs/OCF_Security_Specification_v2.2.0.pdf 7.3.6 - the patch ./device-simulator/patches/devsim.diff just set's manufacturer certificate and CA) at https://github.com/plgd-dev/cloud/blob/master/test/test.go#L221 and provides ACLs https://github.com/plgd-dev/cloud/blob/94017c96d583b787592fad384051921f07f1c1de/test/test.go#L224. CA was not set, because identity CA (configured during own) is same as cloud CA. In near future we want to provide mobile app for IOS/Android which discover the secure device, and onboard it to the bundle/portal.try.plgd.cloud.
You need to set
/data/certs/root_ca.crt as trust anchor. The manufacturer trust anchor is used during ownership transfer method. For ACLs I'm not sure how to setup it via
https://github.com/iotivity/iotivity-lite#step-1-onboard-and-provision-the-server - i used our sdk for that https://github.com/plgd-dev/sdk/tree/master/local
docker exec -it cloud cat /data/certs/root_ca.crt > ./pki_certs/cloudca.pem
./cloud_server "cloud_server" "test" "coaps+tcp://127.0.0.1:5684" "00000000-0000-0000-0000-000000000001" "test"
and then onboarding_tool:
 Discover un-owned devices
 Just-Works Ownership Transfer Method
 Provision ACE2 (to set ACLs wildcart for subjectid 00000000-0000-0000-0000-000000000001 with full access)