shv access control

Shv access control

Access Grant find algorithm

1. Each user has list of roles defined and accessible to shvbroker. Each role has property weight of type int defined.
2. Each SHV method defines its accessLevel as a number > 0 or string which must be convertible to access level int by node, see method ShvNode::grantToAccessLevel(...). accessLevel == 0 means no-access.
3. When client calls the RPC method, then shvbroker check access list (ACL) for all the user's roles sorted by weight DESC.
4. For role in roles sorted by weight, greatest first
   1. For access-rule in acces-rules for role sorted by most specific rule first
      1. if request shvPath matches access-rule
         1. then grant of this role is assigned to RPC request as AccessGrant meta-value and it is sent to the client. It is up to the client implementation whether it checks the accessGrant or not.
         2. stop searching with success
5. 'Operation not permitted' RPC error is returned, because shvPath match is not found for any of role of any weight

Access rule

Access rule consist of:

• service-pattern, used for experimental service down-tree calls only, which might have form:
  1. - NONE
  2. ** - ANY
  3. service-name - SOME
• path-pattern, which might have form:
  1. shv-path
  2. shv-path/**
• method-pattern, which might have form:
  1. method-name
  2. (empty string)
• access-grant, will be explained later in Access Grant

Following access rules examples are sorted from most specific to least specific (see bool AclAccessRule::isMoreSpecificThan(const AclAccessRule &other) const)

Service precedence:

1. SOME service
2. ANY service
3. NO service

Path precedence:

1. Exact path with method
2. Exact path without method
3. Longest path prefix with method
4. Longest path prefix without method

path	method	note
foo/bar	baz	exact match
foo	baz	(same specific as above)
foo/bar		(same specific as above)
foo		(same specific as above)
foo/bar/**	baz	longest path prefix match, exact method match
foo/**	baz	shorter path prefix match, exact method match
**	baz	any path, exact method match
foo/bar/**		longer path prefix match, any method
foo/**		shorter path prefix match, any method
**		any path, any method

Access rules precedence by most-specific will be changed to order-of-definition in future versions

This way we can use any path pattern like **/PME/** because we do not have to define path specificity level and we can also get rid of role weight property.

1. When client calls the RPC method, then shvbroker check access list (ACL) for all the user's roles sorted by order of definition in users roles list, for example ["userAdmin", "support"]`.
2. For access-rule in acces-rules for role sorted by natural order of rules definition
   1. if request shvPath matches access-rule then acces-grant is read
      1. if access-grant is in form jmp role-name, note that this is not valid Cpon, then searching continues in access table for role role-name
      2. else access-grant is added to access-grant-list
3. If access-grant-list is empty 'Operation not permitted' RPC error is returned, because shvPath match is not found.
4. access-grant-list is assigned to RPC request as accessGrant meta-value and it is sent to the client. It is up to the client implementation whether it checks the accessGrant or not. If access-grant-list size == 1, then accessGrant = access-grant-list[0]

Access Grant

Acces grant is rpc value of next forms:

• Int, then it is accessLevel.
• String, then id is Role.
• IMap, then it is AccessGrant, meta type AccessGrant is optional.
  • Possible fields: Type = 1, NotResolved, Role, AccessLevel, User, Password, LoginType

Access grants in client requests are removed by broker form security reasons. Only broker can set this field in RpcRequest.

• If slave broker receives RpcMessage
  • if grant field IS SET, then RpcMessage is forwarded downstream with original grant unchanged. Request is authorized by master broker.
  • if grant field IS NOT SET, then role masterBroker is used in access grant resolution using access table. This is used mainly for service calls as (un)subscribe propagation to slave brokers etc.
• If client receives RpcMessage
  • Access grant from RpcMessage is converted to accessLevel by method ShvNode::grantToAccessLevel(...) on client implementation.