Authentication and authorization

#1

Is there a document or any info explaining how authentication works and what the possibilities are regarding authorization, plus how to set it?

0 Likes

#2

Hey Tom,

The documentation is not currently available in the platform (it should be available after version 7.2). In the meantime, i will post the existing documentation from our internal wiki here. Sorry for the formatting.

Please also see the types Permission, AdminGroup, Role, AclPrivilege, AclEnabled, PageGroup and Authorizer.

|Access Control framework has been revamped to make the system more secure.
ACCESS IS DENIED TO (almost) EVERY ACTION
By default, every User is granted access to a small set of actions for bootstrapping.
Action access is granted in 2 different ways:
adding Users to Groups (AdminGroup).
through the PageGroups that the User has visibility to (PageGroup ACL).
Data access is still mostly done through ACLs but can also be done through the ActionCondition type.
Access Control Types
Permission – describes access to a specific action or actions (abstract type).
ActionCondition – assigns an expression to to a specific action or actions (abstract type).
Role – collection of Permissions and optionally ActionConditions that define a behavior pattern (entity type).
AdminGroup – container for one or more Roles that defines a specific function. Users are assigned to AdminGroups to grant them the given function (entity type).
User – group membership is stored in this object.
PageGroup – Permissions needed by the UI are defined through PageGroups. If a User has access to a PageGroup she/he must have access to all actions invoked by the UI.
Permissions and ActionConditions are assigned to Roles.
Roles are added to AdminGroups – Roles are metadata.
Users are added to AdminGroups – AdminGroups are seed data.

