Difference between revisions of "Authorization"
From MgmtWiki
(→Problems) |
(→Problems) |
||
| Line 9: | Line 9: | ||
==Problems== | ==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 [[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 | * 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 | ||
| − | * In the decentralized environment of the internet, the services no longer can ask for a complete user [[Identity]]. [[Privacy]] concerns have | + | * 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. | * 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. | ||
Revision as of 10:43, 4 January 2019
Full Title or Meme
An action that will give a user an Authorization Code or an Access Token to a protected resource.
Context
- 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 haven been appropriately Authentication. In the case of a failed Authorization the Subject was typically given instructions on the appropriated manual procedures to be follow 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.
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
- 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.
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.
