loginfor an account's users must be different only between the users of that account, not globally. We could have an account with login "mark", another account "exampleOne" with a user with login "mark", another account "exampleTwo" with another user with login "mark", and so forth.
<principals> CAN <actions> <resources> WHEN <conditions>.
<principal>will be always the user performing the HTTP request. Likewise,
<resource>will always be the URL of such request, for example
<principal>in our rules, since it'll always be defined by the role-tags of the resource the user is trying to get access to. For the same reason, we don't need to specify
<resource>in our rules.
DENYany attempt made by any account user to access a given resource, unless:
GRANTSaccess to that resource
read, which includes a policy rule like
CAN listmachines and getmachineswill not get access to resources like
/:account/machines/:instance_idunless these resources are role-tagged with the role
<actions>included in the policy rule are just
getmachine, the user will be able to retrieve an instance's details provided by the GetMachine action, but will not be able to perform any other instance actions (like StopMachine). However, if the role has a rule including that
<action>(like StopMachine), or the user has an additional role which includes that rule, then the user can invoke that action too.
default_membersattribute in a role. If three different roles contain the "john" user (amongst others) in their default-members list, then the "john" user will have those three roles as active roles by default. This can be overridden by passing in
?as-role=<comma-separated list of role names>as part of the URL, or adding a --role flag when using a node-smartdc command; provided that each role contains that user in their
memberslist, then those roles are set as the currently-active roles for a request instead.