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.

...

• Authorization checking can be done before the application is called, e.g. by the Ceptor Gateway
• It can also be done within an application server, before the application logic is called - see Application Server Integrations - decisions might be based upon deployment descriptors, policies etc. depending on what application server is used and what level of authorization it offers.
• It can also be done inside the application either by a filter (e.g. Servlet Filter) which intercepts the call before the application logic is invoked, or it can be done inside the application by specifically doing access checking.
  • When done by the application, it can be via standard techniques like HttpServletRequest.isUserInRole(), Principal.isInRole() etc. where Application Server Integrations is used.
  • ... or it can be done by calling the Ceptor Agent API directly, e.g. Agent.getInstance().isMemberOfGroup(), Agent.getInstance().isURLAllowed() or Agent.getInstance.checkPermission()

RBAC (Role-Based Access Control)

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.

...

An ACL might have a number of data policies attached to it that is used for Attribute-Based Access Control (ABAC) or it might only be a simple ACL with simple group membership.

...

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.

...

Note that the view of DataPolicyEntry above is somewhat simplified - in reality, it contains several more attributes such as java class/methods names, C program / function names etc. that are used depending on what policy implementations are in use.

ABAC (Attribute-Based Access Control)

Attribute-Based Access Control or ABAC differs from RBAC in the sense that access decisions are based upon attributes, it can be anything from department or job function to haircolor, shoesize or time of day.

...

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

...