How can I understand something from hashicorp vault audit? - security

I'm trying to get familiar with Hashicorp Vault and I don't understand how to use its audit log?
For example, let's say, one of the admins was compromised and somebody with root-token created another one root-token. I'm getting an audit log like this:
{
"time": "2019-08-17T21:53:07.625384189Z",
"type": "request",
"auth": {
"client_token": "hmac-sha256:0c97855631748ce0a775e3efc79fc607b0d2f61ddeb78b15e915a5087013fb5b",
"accessor": "hmac-sha256:c081cc37603419f02e67fb93f2f1362aa0eb37fa42635606cc51b9b7ed1ed561",
"display_name": "root",
"policies": [
"root"
],
"token_policies": [
"root"
],
"token_type": "service"
},
"request": {
"id": "f8b0f707-7e38-1410-4173-235ff9e250b6",
"operation": "update",
"client_token": "hmac-sha256:0c97855631748ce0a775e3efc79fc607b0d2f61ddeb78b15e915a5087013fb5b",
"client_token_accessor": "hmac-sha256:c081cc37603419f02e67fb93f2f1362aa0eb37fa42635606cc51b9b7ed1ed561",
"namespace": {
"id": "root"
},
"path": "auth/token/create",
"data": {
"display_name": "hmac-sha256:0f235cb7061e26e25b346c787a036860e247e0e32181b8adf13850812a27a9f1",
"entity_alias": "hmac-sha256:0f235cb7061e26e25b346c787a036860e247e0e32181b8adf13850812a27a9f1",
"explicit_max_ttl": "hmac-sha256:3cf83aa363c8f73a7e23ccd56baa8f4e1119bc15800030f663f2d07c5420ce91",
"num_uses": "hmac-sha256:943213e389eae841e8d03f94149bc8e564973fd4c6f0eabe76061dd4355b03b0",
"period": "hmac-sha256:3cf83aa363c8f73a7e23ccd56baa8f4e1119bc15800030f663f2d07c5420ce91",
"renewable": true,
"ttl": "hmac-sha256:3cf83aa363c8f73a7e23ccd56baa8f4e1119bc15800030f663f2d07c5420ce91",
"type": "hmac-sha256:792572c378bcb0b0400ad2033078e80334dfd06d76d948866960ad9b8547ba62"
},
"remote_address": "127.0.0.1"
}
}
{
"time": "2019-08-17T21:53:07.709275872Z",
"type": "response",
"auth": {
"client_token": "hmac-sha256:0c97855631748ce0a775e3efc79fc607b0d2f61ddeb78b15e915a5087013fb5b",
"accessor": "hmac-sha256:c081cc37603419f02e67fb93f2f1362aa0eb37fa42635606cc51b9b7ed1ed561",
"display_name": "root",
"policies": [
"root"
],
"token_policies": [
"root"
],
"token_type": "service"
},
"request": {
"id": "f8b0f707-7e38-1410-4173-235ff9e250b6",
"operation": "update",
"client_token": "hmac-sha256:0c97855631748ce0a775e3efc79fc607b0d2f61ddeb78b15e915a5087013fb5b",
"client_token_accessor": "hmac-sha256:c081cc37603419f02e67fb93f2f1362aa0eb37fa42635606cc51b9b7ed1ed561",
"namespace": {
"id": "root"
},
"path": "auth/token/create",
"data": {
"display_name": "hmac-sha256:0f235cb7061e26e25b346c787a036860e247e0e32181b8adf13850812a27a9f1",
"entity_alias": "hmac-sha256:0f235cb7061e26e25b346c787a036860e247e0e32181b8adf13850812a27a9f1",
"explicit_max_ttl": "hmac-sha256:3cf83aa363c8f73a7e23ccd56baa8f4e1119bc15800030f663f2d07c5420ce91",
"num_uses": "hmac-sha256:943213e389eae841e8d03f94149bc8e564973fd4c6f0eabe76061dd4355b03b0",
"period": "hmac-sha256:3cf83aa363c8f73a7e23ccd56baa8f4e1119bc15800030f663f2d07c5420ce91",
"renewable": true,
"ttl": "hmac-sha256:3cf83aa363c8f73a7e23ccd56baa8f4e1119bc15800030f663f2d07c5420ce91",
"type": "hmac-sha256:792572c378bcb0b0400ad2033078e80334dfd06d76d948866960ad9b8547ba62"
},
"remote_address": "127.0.0.1"
},
"response": {
"auth": {
"client_token": "hmac-sha256:fdb305fbabaf0044fc6d696fb2d0ff3d96574ff4d7fab804e8d5d36b7f2ddd14",
"accessor": "hmac-sha256:19f3a70ceea337f067c053249504fbf8e8c164304b66a8c97fad421d43b5e4af",
"display_name": "token",
"policies": [
"root"
],
"token_policies": [
"root"
],
"token_type": "service"
}
}
}
How can I find out who it was?
How can I get the accessor of the token that was compromised?
Where can I get an accessor of the just created token to revoke it?
Or maybe I didn't get purposes of the Vault audit right?

