Difference between revisions of "Authorization"
From MgmtWiki
(→Context) |
(→Problems) |
||
| Line 21: | Line 21: | ||
* The first problem with addressing [[Authorization]] is to overcome the legacy view that it is distinct from [[Authentication]]. This goes back to the original source of [[Identity]] in the [[Enterprise]] which could tell [[User]]s what information they needed to supply to be [[Authentication|Authenticated]] to the [[Enterprise]] network. If was fairly simple in the [[Enterprise]] case to build an [[Authorization]] scheme that assumed that the user's [[Identifier]] carried with it all of the information needed to do a simple lookup of that [[Identifier]] in a table of [[Authorization|Authorized]] users at the [[Authorization Service]] to make the access decision. In the simplest case each [[Resource]] service made its own choice about which user had been [[Authorization|Authorized]] access to it. | * The first problem with addressing [[Authorization]] is to overcome the legacy view that it is distinct from [[Authentication]]. This goes back to the original source of [[Identity]] in the [[Enterprise]] which could tell [[User]]s what information they needed to supply to be [[Authentication|Authenticated]] to the [[Enterprise]] network. If was fairly simple in the [[Enterprise]] case to build an [[Authorization]] scheme that assumed that the user's [[Identifier]] carried with it all of the information needed to do a simple lookup of that [[Identifier]] in a table of [[Authorization|Authorized]] users at the [[Authorization Service]] to make the access decision. In the simplest case each [[Resource]] service made its own choice about which user had been [[Authorization|Authorized]] access to it. | ||
* In the decentralized environment of the internet, the services no longer can ask for a complete user [[Identity]]. [[Privacy]] concerns have led to a policy of limiting knowledge of the user to those [[Attribute]]s which are absolutely essential for the [[Authorization Service]] to know in order to provide access. This follows from the enlightenment focus on the [[Identity#Identity_and_Freedom| freedom to control one's own identity]] in the many different roles that a user plays during the day, from family to work to hobbies, all with a different view of the [[Identity]] of the person. | * In the decentralized environment of the internet, the services no longer can ask for a complete user [[Identity]]. [[Privacy]] concerns have led to a policy of limiting knowledge of the user to those [[Attribute]]s which are absolutely essential for the [[Authorization Service]] to know in order to provide access. This follows from the enlightenment focus on the [[Identity#Identity_and_Freedom| freedom to control one's own identity]] in the many different roles that a user plays during the day, from family to work to hobbies, all with a different view of the [[Identity]] of the person. | ||
| − | * The more challenging problem of [[Authorization|Authorizing]] access to a [[Subject]] arriving over the public internet is that the level of [[Authentication]] that has been applied to the [[Subject]] may be adequate for initial access, but is insufficient for full access to all resources. It is that use case which is considered here. For example, as user can be [[Authentication|Authenticated]] at a supplier to purchase goods on site, but then need to | + | * The more challenging problem of [[Authorization|Authorizing]] access to a [[Subject]] arriving over the public internet is that the level of [[Authentication]] that has been applied to the [[Subject]] may be adequate for initial access, but is insufficient for full access to all resources. It is that use case which is considered here. For example, as user can be [[Authentication|Authenticated]] at a supplier to purchase goods on site, but then need to provide proof of age to purchase some restricted good, like drugs, alcohol or sexually explicit material. |
==Solutions== | ==Solutions== | ||
Revision as of 15:20, 26 May 2023
Full Title or Meme
An action that will give a user an Authorization Code or an Access Token to a protected resource.
Context
- Authorization does have other meanings not related to Identity and Access Management
- Previously Authorization was considered to be the second step after the Subject had been successfully Authenticated.
- The challenge of Authorization can be modeled as a decision theory where Authorization of access is granted after the Authorization service has evaluated the Claims presented and made a single decision about access where the Identity of the Subject is assumed to have been appropriately Authentication. In the case of a failed Authorization the Subject was typically given instructions on the appropriated manual procedures to be followed to gain access to the resource. This method worked well within the confines of an Enterprise or Federation that had established the appropriate method for Authentication.
- In the long-term game theory would be a better model where the attacker and the Authorization process are engaged in a duel to gain illicit access to the resource.
Categories
At its core all Authorization decisions are local to the resource being shared. There are a wide range of implementations of Authorization spanning a range of categories that resist being separated. The following is just one suggestion for categorization to help in the reader's understand of the range covered by the term.
- Centralized categories typically are rooted in an Enterprise Risk Assessment. An example would be a Microsoft Active Directory implementing user roles.
- Decentralized categories typically are based on policy or user attributes that are created at a Policy Definition Point (PEP) and then evaluated at the Policy Enforcement Point (PEP).
An alternate categorization that is even less distinct is:
- Role Based Access Control (RBAC) that might implemented as roles contained in an AD user record.
- Attribute Based Access Control (ABAC) where the user attributes are compared with local policy. (Interestingly the user role is one such attribute.)
- Policy Based Access Control (PBAC) where some policy (or business rule) is applied at the PEP. (This could be read to include ABAC. One policy language is XACML.)
Problems
- The first problem with addressing Authorization is to overcome the legacy view that it is distinct from Authentication. This goes back to the original source of Identity in the Enterprise which could tell Users what information they needed to supply to be Authenticated to the Enterprise network. If was fairly simple in the Enterprise case to build an Authorization scheme that assumed that the user's Identifier carried with it all of the information needed to do a simple lookup of that Identifier in a table of Authorized users at the Authorization Service to make the access decision. In the simplest case each Resource service made its own choice about which user had been Authorized access to it.
- In the decentralized environment of the internet, the services no longer can ask for a complete user Identity. Privacy concerns have led to a policy of limiting knowledge of the user to those Attributes which are absolutely essential for the Authorization Service to know in order to provide access. This follows from the enlightenment focus on the freedom to control one's own identity in the many different roles that a user plays during the day, from family to work to hobbies, all with a different view of the Identity of the person.
- The more challenging problem of Authorizing access to a Subject arriving over the public internet is that the level of Authentication that has been applied to the Subject may be adequate for initial access, but is insufficient for full access to all resources. It is that use case which is considered here. For example, as user can be Authenticated at a supplier to purchase goods on site, but then need to provide proof of age to purchase some restricted good, like drugs, alcohol or sexually explicit material.
Solutions
- Bayesian Identity Proofing provides the means for a collection of authentication and verification steps to be validated as an iterative process that can continue until the Authorization to access the resource can be granted.
- Where access needs to be granted over a long period, and the capability to withdraw that access before the Authorization grant expires, additional procedural steps must be implemented. One common method is to issue a refresh token that can be exchanged for a access token at the Authorization Service. In this use case the access can be revoked at the Authorization Service.
