This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 32 lines
!!! Overview
[{$pagename}] ([APAM]) is a [Policy Based Management System] for [Access Control] where [Policies|Policy] are applied at runtime to make [Authorization] decisions based on [Contextual Attributes] in the broadest sense.
[{$pagename}] is part of the broader [User and Entity Behavior Analytics] as applied to [Adaptive Risk] or [Risk Based Access Control].
!! Adaptive Policy-based Access Management (APAM): The Future of Authentication and Authorization[1]
Over the past several years, there have been a lot of discussions around terms such as [RBAC] ([Role Based Access Control]), [ABAC] ([Attribute Based Access Control]), [Dynamic Authorization Management] ([DAM]) and standards such as [XACML]. Other terms such as [Risk Based Access Control] ([RiskBAC]) have been introduced more recently.
Quite frequently, there has been a debate between [RBAC] and [ABAC], as to whether attributes should or must replace roles. However, most [RBAC] approaches in practice rely on more than purely role (i.e. on other attributes), while roles are a common attribute in [ABAC]. In practice, it is not [RBAC] vs. [ABAC], but rather a sort of continuum.
However, the main issue in trying to position [ABAC] as the antipode to [RBAC] is that attributes vs. roles is not what the discussion should be about. The difference is in how [access|Access Control] is granted.
Some years ago, I introduced the term "[Dynamic Authorization Management]” for what some vendors called "[Entitlement] Management", while others used the term of "[Policy Based Management System]". This has been about the contrast of doing [authorizations] based on statically defined [entitlements] (such as in system that rely on [ACL]s, i.e. [Access Control List], e.g. Windows Server) and authorization decisions made at runtime based on policies and context information such as the user, his roles, etc. – in fact a number of attributes.
Even longer ago, the term PBAC had been introduced, With the A in PBAC standing for “admission”, because PBAC was a standard introduced at the network level.
However, you could also argue that systems such as the SAP ERP systems or Windows File Servers do authorizations dynamically, for instance in Windows by comparing ACLs with SIDs contained in the Kerberos token. Nevertheless, the __entitlements are set statically__. Admittedly, after various discussions with end users, the term “dynamic” appears to not be clear enough for distinguishing various approaches.
While common, __static__ approaches at best translate policies in __static entitlements__, this step is lacking in what I now will call [{$pagename}] ([APAM]). And that is what really makes the difference: [Policies|Policy], applied at runtime to make decisions based on [context] in the broadest sense. Whether these are roles, IP addresses, claims, or whatever – this is the essence of the entire discussion that we have seen going on for years now.
It is not a question of whether [RBAC] or [ABAC] is right. It is about moving towards APAM. The advantages of APAM are obvious:
* [APAM] by default is a security service, i.e. externalizes security from the applications (theoretically, such a concept might be implemented into applications, but there is little sense in doing so).
* [APAM] will automatically reflect [policy] changes. Policies,
* [APAM] when implemented right, can be expressed in a business-friendly notation.
* [APAM] is adaptive, e.g. it takes the context into account.
All the aspects we had discussed as advantages for Dynamic Authorization Management logically apply to APAM, because this is just a new term for what KuppingerCole previously named Dynamic Authorization Management. Admittedly, it is a better term.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Adaptive Policy-based Access Management (APAM): The Future of Authentication and Authorization|https://www.kuppingercole.com/blog/kuppinger/adaptive-policy-based-access-management|target='_blank'] - based on information obtained 2015-10-10