GF.Permission Validation
 | Page maturity This page has maturity level 3 (usable) |
|
GF | Permission Validation | Version: | 0.4 | 
|
|---|---|---|---|---|---|
| Document type: | Generic Function | Owner: |
 | This function offers the ability to decide on allowing or disallowing a proposed action by a digital identity on a specified resource. |
Description
This Generic Function belongs to Working Area Middleware.
This function offers the ability to decide on allowing or disallowing a proposed action by a digital identity on a specified resource. 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 "file". The Permission Validation facility must respond with a message, either that the action is allowed, or that it is not.
To validate an action, the Permission Validation facility needs access to one or more Permission Registers. Note that the Permission Register in itself is not part of the Permission Validation facility.
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. It is in this last step where Permission Validation functionality plays a role.
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.
Icon
The image "Icon GF Permission Validation.png" (shown below) can be used to represent this infrastructure function in graphical Pattern representations that it might be part of:
Generic Patterns using this Generic Function
The following Generic Patterns use this function:
| Applied Pattern | Owner | Maturity |
|---|---|---|
| Authentication & Authorization | J.A.H. Schoonderbeek | 3 |
Applied versions of this Generic Function
The following variants of this function have been defined:
No Applied Pattern based on this Generic Pattern (yet)
