WEBVTT

1
00:00:00.090 --> 00:00:01.230
In this lesson,

2
00:00:01.230 --> 00:00:04.800
we will learn about identity and authentication.

3
00:00:04.800 --> 00:00:06.720
Identity and authentication

4
00:00:06.720 --> 00:00:09.780
involve verifying a user's identity

5
00:00:09.780 --> 00:00:11.670
to ensure they are authorized

6
00:00:11.670 --> 00:00:15.270
to access resources and perform actions.

7
00:00:15.270 --> 00:00:19.890
Identity and authentication concepts include attestations,

8
00:00:19.890 --> 00:00:22.440
single sign-on, federation,

9
00:00:22.440 --> 00:00:25.830
identity providers and service providers.

10
00:00:25.830 --> 00:00:28.260
Let's learn more about these identity

11
00:00:28.260 --> 00:00:30.750
and authentication concepts.

12
00:00:30.750 --> 00:00:33.270
First, we have identity providers.

13
00:00:33.270 --> 00:00:36.060
In the world of identity and authentication,

14
00:00:36.060 --> 00:00:38.640
identity providers play a central role

15
00:00:38.640 --> 00:00:42.990
in managing users' identities across multiple systems.

16
00:00:42.990 --> 00:00:46.980
A real world example of an identity provider is Google,

17
00:00:46.980 --> 00:00:48.300
which allows users

18
00:00:48.300 --> 00:00:52.680
to log into various services using their Google credentials.

19
00:00:52.680 --> 00:00:55.530
Google manages the authentication process,

20
00:00:55.530 --> 00:00:57.630
ensuring that the user's identity

21
00:00:57.630 --> 00:01:01.680
is verified before granting access to resources.

22
00:01:01.680 --> 00:01:03.720
By centralizing authentication,

23
00:01:03.720 --> 00:01:07.110
an identity provider simplifies user management

24
00:01:07.110 --> 00:01:08.910
across multiple platforms

25
00:01:08.910 --> 00:01:12.180
while maintaining security and consistency.

26
00:01:12.180 --> 00:01:15.300
Second, we have single sign-on or SSO.

27
00:01:15.300 --> 00:01:19.680
Once a user's identity is verified by an identity provider,

28
00:01:19.680 --> 00:01:23.280
single sign-on lets them access multiple applications

29
00:01:23.280 --> 00:01:27.600
or services within the same domain without logging in again.

30
00:01:27.600 --> 00:01:29.970
This makes things easier for users

31
00:01:29.970 --> 00:01:32.760
because they only need to authenticate once,

32
00:01:32.760 --> 00:01:35.160
usually when logging into their computer

33
00:01:35.160 --> 00:01:37.920
or when getting access to a resource.

34
00:01:37.920 --> 00:01:41.100
After that, they can access systems like email,

35
00:01:41.100 --> 00:01:44.160
file servers, or internal applications

36
00:01:44.160 --> 00:01:47.370
without having to enter those credentials again.

37
00:01:47.370 --> 00:01:50.640
The systems that depend on the identity provider

38
00:01:50.640 --> 00:01:53.850
for authentication are called service providers.

39
00:01:53.850 --> 00:01:55.920
We will discuss service providers

40
00:01:55.920 --> 00:01:58.140
in more detail a bit later.

41
00:01:58.140 --> 00:02:01.020
One common protocol that facilitates sign-on

42
00:02:01.020 --> 00:02:03.960
in enterprise environments is Kerberos.

43
00:02:03.960 --> 00:02:06.510
Kerboros is widely used in systems

44
00:02:06.510 --> 00:02:09.390
like Microsoft Active Directory to secure

45
00:02:09.390 --> 00:02:13.050
and manage single sign-on within a corporate network.

46
00:02:13.050 --> 00:02:16.890
When a user logs in, the Kerberos Key Distribution Center,

