Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Is it possible to authorize only devices from the "Associated client devices" list from the Core device? #423

Open
DDemoNZ opened this issue Feb 8, 2024 · 3 comments
Labels
question Further information is requested

Comments

@DDemoNZ
Copy link

DDemoNZ commented Feb 8, 2024

Main question:
Is it possible to authorize only devices from the "Associated client devices" list from the Core device?

Actual
The situation is the following: we have an Auth component with a configuration with wildcard for thing names and allow all actions for all resources.

{
	"deviceGroups": {
		"formatVersion": "2021-03-05",
		"definitions": {
			"AllPermissiveDeviceGroup": {
				"selectionRule": "thingName: *",
				"policyName": "AllPermissivePolicy"
			}
		},
		"policies": {
			"AllPermissivePolicy": {
				"AllowAll": {
					"statementDescription": "Allow client devices to perform all actions.",
					"operations": [
						"*"
					],
					"resources": [
						"*"
					]
				}
			}
		}
	}
}

And our actual behavior where all devices can access resource, in our case MQTT (using EMQX), using the Auth CA, Core device's instance hostname etc. We do not use Discovery API to get a Connectivity info, so we pass the CA cert and hostname in a third way.
And we send messages from devices to some topic that is specified in the Bridge config.
The result is that any device that has the CA cert is able to send a message, even if it is not associated with the Core device.

Expected
Expected behavior was that unassociated devices wouldn't be able to connect through this Core Device and send any messages to the cloud. Without adding specific name patterns to the Auth configuration.
Is it only possible by using the Discovery API on the client side, or by specifying a thing name or a thing group name?


Actually I didn't find clear information about this, so it's more a question than a defect.
Found that it works in connection with the Discovery API, and for storing client credentials. Just wanted to know if this is possible to achieve this without using the Discovery API.

@DDemoNZ DDemoNZ added bug Something isn't working needs-triage labels Feb 8, 2024
@shaguptashaikh
Copy link
Contributor

shaguptashaikh commented Feb 8, 2024

Hi, your policy in the component configuration you posted is too open, you're allowing all thingnames to be able to connect to the broker, which is the reason any device that has the CA is able to authenticate and send messages. If you expect to restrict it to only a certain set of devices, please restrict the policy to just those.

Association using the cloud APIs is only for discovery which you've opted to not use. It doesn't play a part in what client devices to allowlist, the component configuration controls that

@shaguptashaikh shaguptashaikh added question Further information is requested and removed needs-triage bug Something isn't working labels Feb 8, 2024
@DDemoNZ
Copy link
Author

DDemoNZ commented Feb 23, 2024

Hello.
Thank you for your answer.

I have another question about authentication. It seems I didn't find something related specifically to authentication via things group.

According to your answer, in case the associated devices do not affect the authentication process.
Is it possible to specify Group instead of thingName to allow access only to devices from a specific group.
Or it is necessary to specify exactly the thing names?

Or maybe there is some other way and you could tell me where I should look.

@MikeDombo
Copy link
Member

Hello,

It is not possible to authorize connections by thing group, only by thing name and using wildcards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants