Intro
Connhex IAM is a service that manages identities and permissions in Connhex Cloud.
Use cases
Connhex IAM can be used anytime you need to apply logic that involves assigning or enforcing permissions to some entity. Practically speaking, the vast majority of the services composing Connhex Cloud integrates with Connhex IAM.
Key concepts
There are a few definitions that are instrumental in understanding Connhex IAM.
Actions are operations an identity can perform on a resource. Typical actions are creating, reading, updating and deleting resources.
A resource is something upon which actions can be performed. It shouldn't be confused with a Connhex Resource: the IAM resource is much more general. The prime resource example is represented by devices.
The relationship between resources and actions is specified in policies.
Policies
A policy is a set of rules that dictates how a given entity behaves.
It describes what actions can be performed on a resource by an identity: for example, it specifies that a user can read and update a set of devices but can't create new ones.
Policies include statements and roles: statements are responsible for tracking the relationship between resources and actions that can (or cannot) be performed over them. There are two types of statements:
- allow: actions that are permitted on some resources
- deny: actions that are forbidden on some resources
The reason behind including both types is flexibility: you could apply a set of permissions by assigning a role, then revoke some of these to a certain user through deny statements. Likewise, you could provide a certain user additional permissions over its role through an allow statement.
If the same action-resource pair appears in both deny and allow statements, deny prevails.
Statements can be scoped by tenancy and include inline actions: for performance reasons, you should prefer using custom roles rather than inline actions wherever practical.
Why should I bother with policies? They seem to be much more complex than any other user management that comes with an IoT platform!
This is another example of Connhex being dedicated to device manifacturers: in real production use cases, users can't be managed on an equal basis. You'll always have that particular customer that needs a slightly different behaviour: instead of hard-coding an if statement to handle it, Connhex gives you all the tools necessary to satisfy his necessities.
Because we all know that one simple and reasonable exception quickly becomes two, then three, then "we need to rewrite this from scratch".