47
00:02:16.890 --> 00:02:21.750
or KDC, issues the user a Ticket Granting Ticket or a TGT

48
00:02:21.750 --> 00:02:24.270
after verifying the user's identity.

49
00:02:24.270 --> 00:02:27.210
This Ticket Granting Ticket allows the user

50
00:02:27.210 --> 00:02:30.120
to request access to multiple services

51
00:02:30.120 --> 00:02:33.180
without needing to enter their credentials again.

52
00:02:33.180 --> 00:02:36.750
The client then uses the Ticket Granting Ticket

53
00:02:36.750 --> 00:02:38.670
to request a service ticket

54
00:02:38.670 --> 00:02:42.540
from the Key Distribution Center's Ticket Granting Service

55
00:02:42.540 --> 00:02:44.490
or TGS for each service

56
00:02:44.490 --> 00:02:46.740
or resource that they need access to.

57
00:02:46.740 --> 00:02:49.770
The client can then present the service ticket,

58
00:02:49.770 --> 00:02:50.940
which they receive

59
00:02:50.940 --> 00:02:54.210
from the Key Distribution Center's Ticket Granting Service

60
00:02:54.210 --> 00:02:57.090
to applications, which are service providers,

61
00:02:57.090 --> 00:03:01.050
ensuring they can access resources like email, file storage,

62
00:03:01.050 --> 00:03:04.800
or internal applications without re-authenticating.

63
00:03:04.800 --> 00:03:08.520
Another protocol used to facilitate single sign-on

64
00:03:08.520 --> 00:03:11.790
and federated identity management is shibboleth.

65
00:03:11.790 --> 00:03:14.400
Shibboleth is an open source solution

66
00:03:14.400 --> 00:03:17.100
that allows users to authenticate once

67
00:03:17.100 --> 00:03:20.730
and access resources across multiple organizations

68
00:03:20.730 --> 00:03:23.580
without revealing their individual identity

69
00:03:23.580 --> 00:03:25.350
to the service provider.

70
00:03:25.350 --> 00:03:29.190
This is especially useful when privacy is a concern.

71
00:03:29.190 --> 00:03:31.530
In this case, the origin server

72
00:03:31.530 --> 00:03:35.340
verifies the user's identity, but the target server,

73
00:03:35.340 --> 00:03:39.090
which is the service provider, only receives confirmation

74
00:03:39.090 --> 00:03:41.070
that the user has been authenticated

75
00:03:41.070 --> 00:03:44.730
without any additional identifying information.

76
00:03:44.730 --> 00:03:46.950
This protects the user's privacy

77
00:03:46.950 --> 00:03:50.220
while ensuring secure access to resources.

78
00:03:50.220 --> 00:03:52.740
Third, we have service providers.

79
00:03:52.740 --> 00:03:55.170
These are the applications or systems

80
00:03:55.170 --> 00:03:59.190
that rely on an identity provider for authentication.

81
00:03:59.190 --> 00:04:02.280
In a domain, service providers include tools

82
00:04:02.280 --> 00:04:04.530
that are used for different purposes.

83
00:04:04.530 --> 00:04:07.320
For example, service providers in a company

84
00:04:07.320 --> 00:04:11.460
may include the company's messaging platform, shared drives,

85
00:04:11.460 --> 00:04:14.190
and customer relationship management systems.

86
00:04:14.190 --> 00:04:17.940
All of these services use the same identity provider

87
00:04:17.940 --> 00:04:20.040
to manage user access.

88
00:04:20.040 --> 00:04:23.310
Service providers trust the identity provider

89
00:04:23.310 --> 00:04:25.200
to authenticate the user

90
00:04:25.200 --> 00:04:29.640
and deliver an attestation that the user has been verified.

91
00:04:29.640 --> 00:04:32.280
The service provider then grants access

92
00:04:32.280 --> 00:04:35.220
based on the user's verified identity.

