Identity & access management
Trust concepts & identity and authentication
1. Trust
1.1 The concept of trust
• Hard to grasp
• Subjective
• Characteristic of an interaction between individuals
• Define trust: "Firm belief in the reliability, truth, or ability of someone or something.".
1.2 Trustworthy or not?
• Past experiences
• Experiences shared by others
• Trustworthy recommendations
• In order to trust we need Assurance
o This image explains how to gain assurance (trust) in someone else.
o There are two key aspects:
• Intention of the other party – Are they honest and transparent?
• You can check this through openness and shared goals.
• Also by looking at the history of interactions (your past
experiences with them).
• Competency of the other party – Are they capable and skilled?
• You can check this through references (what others say about
them).
• And through attestations by third parties (official confirmations
from others).
o In short:
You build trust by checking both their past behavior and the opinions or confirmations from
others.
1.3 Types of trust
• Mutual trust
r
, • Unidirectional trust
o Unidirectional trust = only one side trusts the other; access is only possible in one
direction.
o contoso.local
trusts
adatum.remote
(direction of trust
arrow).
o This means users
from
adatum.remote
can access
resources in
contoso.local
(direction of
access arrow).
o But not the other way around — contoso.local users cannot access adatum.remote.
1.4 Organization trusting the individual
• The organization can trust most of the people most of the time
• Traditionally covered by information Security
o To manage trust, organizations use security measures:
▪ Risk assessment
• Identifying possible dangers and deciding how to handle them.
▪ Security policy
• Setting rules and guidelines on how employees should handle
information.
▪ ‘Need-to-know’
• Only giving people access to information if they actually need it for their
work, limiting unnecessary exposure.
1.5 User trusting the machine
• The user can trust a machine to do what it’s told to do
• Traditionally covered by IT Security
o Reputation of supplier
o Qualification of developers
o Functional testing
o Penetration testing
▪ Testing if the system can resist hacking attempts.
r
, o Audit and monitoring
▪ Regular checks and constant observation to catch problems.
o Evaluation and certification
• In short: Users trust machines because experts build, test, check, and certify them.
1.6 Machine trusting the user
• Authentication
o The machine checks if the user (or another machine) is really who they claim to be.
▪ Authenticity of the user
▪ Authenticity of the machine
• Authorization
o After authentication, the machine decides what the user is allowed to do.
o Authorizing access to the machine
▪ Allowing user to login
o Authorizing action
▪ Controlling what user can do:
• Create
• Read
• Update
• Delete
2. Identity and authentication
2.1 Identity
• Who are you?
• How can I be sure that you are what you claim to be?
• Attributes define the identity
o Those intrinsic to you when you are born
o Those assigned to you by others
o Those you get as you interact with the world
• An identity can only exist in a community.
o No community = no identity
• A user is a digital representation of an identity.
• A credential provides proof of successful registration, where an identity became a user.
• Consequently, a credential provides proof of identity
2.2 Registering a new identity
2.2.1 Registration
• Generate proof of identity in a community
• ID card
o Username / password
• It creates “User”
o User is the digital representation of an identity for a particular platform
r
, 2.3 Authentication
• Factors in authentication
o Something you know
▪ A pass phrase
▪ A shared secret
o Something you have
▪ A smart card (ex. Belgian ID)
▪ Secure Hardware Token
o Something you are
▪ Fingerprint
▪ Iris scan
▪ Face recognition
2.3.1 Direction in authentication
• Unilateral
o A authenticates to B
o B gets assurances that A is who he claims
to be
• Bilateral
o A authenticates to B
o B authenticates to A
o Both parties get assurance that the other
party is who he/she claims to be
2.3.2 Authentication protocol
• Weak
o Assume, A authenticates to B
o A and B use weak authentication if the credential is “exposed” as part of
the protocol. In other words, the credential is transmitted from A to B,
independent of the format.
o Even if it’s encrypted or in a different format, if the actual secret
(credential) is sent over the connection, it can potentially be intercepted.
o E.g. Basic authentication, form based authentication
• Strong
o Assume, A authenticates to B
o A and B use strong authentication if the credential is never “exposed” as
part of the protocol. In other words, the credential is not transmitted
directtly from A to B.
o System uses methods that prove identity without exposing the secret:
▪ Challenge-response mechanisms
• System sends challenge to user , user must respond in a way
that proves they know the secret — without sending the
secret itself.
• Fixed challenge does not change over time
• One-time fresh challenge fresh for every interaction
• Random
• Sequence
• Time
• E.g. One Time Password
▪ (Short-lived credentials
• Temporary passwords or tokens that expire quickly.
▪ Digital signatures
r
Trust concepts & identity and authentication
1. Trust
1.1 The concept of trust
• Hard to grasp
• Subjective
• Characteristic of an interaction between individuals
• Define trust: "Firm belief in the reliability, truth, or ability of someone or something.".
1.2 Trustworthy or not?
• Past experiences
• Experiences shared by others
• Trustworthy recommendations
• In order to trust we need Assurance
o This image explains how to gain assurance (trust) in someone else.
o There are two key aspects:
• Intention of the other party – Are they honest and transparent?
• You can check this through openness and shared goals.
• Also by looking at the history of interactions (your past
experiences with them).
• Competency of the other party – Are they capable and skilled?
• You can check this through references (what others say about
them).
• And through attestations by third parties (official confirmations
from others).
o In short:
You build trust by checking both their past behavior and the opinions or confirmations from
others.
1.3 Types of trust
• Mutual trust
r
, • Unidirectional trust
o Unidirectional trust = only one side trusts the other; access is only possible in one
direction.
o contoso.local
trusts
adatum.remote
(direction of trust
arrow).
o This means users
from
adatum.remote
can access
resources in
contoso.local
(direction of
access arrow).
o But not the other way around — contoso.local users cannot access adatum.remote.
1.4 Organization trusting the individual
• The organization can trust most of the people most of the time
• Traditionally covered by information Security
o To manage trust, organizations use security measures:
▪ Risk assessment
• Identifying possible dangers and deciding how to handle them.
▪ Security policy
• Setting rules and guidelines on how employees should handle
information.
▪ ‘Need-to-know’
• Only giving people access to information if they actually need it for their
work, limiting unnecessary exposure.
1.5 User trusting the machine
• The user can trust a machine to do what it’s told to do
• Traditionally covered by IT Security
o Reputation of supplier
o Qualification of developers
o Functional testing
o Penetration testing
▪ Testing if the system can resist hacking attempts.
r
, o Audit and monitoring
▪ Regular checks and constant observation to catch problems.
o Evaluation and certification
• In short: Users trust machines because experts build, test, check, and certify them.
1.6 Machine trusting the user
• Authentication
o The machine checks if the user (or another machine) is really who they claim to be.
▪ Authenticity of the user
▪ Authenticity of the machine
• Authorization
o After authentication, the machine decides what the user is allowed to do.
o Authorizing access to the machine
▪ Allowing user to login
o Authorizing action
▪ Controlling what user can do:
• Create
• Read
• Update
• Delete
2. Identity and authentication
2.1 Identity
• Who are you?
• How can I be sure that you are what you claim to be?
• Attributes define the identity
o Those intrinsic to you when you are born
o Those assigned to you by others
o Those you get as you interact with the world
• An identity can only exist in a community.
o No community = no identity
• A user is a digital representation of an identity.
• A credential provides proof of successful registration, where an identity became a user.
• Consequently, a credential provides proof of identity
2.2 Registering a new identity
2.2.1 Registration
• Generate proof of identity in a community
• ID card
o Username / password
• It creates “User”
o User is the digital representation of an identity for a particular platform
r
, 2.3 Authentication
• Factors in authentication
o Something you know
▪ A pass phrase
▪ A shared secret
o Something you have
▪ A smart card (ex. Belgian ID)
▪ Secure Hardware Token
o Something you are
▪ Fingerprint
▪ Iris scan
▪ Face recognition
2.3.1 Direction in authentication
• Unilateral
o A authenticates to B
o B gets assurances that A is who he claims
to be
• Bilateral
o A authenticates to B
o B authenticates to A
o Both parties get assurance that the other
party is who he/she claims to be
2.3.2 Authentication protocol
• Weak
o Assume, A authenticates to B
o A and B use weak authentication if the credential is “exposed” as part of
the protocol. In other words, the credential is transmitted from A to B,
independent of the format.
o Even if it’s encrypted or in a different format, if the actual secret
(credential) is sent over the connection, it can potentially be intercepted.
o E.g. Basic authentication, form based authentication
• Strong
o Assume, A authenticates to B
o A and B use strong authentication if the credential is never “exposed” as
part of the protocol. In other words, the credential is not transmitted
directtly from A to B.
o System uses methods that prove identity without exposing the secret:
▪ Challenge-response mechanisms
• System sends challenge to user , user must respond in a way
that proves they know the secret — without sending the
secret itself.
• Fixed challenge does not change over time
• One-time fresh challenge fresh for every interaction
• Random
• Sequence
• Time
• E.g. One Time Password
▪ (Short-lived credentials
• Temporary passwords or tokens that expire quickly.
▪ Digital signatures
r