Difference between revisions of "Access Control"
From MgmtWiki
(→Full Title or Meme) |
(→Context) |
||
| (17 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | [[ | + | [[Authorization]] of [[Access]] to a Resource has evolved from ancient locks and guards to today’s digital authentication and authorization systems. It began with physical barriers thousands of years ago and now encompasses complex electronic and cloud‑based frameworks. |
==Context== | ==Context== | ||
| + | ===Historical=== | ||
| + | * 4000 BCE (Mesopotamia): The earliest known wooden locks discovered in Iraq.<ref>SC DataCom, ''From Keys to Credentials: The History of Access Control'' https://www.scdatacom.net/blog/from-keys-to-credentials-the-history-of-access-controlnbsp</ref> | ||
| + | * Egypt (c. 2000 BCE): Wooden pin locks used to secure temples and valuables. | ||
| + | * Roman Era: Romans refined Greek wooden locks into metal keys and padlocks, later improved by the Chinese for trade routes. | ||
| + | * Medieval Europe: Heavy wrought‑iron padlocks (870–890 CE) and physical defenses like moats, drawbridges, and watchtowers served as access control. | ||
| + | * Passwords & Guards: Verbal passwords and guard shifts were used to restrict entry, foreshadowing identity management | ||
| + | ===Digital=== | ||
There are a variety of reasons to limit access to a resource on the web. The primary ones are: | There are a variety of reasons to limit access to a resource on the web. The primary ones are: | ||
| − | # | + | # Embarrassment - there are some things we just don't want others to know about us. |
# Financial - there are some things that we want to make a profit from releasing. | # Financial - there are some things that we want to make a profit from releasing. | ||
| + | |||
| + | ==Problems== | ||
| + | Security boundaries seem to be mixing two security features which basically describes why cross-site scripting attacks are so common. The basic rule is this - Don't mix control messages with data messages. The two rules are: | ||
| + | # Bell–LaPadula model focuses on data confidentiality (privacy - MAC = Mandatory Access Control) | ||
| + | # Biba Integrity Model is for the protection of data integrity (control - MIC = Mandatory Integrity Control) | ||
| + | Applying both rules means that no security boundary should be crossed without clear permission to do so. And a security policy that allows data flow (MAC) should not allow control flow (MIC). | ||
| + | So, security boundaries need to distinguish between the two. | ||
| + | *As a side note Microsoft Vista UAC (user access control) is not a boundary of any sort, it is a UX that applies policy to override MAC. (Tom Jones wrote the spec.) | ||
| + | *It is the rainbow books that described MAC & MIC rules. | ||
| + | |||
| + | ==Solutions== | ||
| + | In general the wiki page on [[Authorization]] deals with [[Access Control]] in an [[Identity Management]] ecosystem. | ||
| + | |||
| + | In the following cases [[Access Control]] is addressed independently from [[Identity Management]]. | ||
| + | |||
| + | Also note that the use of [[Verifiable Credential]]s can be tied to a one-time or [[Pseudonym]] thus avoiding any [[Identity Management]] between the holder and the verifier. | ||
| + | |||
| + | ===Access Control Encryption=== | ||
| + | or ACE is a scheme for using attribute encryption to acquire access.<ref>Made Sedaghat +1, ''Cross-Domain Attribute-Based Access Control Encryption'' in ''Cryptology and Network Security'' Springer ISBN 9783030925475</ref> | ||
==References== | ==References== | ||
| + | <references /> | ||
| + | ===Other Material=== | ||
| + | * See wiki page on [[Access Token]]. | ||
| + | |||
| + | [[Category: Authorization]] | ||
| + | |||
| + | |||
| + | [[Category: Glossary]] | ||
| + | [[Category: Policy]] | ||
[[Category: Authorization]] | [[Category: Authorization]] | ||
Latest revision as of 15:28, 30 November 2025
Contents
Full Title or Meme
Authorization of Access to a Resource has evolved from ancient locks and guards to today’s digital authentication and authorization systems. It began with physical barriers thousands of years ago and now encompasses complex electronic and cloud‑based frameworks.
Context
Historical
- 4000 BCE (Mesopotamia): The earliest known wooden locks discovered in Iraq.[1]
- Egypt (c. 2000 BCE): Wooden pin locks used to secure temples and valuables.
- Roman Era: Romans refined Greek wooden locks into metal keys and padlocks, later improved by the Chinese for trade routes.
- Medieval Europe: Heavy wrought‑iron padlocks (870–890 CE) and physical defenses like moats, drawbridges, and watchtowers served as access control.
- Passwords & Guards: Verbal passwords and guard shifts were used to restrict entry, foreshadowing identity management
Digital
There are a variety of reasons to limit access to a resource on the web. The primary ones are:
- Embarrassment - there are some things we just don't want others to know about us.
- Financial - there are some things that we want to make a profit from releasing.
Problems
Security boundaries seem to be mixing two security features which basically describes why cross-site scripting attacks are so common. The basic rule is this - Don't mix control messages with data messages. The two rules are:
- Bell–LaPadula model focuses on data confidentiality (privacy - MAC = Mandatory Access Control)
- Biba Integrity Model is for the protection of data integrity (control - MIC = Mandatory Integrity Control)
Applying both rules means that no security boundary should be crossed without clear permission to do so. And a security policy that allows data flow (MAC) should not allow control flow (MIC). So, security boundaries need to distinguish between the two.
- As a side note Microsoft Vista UAC (user access control) is not a boundary of any sort, it is a UX that applies policy to override MAC. (Tom Jones wrote the spec.)
- It is the rainbow books that described MAC & MIC rules.
Solutions
In general the wiki page on Authorization deals with Access Control in an Identity Management ecosystem.
In the following cases Access Control is addressed independently from Identity Management.
Also note that the use of Verifiable Credentials can be tied to a one-time or Pseudonym thus avoiding any Identity Management between the holder and the verifier.
Access Control Encryption
or ACE is a scheme for using attribute encryption to acquire access.[2]
References
- ↑ SC DataCom, From Keys to Credentials: The History of Access Control https://www.scdatacom.net/blog/from-keys-to-credentials-the-history-of-access-controlnbsp
- ↑ Made Sedaghat +1, Cross-Domain Attribute-Based Access Control Encryption in Cryptology and Network Security Springer ISBN 9783030925475
Other Material
- See wiki page on Access Token.
