Skip to main content


As stated before Principal is an actor that interacts with the system. Logically speaking if your system can define only one principal then it does not need access control at all.

Lets define examples of principals for inspiration. The more principals you've got the more control you get.


Represents an actor that makes unauthenticated interaction with your system.

@pallad/access-control defines it as BasicPrincipal.Anonymous.

export class Anonymous extends new TypeCheck<Anonymous>('@pallad/access-control/Principal/Anonymous').clazz {
readonly kind = 'principal';
readonly type = 'anonymous'
static INSTANCE = new Anonymous();


Indicates that system itself performs an action. Might be used to effectively "turn off" access control since we would like to allow system to do almost everything.

Example of actions that might be restricted only to system:

  • Truncate database storage
  • Getting data and bypassing tenancy checks


Represents authenticated user.

@pallad/access-control does not defines such participant as the shape of authenticates users data is too different among the systems, therefore to avoid confusion it was not added.

Example User principal just for sake of inspiration

export class User {
readonly kind = 'principal';
readonly type = 'user'

readonly id: string, // just user id
readonly workspaceId: string // workspaceID - very helpful for tenancy checks
) {



Describes an actor that impersonates as given user. For example administrator might have an ability to "log in" as John Smith and perform some actions on his behalf. Having this type of participant allows you to limit area of possible actions for impersonated users.

For example impersonated user:

  • cannot remove account since it is too dangerous action
  • cannot mark notifications, messages as read (very cool feature)


All possibilities are not listed since that is simply impossible. That is why you should not hesitate to create your own type of principal or extend existing ones.