93
00:04:35.220 --> 00:04:39.420
Examples of service providers include platforms like Slack,

94
00:04:39.420 --> 00:04:42.630
Dropbox, or Salesforce, which allow users

95
00:04:42.630 --> 00:04:45.000
to log in using their Google

96
00:04:45.000 --> 00:04:47.910
or other identity provider credentials.

97
00:04:47.910 --> 00:04:50.070
This division of responsibilities

98
00:04:50.070 --> 00:04:52.320
makes it easier for service providers

99
00:04:52.320 --> 00:04:55.350
to manage access while maintaining security

100
00:04:55.350 --> 00:04:58.740
as they delegate the identity verification process

101
00:04:58.740 --> 00:05:00.955
to trusted identity providers.

102
00:05:00.955 --> 00:05:05.400
In some systems, JavaScript Object Notation Web Tokens

103
00:05:05.400 --> 00:05:08.340
or JWTs, pronounced jots,

104
00:05:08.340 --> 00:05:11.490
are used to transfer this authentication information

105
00:05:11.490 --> 00:05:14.880
between the identity provider and the service provider.

106
00:05:14.880 --> 00:05:17.370
A JWT contains key information

107
00:05:17.370 --> 00:05:20.160
about the user in a JSON format

108
00:05:20.160 --> 00:05:22.890
or JavaScript Object Notation format,

109
00:05:22.890 --> 00:05:24.930
and is signed for security.

110
00:05:24.930 --> 00:05:29.850
The JWT allows service providers to verify a user's identity

111
00:05:29.850 --> 00:05:33.600
and authorize access to the necessary resources,

112
00:05:33.600 --> 00:05:37.140
simplifying the interaction between systems.

113
00:05:37.140 --> 00:05:39.210
Fourth, we have federation.

114
00:05:39.210 --> 00:05:42.840
Federation builds on the concept of single sign-on

115
00:05:42.840 --> 00:05:45.360
by enabling multiple organizations

116
00:05:45.360 --> 00:05:47.970
to collaborate on identity management.

117
00:05:47.970 --> 00:05:49.710
In a federated environment,

118
00:05:49.710 --> 00:05:53.280
organizations trust a common identity provider

119
00:05:53.280 --> 00:05:54.840
for authentication.

120
00:05:54.840 --> 00:05:58.740
An example of federation is the eduGAIN network,

121
00:05:58.740 --> 00:06:02.580
which connects national identity federations in the research

122
00:06:02.580 --> 00:06:05.160
and education sectors globally.

123
00:06:05.160 --> 00:06:07.800
This allows students, researchers,

124
00:06:07.800 --> 00:06:10.590
and staff from different universities

125
00:06:10.590 --> 00:06:12.810
to access shared services

126
00:06:12.810 --> 00:06:15.810
using their home institution's credentials.

127
00:06:15.810 --> 00:06:18.480
Federation agreements establish trust

128
00:06:18.480 --> 00:06:22.020
and ensure secure access across institutions

129
00:06:22.020 --> 00:06:25.740
by adhering to common identity and security standards.

130
00:06:25.740 --> 00:06:27.240
In a federated system,

131
00:06:27.240 --> 00:06:31.320
trust can also extend across multiple federations.

132
00:06:31.320 --> 00:06:33.780
This is called transitive trust.

133
00:06:33.780 --> 00:06:36.870
Transitive trust means that if federation A

134
00:06:36.870 --> 00:06:41.580
trusts federation B, and federation B trust federation C,

135
00:06:41.580 --> 00:06:46.580
then federation A automatically trusts federation C.

136
00:06:46.710 --> 00:06:50.640
This allows users authenticated in federation A

137
00:06:50.640 --> 00:06:53.970
to access resources in federation C

138
00:06:53.970 --> 00:06:56.760
without needing additional authentication,

139
00:06:56.760 --> 00:06:58.920
even though federation A