By default, if root action is authorized, child actions will also be authorized.
New @action annotation to define access control properties for actions.
Permission
Fields
access: ‘allow’ or ‘deny’
typeName: type name or * for all types
actionGroup: action group name
action: action name or * for all actions
only one of actionGroup or action can be specified
String representation
“access:typeName:actionGroup:action”
Examples:
“allow:::” – allow access to all actions in all types (SystemAdminRole)
“deny::cluster-admin:” – deny access for actionGroup cluster-admin in all types
“allow:User::upsert” – allow User.upsert() access
ActionCondition
Fields
typeName: type name or * for all types
actionGroup: action group name
action: action name or * for all actions
condition: expression to be evaluated by action
only one of actionGroup or action can be specified
String representation
“typeName:actionGroup:action:condition”
Examples
“User:write::(id == _context.userName)”
“User:read::(1 == 1)”
“MemberAccount::evaluate:(member == _context.userName)"
Role
Fields
id
name
permissions – arry of Permission
actionConditions – arry of ActionCondition
securityLevel – used for impersonation
lower value => higher level
Impersonator user can only impersonate users with lower securityLevel (higher value)
description
Examples:
{
“id” : “DeveloperRole”,
“name” : “DeveloperRole”,
“securityLevel” : 3,
“permissions” : [
"deny:
:cluster-admin:",
“deny::user-admin:",
"allow:
::"
],
“actionConditions” : [
"Member::
:(1==1)”
]
}
{
“id” : “ClusterAdminRole”,
“name” : “ClusterAdminRole”,
“securityLevel” : 2,
“permissions” : [
“allow:Cassandra::",
"allow:Cluster::
”,
“allow:ClusterConfig::",
"allow:Console::
”,
“allow:DbAdmin::*”
]
}
AdminGroup
Fields
id
name
roles – arry of assigned Roles
This type will be renamed to 'Group’
Examples:
{
“id”:“DeveloperGroup”,
“name”:“DeveloperGroup”,
“roles”: [
{ “id”:"DeveloperRole” },
{ “id”:"ConsoleAccessRole” },
{ “id”:“C3.Role.AllPageGroupAccess”}
]
}
{
“id”:“ClusterAdminGroup”,
“name”:“ClusterAdminGroup”,
“roles”:[
{ “id”:"ClusterAdminRole” },
{ “id”:"ConsoleAccessRole” }
]
}
@action annotations
Specified at type and action (function) levels.
@action(group=<group_name>)
Actions can be grouped for ease of administration.
@action(authz=‘never’)
Actions with this annotation will never be checked for authorization (will always be allowed).
@action(authz=‘always’)
Actions with this annotation will always be evaluated for authorization even if it is a child of an authorized root action.
@action(authzChildActions=true)
Child actions must always be evaluated for authorization.
PageGroup
PageGroup is an ACL enabled type.
Every new UI page should have a seed data in PageGroup for that ui page with id format {App.Page}
Every page should cal list with roles who should have access.
By having access to a page, underlying types and actions are granted permissions through PageGroup.getPermissions([PageGroup]);
For a give page, its permissions are generated using:
all Components referenced in those pages with id format {App.Component} and their DataSources will be used to determine the permissions. This will be done recursively.
all DataSources explicitly referenced in Pages and Components
explicitly defined Permission list in those pages.
If any additional permissions are required that are not captured (for example, javascript code explicitly making action requests), they should be specified in pages using the ‘permissions’ field.
Access (Permission) evaluation
Permissions can grant or deny access to the given resource.
Actions that will be evaluated for access:
Root actions without @action(authz=‘never’) annotation – vast majority of actions
Child actions with @action(authz=‘always’) annotation
Evaluation:
Based on the intersection of:
User’s Permissions - gathered from all Roles the User has and all the PageGroups the User has access to.
Permissions defined for current action type and from the corresponding mixed-in types.
Permissions within the same Role are and’ed and Permissions across different Roles are or’ed
allow AND deny = deny
allow OR deny = allow
ActionCondition evaluation
Boolean expressions that can be evaluated by an action for further filtering.
ActionConditions are aggregated from current action type and from the corresponding mixed-in type or types.
ActionConditions within the same Role are and’ed and Permissions across different Roles are or’ed
Currently only Data Access actions use this feature.
DefaultActionCondition – is a persistable type that can be used to assign a default condition to a given action or actions.
For example there is a DefaultActionCondition to access User objects:
{
“id” : “UserAccess”
“typeName” : "User”,
“condition” : “(user == _context.userName)”
}
Helper Functions
User.allGroups - member function to list all the AdminGroups for the given User.
User.allRoles - member function to list all the Roles for the given User.
AdminGroup.allUsers - member function to list all the Users that belong to the given AdminGroup.
AdminGroup.allRoles - member function to list all the Roles assigned to the given AdminGroup.
Role.allUsers - member function to list all the Users that have assigned the given Role.
Role.allGroups - member function to list all the AdminGroups that have assigned the given Role.
Role.allPermissions - member function to list all the Permissions for the given Role.
Role.allActionConditions - member function to list all ActionConditions for the given Role.
Developer Tools
Authorizer
C3 type that has utility functions to find details about access authorization.
isAuthorized(typename, action) – is the given action authorized for the given user (accessible always by all users).
actionAuthorization(typename, action, username, tenant, tag) – is the given action authorized for the given user (optionally in tenant and tag) and why.
actionPermissions(typename, action, tenant, tag) – returns the Permissions and Action Conditions that apply to the given action and also returns the AdminGroups that grant access to it.
Group impersonation
User.impersonateGroup(User, Admingroup)
The target User will swap its original group membership with the target AdminGroup
Impersonation is allowed only be to AdminGroups that have Roles with the same or higher securityLevel value as original membership.
A user already impersonating cannot impersonate again.
User.unimpersonateGroup() – will restore original User’s membership.
User impersonation (5.6 feature)
Member function User.impersonate(impersonator-username, impersonatee-username)
Effectively the impersonator user becomes the target user (impersonatee).
Impersonator must have a higher security level (lower aggregated Role.securityLevel value) than the target user.
security level is the lowest securityLevel value off all the Roles that the User has.
The boolean field ‘impersonating’ in the ActionContext object indicates whether the user is impersonated.
To use this field in an expression:
check for ‘false’: (!exists(_context.impersonating) || _context.impersonating != true))
check for ‘true’: (exists(_context.impersonating) && _context.impersonating == true))
The java SimpleActionContext realUserName field has the userName of the impersonator.
Member function User.unimpersonate(impersonator-username)
UserAdmin
UserAdmin.addUserToGroup(username, groupId)
UserAdmin.removeUserFromGroup(username, groupId)

0 Likes

#3

Also, if you have access to the “Advanced API Topics” presentation, please see that last section called “Authorization”

0 Likes