BT.Permission Validation

From OIAr Archive 2013
Revision as of 00:22, 12 November 2012 by Jan Schoonderbeek (talk | contribs) (start)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Informational
Informational
Page maturity
This page has maturity level 3 (usable)

This is a Building Block document

Document icon BT Permission Validation Version: 0.3 OIAr logo
Document type: Building Block Type Owner:

J.A.H. Schoonderbeek


Informational
Informational
Create commentary

Description

This Building Block Type belongs to Working Area Middleware (MW). A Permission Validation facility offers the ability to decide on allowing or blocking a proposed action by a digital identity. In essence, it can answer the question "is entity X allowed to perform action Y on object Z?". The facility must be offered an identity attribute representing a digital identity, and a suitable representation of the proposed action and object. The facility then checks the data offered against a set of rules that describe the relevant access policies, and responds with a yes/no (true/false).
An example of an identity attribute would be a username; an example of a proposed action would be "read"; an example of an object would be "a particular file". The Permission Validation facility must respond with a message, either that the action is allowed or not.

Permission Validation is an important part of Authentication and Authorization. Beware, however, that Permission Validation is NOT synonymous to Authorization. Authorization roughly looks like this:

  • For a particular set of resources, e.g. access to the country from abroad, the security officer decides on a required level of authentication, e.g. people must authenticate using a passport.
  • Next, the requirements for allowing or disallowing access are formulated, usually in cooperation between the business and a security officer. The requirements are usually in the form of business rules. As an example: for resource "access to our country", the business rules could be a.o. "not if the identity appears on the list 'wanted terrorists' or 'wanted criminals'", "not when <person appears to be a work migrant> AND <work visa is absent>".
  • Then, the security officer determines or appoints an access point, where permission validation will take place, e.g. a border checkpoint.
  • Finally, a process is put in place to validate the required actions, e.g. the border checkpoint check of the passport name against the database of wanted persons, and the baggage check.

Note that Authorization means that someone (himself authorized to do so) makes decisions on the needed level of authorization, and on the rules that decide on allowing or disallowing access; thus the process of authorization always involves a security officer. Permission validation is only an automated means for part of that process, the correct deployment of which must itself be checked by a security officer.

To validate an action, the Permission Validation facility needs access to one or more Permission Stores. Note that the permission store in itself is not part of the Permission Validation facility.

Icon

The icon below can be used to represent this infrastructure function in graphical Pattern representations that it might be part of:

Icon for this function
Icon for this function


Variants of this Building Block Type

The following variants of this function have been defined:

Semantic query
Semantic query

No Pattern Variants based on this Pattern Type (yet)


Pattern Types using this Building Block Type

The following Pattern Types use this function:

Semantic query
Semantic query
Pattern VariantBrief DescriptionOwnerMaturity
PAT.Authentication+AuthorizationAuthentication & AuthorizationJ.A.H. Schoonderbeek3