140
00:06:58.920 --> 00:07:03.540
and federation C do not have a direct trust relationship.

141
00:07:03.540 --> 00:07:05.070
This layered trust system

142
00:07:05.070 --> 00:07:07.232
extends across multiple federations

143
00:07:07.232 --> 00:07:11.340
and further streamlines cross-organizational access.

144
00:07:11.340 --> 00:07:14.940
It allows users to securely access resources

145
00:07:14.940 --> 00:07:17.850
across multiple institutions or sectors,

146
00:07:17.850 --> 00:07:20.280
maintaining the same level of security

147
00:07:20.280 --> 00:07:23.490
and trust as within a single federation.

148
00:07:23.490 --> 00:07:26.790
Fifth and last, we have attestation

149
00:07:26.790 --> 00:07:28.980
to ensure that trust is maintained.

150
00:07:28.980 --> 00:07:33.300
Attestations are used to communicate identity verification

151
00:07:33.300 --> 00:07:36.750
between an identity provider and a service provider.

152
00:07:36.750 --> 00:07:38.309
Attestation is a message

153
00:07:38.309 --> 00:07:42.120
sent by the identity provider to the service provider

154
00:07:42.120 --> 00:07:45.030
that confirms the user has been authenticated

155
00:07:45.030 --> 00:07:48.450
and specifies what access rights they have.

156
00:07:48.450 --> 00:07:52.080
For example, when you log into a service provider

157
00:07:52.080 --> 00:07:56.220
using Google, the identity provider sends an attestation

158
00:07:56.220 --> 00:07:58.920
that tells the service provider who you are

159
00:07:58.920 --> 00:08:00.928
and what level of access you have.

160
00:08:00.928 --> 00:08:03.960
These attestations can be transmitted

161
00:08:03.960 --> 00:08:06.780
using various protocols like SAML

162
00:08:06.780 --> 00:08:09.570
or the Security Assertion Markup Language,

163
00:08:09.570 --> 00:08:11.670
OpenID, or others.

164
00:08:11.670 --> 00:08:14.880
In the case of the Security Assertion Markup Language

165
00:08:14.880 --> 00:08:19.530
or SAML, the attestation is in an extensible markup language

166
00:08:19.530 --> 00:08:23.220
or XML-based message that contains information

167
00:08:23.220 --> 00:08:26.160
about the user's identity and permissions.

168
00:08:26.160 --> 00:08:28.170
This allows the service provider

169
00:08:28.170 --> 00:08:31.500
to trust that the user has been properly verified

170
00:08:31.500 --> 00:08:35.400
without handling the authentication process itself.

171
00:08:35.400 --> 00:08:39.120
So, remember, identity and authentication

172
00:08:39.120 --> 00:08:42.240
involve verifying a user's identity

173
00:08:42.240 --> 00:08:44.160
to ensure they are authorized

174
00:08:44.160 --> 00:08:47.700
to access resources and perform actions.

175
00:08:47.700 --> 00:08:52.020
Key concepts include attestations, single sign-on,

176
00:08:52.020 --> 00:08:56.220
federation, identity providers, and service providers.

177
00:08:56.220 --> 00:09:00.600
These elements work together to simplify access management

178
00:09:00.600 --> 00:09:03.180
and enhance security across systems.

179
00:09:03.180 --> 00:09:06.210
Identity providers manage user identities

180
00:09:06.210 --> 00:09:08.460
while SSO allows users

181
00:09:08.460 --> 00:09:12.780
to access multiple services after a single authentication.

182
00:09:12.780 --> 00:09:13.920
In a federation,

183
00:09:13.920 --> 00:09:17.010
organizations collaborate to manage identities,

184
00:09:17.010 --> 00:09:19.590
allowing users to access resources

185
00:09:19.590 --> 00:09:22.170
across different institutions securely

186
00:09:22.170 --> 00:09:24.513
through shared trust agreements.