I've found a cool option that hepled me: hmac_accessor = false, here is the audit log with tis option enabled:
{
"time": "2019-08-27T07:55:57.888464574Z",
"type": "response",
"auth": {
"client_token": "hmac-sha256:84c8887e815c04aeef145ebffa05f9ef6fde166d7645b5046416d76add283fef",
"accessor": "y1lRcyzxkPgL0gmQ45WqliPy",
"display_name": "root",
...
},
"request": {
"id": "f4dc76af-b562-ae2c-8d6f-dd6a0d6f7ef6",
"operation": "update",
"client_token": "hmac-sha256:84c8887e815c04aeef145ebffa05f9ef6fde166d7645b5046416d76add283fef",
"client_token_accessor": "y1lRcyzxkPgL0gmQ45WqliPy",
...
},
"response": {
...
},
"error": ""
}
UPD: list of current accessors:
$ vault list auth/token/accessors
Keys
----
MelMLthx4K4FznCbNIB8xbC6
bOnatDe7MXfdB9f3CRuGPo0h
y1lRcyzxkPgL0gmQ45WqliPy
VerAvaBln92HG38gKbKEcXOZ
Get info about token by the accessor:
$ vault write auth/token/lookup-accessor accessor=VerAvaBln92HG38gKbKEcXOZ
Key Value
--- -----
accessor VerAvaBln92HG38gKbKEcXOZ
creation_time 1566893336
creation_ttl 3m
display_name token
entity_id n/a
expire_time 2019-08-27T11:11:56.903211142+03:00
explicit_max_ttl 0s
id n/a
issue_time 2019-08-27T11:08:56.903210949+03:00
meta <nil>
num_uses 0
orphan false
path auth/token/create
period 3m
policies [root]
renewable true
ttl 2m55s
type service

Related

Alexa CBT Test: Failed Test due to DeepQuery=True

