What

...

Types of Authorization Are Available and Where Can Authorization Take Place

There are many different ways of doing authorization with Ceptor - ranging from simple role-based authorization checking in the Ceptor Gateway before a request is allowed to continue over centrally configured attribute-based checking to complete custom scripts which can implement any kind of checking they wish based upon the available information about the user, his roles, the resource he is attempting to access, and the data he is accessing it with.

Authorization checking can be completely customized by implementing your own Validation code (see Creating a custom Custom Agent Validator for details) which allows complete control over checking group memberships.

...

Role-based access control is the concept where a user has zero or many roles attached to him. Resources are protected by roles, and if the user has one of the require required roles, access is allowed, otherwise access is denied to the given resource.

...

Default "magic" roles that exists exist and are used in Ceptor are:

• pp_everyone
  Every user/session has this role - no matter if they are authenticated or not - this can be used to allow unrestricted access, or to require that a request has a valid session (anonymous or authenticated) and deny requests without one.
• pp_identifiedusers
  Only identified users have this role - but no matter how they are authenticated, and what authorization level they have, they have this role automatically. Use this role to protect access to resources where you do not care who the user is or what rights he havehas, but only need him to be authenticated using any available Authentication Plugin (see Authentication Plugins)
• pp_anonymous
  Only users which are NOT identified have this role - meaning only uses which are not currently logged on.

...

To simplify protecting access to resources, Ceptor allows you to embed additional information into the group name - this functionality is provided by the default Agent Validator (see Creating a custom Custom Agent Validator) and might differ if you use a different authenticator.

...

• <group name>
  This is a plain check for group membership - nothing fancy here - the user is member of the group. or he isn't.
• <group name>.<authentication level>
  In addition to being member of this group, the user needs the minimum <authentication level> specified - this is determined upon authentication by the Authentication Plugin. It is a plain number. In general, the higher the number the more secure it is and the more trust we have in the user being who is claims to be.
• <group name>@<environment>
  When applications are accesssaccess, they can optionally be accessed from different environments - e.g. if you have multiple clusters of Gateway's where some are accessed by employees, others by partners or even others by customers, each can be configured with its own environment ID. If you only wish to allow access to a shared application for identified users where the request originates from a specific environment, you can add the environment ID to the group name here.
• <group name>.<authentication level>@<environment>
  This is a combination of the two above - requires group membership, with a minium minimum specified authentication level and the request needs to have passed through a particular environment.

...

A user that has one of the groups listed and fulfill the fulfil the data policies that might be attached to the ACL is considered to have access to the resource behind the named ACL.

...

With traditional RBAC, the customer has access to the /transfer url, resource or ACL - or he has not - so it is a yes/no decision based upon group membership.

With ABAC, the customers customer's access might depend upon which account he transfers from, what account he transfers to and what amount he is transferring - it might even depend on his daily limit so it depends on previous actions during the day

...