Security Concepts: Difference between revisions
| (58 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Internal= | |||
* [[Security]] | |||
* [[Public Key Security#Overview|Public Key Security]] | |||
* [[OAuth 2.0 Concepts]] | |||
=Identity= | |||
The identity could be that of a human using the computer and running programs, or of a automation system. In the first case we qualify the identity as "end-user" or "user" identity, and in the second case we use the terms "[[#System_Account|system account]]" or "[[#Service_Account|service account]]" identity. The identity can be proven by a [[#Certificate|certificate]] or by other means, such as providing a password. | |||
==Established Identity== | |||
An established identity could be some form of [[#Zero-to-One_and_the_First_Key_Problem| zero-to-one attestation]] or a previously issued, trusted certificate. | |||
==Desired Identity== | |||
==Identity Transition== | |||
The process of assuming a [[#Desired_Identity|desired identity]] starting from an [[#Established_Identity|established identity]], through attestation. | |||
==End User Identity== | |||
A human user. | |||
==<span id='Service_Account'></span>Service Account Identity== | |||
==<span id='System_Account'></span>System Account Identity== | |||
==Platform Identity== | |||
The platform identity is the kind of identity information an entity that seeks attestation presents at the very beginning of the attestation process. Usually, this is some sort of hardware identity, which could be theoretically verified against an inventory. Also see [[#Zero-to-One_and_the_First_Key_Problem|Zero to One and the First Key Problem]]. | |||
=Trust= | |||
A claimed identity is useless if it is not trusted by the party. | |||
==Zero-to-One and the First Key Problem== | |||
There is always a moment in the processing of establishing trust when the entity that seeks attestation cannot present any trusted certificate yet, because it doesn't have one. This is the zero-to-one problem. Usually, the entity presents some sort of hardware identity, also referred to as [[#Platform_Identity|platform identity]], which could be theoretically verified against an inventory. | |||
=<span id='Public_Key_Cryptography'></span>Public Key Security= | |||
Public Key security is supported by public key cryptography, also known as ''asymmetrical cryptography'' | |||
{{Internal|Public_Key_Security#Overview|Public Key Security}} | |||
==Public Key== | |||
{{Internal|Public_Key_Security#Public_Key|Public Key Security | Public Key}} | |||
==Private Key== | |||
{{Internal|Public_Key_Security#Private_Key|Public Key Security | Private Key}} | |||
===Key Residency Attestation=== | |||
Key residency attestation is the process by which one peer proves to another that a private key is stored in a certain way. Private keys stored in hardware are usually better protected than software private keys. This kind of attestation helps assessing risk, since a private key stored in hardware are less likely to be copied around. | |||
====Hardware Security Module (HSM)==== | |||
====Secure Enclave Processor (SEP)==== | |||
{{External|https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web}} | |||
Secure Enclave Processor (SEP) is an extension of modern Apple chips used to protect cryptographic keys in Apple devices. A key stored and processed with SEP is considered stored in hardware. | |||
====YubiKey==== | |||
====Software Keys==== | |||
Software keys are keys generated through standard cryptographic software such as <code>[[Openssl_Operations#Generate_a_Private_Key|openssl genpkey]]</code> or <code>[[Openssl_Operations#Generate_an_RSA_Private_Key|openssl genrsa]]</code>. The key material is accessible to the general purpose CPU and it is usually stored either in memory or as files. A software key attestation is a self-signed certificate. | |||
==Certificate== | |||
Certificates are used to prove [[#Identity|identities]]. | |||
{{Internal|Public_Key_Security#Certificate|Public Key Security | Certificate}} | |||
===Certificate Authority=== | |||
{{External|https://en.wikipedia.org/wiki/Certificate_authority}} | |||
===Certificate Signing Request (CSR)=== | |||
{{Internal|Public_Key_Security#Certificate_Signing_Request_.28CSR.29|Public Key Security | Certificate Signing Request (CSR)}} | |||
=Authentication= | =Authentication= | ||
| Line 10: | Line 66: | ||
=Authorization= | =Authorization= | ||
Authorization is the mechanism for granting or denying access to a resource based on identity. | Authorization is the mechanism for granting or denying access to a resource based on identity. | ||
| Line 16: | Line 71: | ||
In JEE, this is usually implemented by matching a principal with a set of actions they are or are not allowed to perform. This mapping is referred as a ''role''. | In JEE, this is usually implemented by matching a principal with a set of actions they are or are not allowed to perform. This mapping is referred as a ''role''. | ||
=Encryption= | |||
<font color=red>TODO https://home.feodorov.com:9443/wiki/Wiki.jsp?page=CryptographicAlgorithms#EncryptionAndDecryption</font> | |||
=SSL/TLS= | |||
{{Internal|TLS|TLS}} | |||
=SSO= | |||
<font color=red>TODO https://home.feodorov.com:9443/wiki/Wiki.jsp?page=SingleSign-On</font> | |||
=LDAP= | |||
<font color=red>TODO https://home.feodorov.com:9443/wiki/Wiki.jsp?page=LDAP</font> | |||
=Security Protocols= | |||
==Authentication Protocols== | |||
* [[SAML]] | |||
* [[OpenID Connect]] | |||
* [[Kerberos]] | |||
==Authorization Delegation Protocols== | |||
* [[OAuth 2.0]] | |||
==Others== | |||
* [[WS-*]] | |||
=To Process= | |||
<font color=darkgray> | |||
Identity Federation and Single Sign-On are related concepts. | |||
Single Sign-On (SSO) systems allow a single user authentication process across multiple IT systems and organizations. SSO is a subset of federated identity management, as it relates only to ''authentication'' and technical interoperability. | |||
''User's presence'' in the system - means that the user identity is associated with the thread that is processing the user's request, and in a way, it is the user that "drives" the thread. The identity is associated with the thread in the form of a ''security context''. | |||
Authentication. The whole point of an authentication protocol is to tell whether the user ''is present'' in the system. | |||
Identity Provider (IdP) and Relying Party (RP). | |||
Authentication protocols, single sign-on, SAML. | |||
Authorization. | |||
</font> | |||
Latest revision as of 23:59, 12 May 2022
Internal
Identity
The identity could be that of a human using the computer and running programs, or of a automation system. In the first case we qualify the identity as "end-user" or "user" identity, and in the second case we use the terms "system account" or "service account" identity. The identity can be proven by a certificate or by other means, such as providing a password.
Established Identity
An established identity could be some form of zero-to-one attestation or a previously issued, trusted certificate.
Desired Identity
Identity Transition
The process of assuming a desired identity starting from an established identity, through attestation.
End User Identity
A human user.
Service Account Identity
System Account Identity
Platform Identity
The platform identity is the kind of identity information an entity that seeks attestation presents at the very beginning of the attestation process. Usually, this is some sort of hardware identity, which could be theoretically verified against an inventory. Also see Zero to One and the First Key Problem.
Trust
A claimed identity is useless if it is not trusted by the party.
Zero-to-One and the First Key Problem
There is always a moment in the processing of establishing trust when the entity that seeks attestation cannot present any trusted certificate yet, because it doesn't have one. This is the zero-to-one problem. Usually, the entity presents some sort of hardware identity, also referred to as platform identity, which could be theoretically verified against an inventory.
Public Key Security
Public Key security is supported by public key cryptography, also known as asymmetrical cryptography
Public Key
Private Key
Key Residency Attestation
Key residency attestation is the process by which one peer proves to another that a private key is stored in a certain way. Private keys stored in hardware are usually better protected than software private keys. This kind of attestation helps assessing risk, since a private key stored in hardware are less likely to be copied around.
Hardware Security Module (HSM)
Secure Enclave Processor (SEP)
Secure Enclave Processor (SEP) is an extension of modern Apple chips used to protect cryptographic keys in Apple devices. A key stored and processed with SEP is considered stored in hardware.
YubiKey
Software Keys
Software keys are keys generated through standard cryptographic software such as openssl genpkey or openssl genrsa. The key material is accessible to the general purpose CPU and it is usually stored either in memory or as files. A software key attestation is a self-signed certificate.
Certificate
Certificates are used to prove identities.
Certificate Authority
Certificate Signing Request (CSR)
Authentication
Authentication is the process of identifying a subject and verifying the authenticity of the identification information.
The most common authentication mechanism is username/password. Other mechanisms are available: public key, shared key, smart cards, etc.
In the context of JEE declarative security, the result of a successful authentication is called a principal.
Related subjects: Basic and Digest HTTP Authentication.
Authorization
Authorization is the mechanism for granting or denying access to a resource based on identity.
In JEE, this is usually implemented by matching a principal with a set of actions they are or are not allowed to perform. This mapping is referred as a role.
Encryption
TODO https://home.feodorov.com:9443/wiki/Wiki.jsp?page=CryptographicAlgorithms#EncryptionAndDecryption
SSL/TLS
SSO
TODO https://home.feodorov.com:9443/wiki/Wiki.jsp?page=SingleSign-On
LDAP
TODO https://home.feodorov.com:9443/wiki/Wiki.jsp?page=LDAP
Security Protocols
Authentication Protocols
Authorization Delegation Protocols
Others
To Process
Identity Federation and Single Sign-On are related concepts.
Single Sign-On (SSO) systems allow a single user authentication process across multiple IT systems and organizations. SSO is a subset of federated identity management, as it relates only to authentication and technical interoperability.
User's presence in the system - means that the user identity is associated with the thread that is processing the user's request, and in a way, it is the user that "drives" the thread. The identity is associated with the thread in the form of a security context.
Authentication. The whole point of an authentication protocol is to tell whether the user is present in the system.
Identity Provider (IdP) and Relying Party (RP).
Authentication protocols, single sign-on, SAML.
Authorization.