My colleagues and I have been working to fix a reported issue on our Amazon Alexa CBT Test regarding the value “DeepQuery=true”.
Our code has been modified, so that every state change is reported automatically and all the used interfaces have the properties “proactivelyReported” and “retrievable” set to true.
As has been suggested by the WWA-Support we used the Smart Home Debugger of the Developer Console to validate the ReportEvents (e.g. Discovery or ChangeReport) and we checked the state of our device on the “View Device State” page (both pages are referenced on: https://developer.amazon.com/en-US/docs/alexa/smarthome/debug-your-smart-home-skill.html).
For debugging purposes we scaled our device capabilities down to just the PowerController. The AddOrUpdateReport of Alexa.Discovery looks to our eyes now exactly as expected/documented. Same goes for the ChangeReport, which we proactively send right after the AddOrUpdateReport (Two sample-Reports for both are provided at the end).
Unfortunately we are still faced with the issue, that “DeepQuery=true” on the “View Device State” page.
If we set the interface property “retrievable” to false, “DeepQuery=false”, but the Alexa-App does not retain the current state of the device. In this configuration the Alexa-App can only be used to send commands, which unfortunately will lead to other test cases to fail.
Does anyone know how to solve this issue?
How can we set “proactivelyReported” and “retrievable” to true and have “DeepQuery=false”?
Any help would be greatly appreciated and I will gladly provide more informations if needed.
Sample AddOrUpdateReport from Smart Home Debugger
{
"header": {
"namespace": "SkillDebugger",
"name": "CaptureDebuggingInfo",
"messageId": "05b030fb-6393-4ae0-80d0-47fc27876f0e"
},
"payload": {
"skillId": "amzn1.ask.skill.055ca62d-3cf8-4f51-a683-9a98b36f4637",
"timestamp": "2021-09-09T13:28:21.629Z",
"dialogRequestId": null,
"skillRequestId": null,
"type": "SmartHomeAddOrUpdateReportSuccess",
"content": {
"addOrUpdateReport": {
"event": {
"header": {
"namespace": "Alexa.Discovery",
"name": "AddOrUpdateReport",
"messageId": "2458b969-7c3e-47e2-ab0b-6e13a999be76",
"payloadVersion": "3"
},
"payload": {
"endpoints": [
{
"manufacturerName": "Our Company Name",
"description": "Our Product Name",
"endpointId": "device--cb12b420-1171-11ec-81f3-cb34e87ea438",
"friendlyName": "Lampe 1",
"capabilities": [
{
"type": "AlexaInterface",
"version": "3",
"interface": "Alexa.PowerController",
"properties": {
"supported": [
{
"name": "powerState"
}
],
"proactivelyReported": true,
"retrievable": true
}
},
{
"type": "AlexaInterface",
"interface": "Alexa",
"version": "3"
}
],
"displayCategories": [
"LIGHT"
],
"connections": [],
"relationships": {},
"cookie": {}
}
],
"scope": null
}
}
}
}
}
}
Sample ChangeReport from Smart Home Debugger
{
"header": {
"namespace": "SkillDebugger",
"name": "CaptureDebuggingInfo",
"messageId": "194a96a1-6747-46ba-8751-5c9ef715fd34"
},
"payload": {
"skillId": "amzn1.ask.skill.055ca62d-3cf8-4f51-a683-9a98b36f4637",
"timestamp": "2021-09-09T13:28:23.227Z",
"dialogRequestId": null,
"skillRequestId": null,
"type": "SmartHomeChangeReportSuccess",
"content": {
"changeReport": {
"event": {
"header": {
"namespace": "Alexa",
"name": "ChangeReport",
"messageId": "8972e386-9622-40e6-85e7-1a7d81c79c8a",
"payloadVersion": "3"
},
"endpoint": {
"scope": null,
"endpointId": "device--cb12b420-1171-11ec-81f3-cb34e87ea438"
},
"payload": {
"change": {
"cause": {
"type": "APP_INTERACTION"
},
"properties": [
{
"namespace": "Alexa.PowerController",
"name": "powerState",
"value": "ON",
"timeOfSample": "2021-09-09T13:28:18.088Z",
"uncertaintyInMilliseconds": 500
}
]
}
}
},
"context": {
"properties": []
}
}
}
}
}

Gitlab: Dependency scanner report is not shown on security dashboard

I am trying to create my own security scanner which will check dependencies. To test the functionality, I created a "mock scanner" which downloads a file from webhook, and saves it as an artifact ought to be uploaded to the server.
The artifact is uploaded successfully and in the CI output I can see the 201 code, but for some reason it is not presented in the security dashboard.
What am I doing wrong?
Thank you!
The CI job looks as following:
mysec_dependency_scanning:
stage: test
script:
- curl https://webhook.site/XXXX -o gl-dependency-scanning-report.json
- sleep 3
allow_failure: true
artifacts:
reports:
dependency_scanning: gl-dependency-scanning-report.json
The content of the json file is from the example provided by gitlab and it as following:
{
"version": "2.0",
"vulnerabilities": [
{
"id": "51e83874-0ff6-4677-a4c5-249060554eae",
"category": "dependency_scanning",
"name": "alik alik",
"message": "Regular Expression Denial of Service in debug",
"description": "alik to regular expression denial of service when untrusted user input is passed into the `o` formatter. It takes around 50k characters to block for 2 seconds making this a low severity issue.",
"severity": "Unknown",
"solution": "Upgrade to latest versions.",
"scanner": {
"id": "dadada",
"name": "dadada"
},
"location": {
"file": "yarn.lock",
"dependency": {
"package": {
"name": "debug"
},
"version": "1.0.5"
}
},
"identifiers": [
{
"type": "gemnasium",
"name": "Gemnasium-37283ed4-0380-40d7-ada7-2d994afcc62a",
"value": "37283ed4-0380-40d7-ada7-2d994afcc62a",
"url": "https://deps.sec.gitlab.com/packages/npm/debug/versions/1.0.5/advisories"
}
],
"links": [
{
"url": "https://nodesecurity.io/advisories/534"
},
{
"url": "https://github.com/visionmedia/debug/issues/501"
},
{
"url": "https://github.com/visionmedia/debug/pull/504"
}
]
},
{
"id": "5d681b13-e8fa-4668-957e-8d88f932ddc7",
"category": "dependency_scanning",
"name": "Authentication bypass via incorrect DOM traversal and canonicalization",
"message": "Authentication bypass via incorrect DOM traversal and canonicalization in saml2-js",
"description": "Some XML DOM traversal and canonicalization APIs may be inconsistent in handling of comments within XML nodes. Incorrect use of these APIs by some SAML libraries results in incorrect parsing of the inner text of XML nodes such that any inner text after the comment is lost prior to cryptographically signing the SAML message. Text after the comment, therefore, has no impact on the signature on the SAML message.\r\n\r\nA remote attacker can modify SAML content for a SAML service provider without invalidating the cryptographic signature, which may allow attackers to bypass primary authentication for the affected SAML service provider.",
"severity": "Unknown",
"solution": "Upgrade to fixed version.\r\n",
"scanner": {
"id": "dadada",
"name": "dadada"
},
"location": {
"file": "yarn.lock",
"dependency": {
"package": {
"name": "saml2-js"
},
"version": "1.5.0"
}
},
"identifiers": [
{
"type": "gemnasium",
"name": "Gemnasium-9952e574-7b5b-46fa-a270-aeb694198a98",
"value": "9952e574-7b5b-46fa-a270-aeb694198a98",
"url": "https://deps.sec.gitlab.com/packages/npm/saml2-js/versions/1.5.0/advisories"
},
{
"type": "cve",
"name": "CVE-2017-11429",
"value": "CVE-2017-11429",
"url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11429"
}
],
"links": [
{
"url": "https://github.com/Clever/saml2/commit/3546cb61fd541f219abda364c5b919633609ef3d#diff-af730f9f738de1c9ad87596df3f6de84R279"
},
{
"url": "https://github.com/Clever/saml2/issues/127"
},
{
"url": "https://www.kb.cert.org/vuls/id/475445"
}
]
}
],
"remediations": [
{
"fixes": [
{
"id": "5d681b13-e8fa-4668-957e-8d88f932ddc7",
}
],
"summary": "Upgrade saml2-js",
"diff": "ZGlmZiAtLWdpdCBhL...OR0d1ZUc2THh3UT09Cg==" // some content is omitted for brevity
}
]
}
I was able to fix the problem, the issue was an invalid json format.
Had to do alot of trial and error but I was able to create a working template for a dependency scanning report.
{
"version": "3.0.0",
"vulnerabilities": [
{
"id": "dfa1f7f3d56db6e1c3451a232de42f153e0335611de6f0344443d84e448ee2cf",
"category": "dddda",
"name": "dddda",
"message": "ddda",
"description": "dddda lack of validation in `index.js`.",
"cve": "dada",
"severity": "Critical",
"solution": "Upgrade to version 2.0.5 or above.",
"scanner": {
"id": "lalal",
"name": "Code_Analyzer"
},
"location": {
"file": "yarn.lock",
"dependency": {
"iid": 447,
"package": {
"name": "copy-props"
},
"version": "2.0.4"
}
},
"identifiers": [
{
"type": "dada",
"name": "dada-e9e12690-2e4d-4251-bef0-7357ddc05881",
"value": "e9e57890-5e4d-4832-bef2-7337ddc05889",
"url": "https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/blob/master/npm/copy-props/CVE-2219-28503.yml"
},
{
"type": "cve",
"name": "CVE-2237-28503",
"value": "CVE-2237-28503",
"url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2237-28503"
}
],
"links": [
{
"url": "https://nvd.nist.gov/vuln/detail/CVE-2237-28503"
}
]
}
],
"remediations": [],
"dependency_files": [
{
"path": "yarn.lock",
"package_manager": "yarn",
"dependencies": [
{
"iid": 447,
"dependency_path": [
{
"iid": 708
},
{
"iid": 707
}
],
"package": {
"name": "copy-props"
},
"version": "2.0.4"
}
]
}
],
"scan": {
"scanner": {
"id": "lalal",
"name": "Code_Analyzer",
"url": "https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium",
"vendor": {
"name": "lalal"
},
"version": "2.29.5"
},
"type": "dependency_scanning",
"start_time": "2021-05-03T06:47:29",
"end_time": "2021-05-03T06:47:30",
"status": "success"
}
}

Create the message route in azure iothub using rest api

I am able to create the "message route" in azure portal and able to route messages to servicebusqueue if the query matching, I want to create the message route using the restapi instead of using azure portal, I have seen many documents but unable to find the proper one. Whether creating the message route using restapi is possible or not? if yes,How can I achieve this and please provide the respective links to refer?
I haven't tried this through REST API, but as Roman suggested,
You can check the IotHubResource_CreateOrUpdate which will help you understand how to Create or update the metadata of an Iot hub. The usual pattern to modify a property is to retrieve the IoT hub metadata and security metadata, and then combine them with the modified values in a new body to update the IoT hub.
Sample Request:
PUT https://management.azure.com/subscriptions/91d12660-3dec-467a-be2a-213b5544ddc0/resourceGroups/myResourceGroup/providers/Microsoft.Devices/IotHubs/testHub?api-version=2018-04-01
Request Body:
{
"name": "iot-dps-cit-hub-1",
"type": "Microsoft.Devices/IotHubs",
"location": "centraluseuap",
"tags": {},
"etag": "AAAAAAFD6M4=",
"properties": {
"operationsMonitoringProperties": {
"events": {
"None": "None",
"Connections": "None",
"DeviceTelemetry": "None",
"C2DCommands": "None",
"DeviceIdentityOperations": "None",
"FileUploadOperations": "None",
"Routes": "None"
}
},
"state": "Active",
"provisioningState": "Succeeded",
"ipFilterRules": [],
"hostName": "iot-dps-cit-hub-1.azure-devices.net",
"eventHubEndpoints": {
"events": {
"retentionTimeInDays": 1,
"partitionCount": 2,
"partitionIds": [
"0",
"1"
],
"path": "iot-dps-cit-hub-1",
"endpoint": "sb://iothub-ns-iot-dps-ci-245306-76aca8e13b.servicebus.windows.net/"
},
"operationsMonitoringEvents": {
"retentionTimeInDays": 1,
"partitionCount": 2,
"partitionIds": [
"0",
"1"
],
"path": "iot-dps-cit-hub-1-operationmonitoring",
"endpoint": "sb://iothub-ns-iot-dps-ci-245306-76aca8e13b.servicebus.windows.net/"
}
},
"routing": {
"endpoints": {
"serviceBusQueues": [],
"serviceBusTopics": [],
"eventHubs": [],
"storageContainers": []
},
"routes": [],
"fallbackRoute": {
"name": "$fallback",
"source": "DeviceMessages",
"condition": "true",
"endpointNames": [
"events"
],
"isEnabled": true
}
},
"storageEndpoints": {
"$default": {
"sasTtlAsIso8601": "PT1H",
"connectionString": "",
"containerName": ""
}
},
"messagingEndpoints": {
"fileNotifications": {
"lockDurationAsIso8601": "PT1M",
"ttlAsIso8601": "PT1H",
"maxDeliveryCount": 10
}
},
"enableFileUploadNotifications": false,
"cloudToDevice": {
"maxDeliveryCount": 10,
"defaultTtlAsIso8601": "PT1H",
"feedback": {
"lockDurationAsIso8601": "PT1M",
"ttlAsIso8601": "PT1H",
"maxDeliveryCount": 10
}
},
"features": "None"
},
"sku": {
"name": "S1",
"tier": "Standard",
"capacity": 1
}
}

Getting access denied after keycloak login. I dont have any roles in my keycloak server

I am implementing Keycloak authorization to my Node.js application. I created a realm and a client inside of it. I don't have any roles either in realm or in client. I have a route "/test" which is protected with Keycloak.
My keycloak.json looks like this:
{
"realm": "demo",
"auth-server-url": "http://localhost:8080/auth",
"ssl-required": "external",
"resource": "myapp",
"public-client": true,
"confidential-port": 0
}
Define roles (realm roles or client roles), assign the roles to your user (user which you use to perform the test), check your role scope mappings (or you can configure your client as full-scope for testing purpouse), and check that you are protecting your '/test' route with those same permissions.
E.g. you can try with keycloak-nodejs adapter (example).
Look at this configuration file (keycloak realm configuration example):
{
"realm": "nodejs-example",
"enabled": true,
"sslRequired": "external",
"registrationAllowed": true,
"privateKey": "...................",
"publicKey": ".....................",
"requiredCredentials": [ "password" ],
"users" : [
{
"username" : "user",
"enabled": true,
"email" : "sample-user#nodejs-example",
"firstName": "Sample",
"lastName": "User",
"credentials" : [
{ "type" : "password",
"value" : "password" }
],
"realmRoles": [ "user" ],
"clientRoles": {
"account": ["view-profile", "manage-account"]
}
}
],
"roles" : {
"realm" : [
{
"name": "user",
"description": "User privileges"
},
{
"name": "admin",
"description": "Administrator privileges"
}
]
},
"scopeMappings": [
{
"client": "nodejs-connect",
"roles": ["user"]
}
],
"clients": [
{
"clientId": "nodejs-connect",
"enabled": true,
"publicClient": true,
"baseUrl": "/",
"adminUrl" : "http://localhost:3000/",
"baseUrl" : "http://localhost:3000/",
"redirectUris": [
"http://localhost:3000/*"
],
"webOrigins": []
},
{
"clientId": "nodejs-apiserver",
"enabled": true,
"secret": "secret",
"redirectUris": [
"http://localhost:3000/*"
],
"webOrigins": [
"http://localhost:3000/*"
],
"serviceAccountsEnabled": true,
"authorizationServicesEnabled": true,
"authorizationSettings": {
"resources": [
{
"name": "resource",
"type": "urn:nodejs-apiserver:resources:default",
"ownerManagedAccess": false,
"uris": [
"/*"
],
"scopes": [
{
"name": "view"
},
{
"name": "write"
}
]
}
],
"policies": [
{
"name": "Default Policy",
"description": "A policy that grants access only for users within this realm",
"type": "js",
"config": {
"code": "// by default, grants any permission associated with this policy\n$evaluation.grant();\n"
}
},
{
"name": "Default Permission",
"description": "A permission that applies to the default resource type",
"type": "resource",
"config": {
"defaultResourceType": "urn:nodejs-apiserver:resources:default",
"applyPolicies": "[\"Default Policy\"]"
}
}
]
}
}
]
}
Explanation:
From this sample, look at how a user has roles assigned (realm roles: "user", account client roles: "account": ["view-profile", "manage-account"]):
{
...
"users" : [
{
"username" : "user",
"enabled": true,
"email" : "sample-user#nodejs-example",
"firstName": "Sample",
"lastName": "User",
"credentials" : [
{ "type" : "password",
"value" : "password" }
],
"realmRoles": [ "user" ],
"clientRoles": {
"account": ["view-profile", "manage-account"]
}
}
],
...
}
Look at how realm Roles are defined:
{
...
"roles" : {
"realm" : [
{
"name": "user",
"description": "User privileges"
},
{
"name": "admin",
"description": "Administrator privileges"
}
]
},
...
}
Look at how this sample uses a 'scope mapping' to map roles from realm to a user authenticated by a client (read more about this here role scope mapping):
{
...
"scopeMappings": [
{
"client": "nodejs-connect",
"roles": ["user"]
}
],
...
}
Look at how clients are defined. Check that 'nodejs-connect' client is public and 'nodejs-apiserver' is secret. In this sample, server is using the 'Authorization Api' to protect resources but you could protect your resources by granted roles only (if you want).
{
...
"clients": [
{
"clientId": "nodejs-connect",
"enabled": true,
"publicClient": true,
"baseUrl": "/",
"adminUrl" : "http://localhost:3000/",
"baseUrl" : "http://localhost:3000/",
"redirectUris": [
"http://localhost:3000/*"
],
"webOrigins": []
},
{
"clientId": "nodejs-apiserver",
"enabled": true,
"secret": "secret",
"redirectUris": [
"http://localhost:3000/*"
],
"webOrigins": [
"http://localhost:3000/*"
],
"serviceAccountsEnabled": true,
"authorizationServicesEnabled": true,
"authorizationSettings": {
"resources": [
{
"name": "resource",
"type": "urn:nodejs-apiserver:resources:default",
"ownerManagedAccess": false,
"uris": [
"/*"
],
"scopes": [
{
"name": "view"
},
{
"name": "write"
}
]
}
],
"policies": [
{
"name": "Default Policy",
"description": "A policy that grants access only for users within this realm",
"type": "js",
"config": {
"code": "// by default, grants any permission associated with this policy\n$evaluation.grant();\n"
}
},
{
"name": "Default Permission",
"description": "A permission that applies to the default resource type",
"type": "resource",
"config": {
"defaultResourceType": "urn:nodejs-apiserver:resources:default",
"applyPolicies": "[\"Default Policy\"]"
}
}
]
}
}
]
...
}
Finally, look at javascript (index.js) file to see how it uses 'keycloak-connect' (adapter) to protect and enforce access policies (usage of Authorization Api).
Tip
In development, you can get an access token and use this page to decode and see the token's content.
JWT.IO
I hope this helps.
I also had a 403 - Access Denied. What helped was stepping through the auth code of keycloak-connect. The token validation happens in the function validateToken in node_modules\keycloak-connect\middleware\auth-utils\grant-manager.js
if (!token) {
reject(new Error('invalid token (missing)'))
} else if (token.isExpired()) {
reject(new Error('invalid token (expired)'))
} else if (!token.signed) {
reject(new Error('invalid token (not signed)'))
} else if (token.content.typ !== expectedType) {
reject(new Error('invalid token (wrong type)'))
} else if (token.content.iat < this.notBefore) {
reject(new Error('invalid token (stale token)'))
} else if (token.content.iss !== this.realmUrl) {
reject(new Error('invalid token (wrong ISS)'))
}
...
For me, the problem was that I configured the url to the keycloak server without the schema (https). token.content.iss includes the schema and so it rejected because of token.content.iss !== this.realmUrl.
Unfortunately they seem to swallow those valuable Error messages without logging or returning them. I opened a question regarding this behavior.

How to fix "it doesn't support that" when I query Alexa retrievable property

I have this endpoint with powerState and connectivity properties both retrievable:
{
"endpointId": "123",
"manufacturerName": "abc",
"friendlyName": "lamp",
"description": "lamp",
"displayCategories": [
"LIGHT"
],
"capabilities": [
{
"type": "AlexaInterface",
"interface": "Alexa.PowerController",
"version": "3",
"properties": {
"supported": [{
"name": "powerState"
}],
"retrievable": true
}
},
{
"type": "AlexaInterface",
"interface": "Alexa.EndpointHealth",
"version": "3",
"properties": {
"supported": [{
"name": "connectivity"
}],
"retrievable": true
}
}
],
"cookie": {}
}
I respond to ReportState request by sending the state of both properties:
{
"context": {
"properties": [
{
"namespace": "Alexa.PowerController",
"name": "powerState",
"value": "ON",
"timeOfSample": "2019-01-10T10:17:19.99Z",
"uncertaintyInMilliseconds": 50
},
{
"namespace": "Alexa.EndpointHealth",
"name": "connectivity",
"value": {
"value": "OK"
},
"timeOfSample": "2019-01-10T10:17:19.90Z",
"uncertaintyInMilliseconds": 50
}
]
},
"event": {
"header": {
"namespace": "Alexa",
"name": "StateReport",
"payloadVersion": "3",
"messageId": "cde",
"correlationToken": "efg123"
},
"endpoint": {
"scope": {
"type": "BearerToken",
"token": "ab123"
},
"endpointId": "123",
"cookie": {}
},
"payload": {}
}
}
And I send the same context in the PowerController response.
In the Alexa app I can see my device, turn it on and off and view its state rightly. I can ask Alexa to turn on and off my device and the response in "OK", but if I try to ask:** "Is my device turned on?" ** Alexa answers that this device doesn't support that.
The skill language is Italian and PowerController documentation https://developer.amazon.com/it/docs/device-apis/alexa-powercontroller.html says that query is supported.
What am I missing?

Resources