1
00:00:06,480 --> 00:00:08,640
- In this lesson 19.2,

2
00:00:08,640 --> 00:00:11,073
we're gonna take a look
at federated identity.

3
00:00:12,090 --> 00:00:13,530
Before we start talking about federated,

4
00:00:13,530 --> 00:00:15,810
let's just define SSO.

5
00:00:15,810 --> 00:00:17,430
SSO or single sign-on,

6
00:00:17,430 --> 00:00:19,530
we've used for quite a long
time in our environments,

7
00:00:19,530 --> 00:00:22,380
and often we refer to the older version,

8
00:00:22,380 --> 00:00:25,410
of SSO as a legacy single sign-on.

9
00:00:25,410 --> 00:00:27,780
Now, the idea of single
sign-on was that users

10
00:00:27,780 --> 00:00:30,540
could access multiple applications,

11
00:00:30,540 --> 00:00:33,210
within the same organization,

12
00:00:33,210 --> 00:00:36,540
or domain using a single
set of credentials.

13
00:00:36,540 --> 00:00:38,310
You would have a single sign-on server,

14
00:00:38,310 --> 00:00:39,690
who would act as a proxy,

15
00:00:39,690 --> 00:00:42,960
and you would only need to
have one set of credentials,

16
00:00:42,960 --> 00:00:46,140
and the proxy server would on your behalf,

17
00:00:46,140 --> 00:00:50,280
actually authenticate you
to different applications.

18
00:00:50,280 --> 00:00:53,910
So that worked, I don't know,
maybe about 80% of the time,

19
00:00:53,910 --> 00:00:55,170
but what a great idea,

20
00:00:55,170 --> 00:00:57,600
not to have to have different
sets of credentials,

21
00:00:57,600 --> 00:01:00,000
when you're logging into
different applications.

22
00:01:01,110 --> 00:01:04,680
Well, federated identity
goes a step further.

23
00:01:04,680 --> 00:01:06,960
Federated identity enables users,

24
00:01:06,960 --> 00:01:09,990
to access applications or platforms,

25
00:01:09,990 --> 00:01:13,140
across multiple enterprise domains,

26
00:01:13,140 --> 00:01:15,780
that are part of a
federated configuration,

27
00:01:15,780 --> 00:01:18,150
using a single set of credentials,

28
00:01:18,150 --> 00:01:21,120
and that's referred to
as a portable identity.

29
00:01:21,120 --> 00:01:23,010
So just to be clear for the difference,

30
00:01:23,010 --> 00:01:25,380
legacy single sign-on where the users

31
00:01:25,380 --> 00:01:29,430
would access multiple applications within

32
00:01:29,430 --> 00:01:31,830
the same organization or domain,

33
00:01:31,830 --> 00:01:34,050
using a single set of credentials,

34
00:01:34,050 --> 00:01:36,156
with federated identity,

35
00:01:36,156 --> 00:01:38,820
it enables users to access applications,

36
00:01:38,820 --> 00:01:41,640
across multiple enterprise domains,

37
00:01:41,640 --> 00:01:43,980
that are part of a
federated configuration,

38
00:01:43,980 --> 00:01:46,050
using a single set of credentials.

39
00:01:46,050 --> 00:01:49,140
So they're independent
organizations, right?

40
00:01:49,140 --> 00:01:50,133
Independent.

41
00:01:51,000 --> 00:01:53,790
Now, a federated configuration
is just a configuration,

42
00:01:53,790 --> 00:01:55,290
in which resources belong,

43
00:01:55,290 --> 00:01:58,114
to different organizational entities,

44
00:01:58,114 --> 00:01:59,633
so they're not related to each other.

45
00:02:01,560 --> 00:02:05,040
Federated identity management
refers to the processes

46
00:02:05,040 --> 00:02:08,820
and technologies involved
in managing user identities,

47
00:02:08,820 --> 00:02:13,383
access rights, and permissions,
across federated systems.

48
00:02:14,430 --> 00:02:16,800
Now, federated identity
management, or FIM,

49
00:02:16,800 --> 00:02:20,040
includes identity
provisioning authentication,

50
00:02:20,040 --> 00:02:23,100
which is proving your
identity to be genuine,

51
00:02:23,100 --> 00:02:24,780
authorization which is the assignment,

52
00:02:24,780 --> 00:02:27,390
of rights and permissions
and attribute sharing,

53
00:02:27,390 --> 00:02:29,880
between participating systems.

54
00:02:29,880 --> 00:02:32,160
Now, the technologies
used to implement FIM,

55
00:02:32,160 --> 00:02:34,290
includes security
assertion markup language,

56
00:02:34,290 --> 00:02:37,500
known as SAML and OAuth 2.0.

57
00:02:37,500 --> 00:02:40,267
So we're gonna dive
deep into both of those.

58
00:02:40,267 --> 00:02:42,000
I wanted you to understand how SAML works,

59
00:02:42,000 --> 00:02:44,073
and how OAuth 2.0 works.

60
00:02:46,740 --> 00:02:50,220
Now, SAML is an XML based open standard,

61
00:02:50,220 --> 00:02:52,140
for exchanging authentication.

62
00:02:52,140 --> 00:02:55,383
That's proving your identity
be genuine, and authorization,

63
00:02:56,278 --> 00:02:58,331
which is assignment of
rights and permissions,

64
00:02:58,331 --> 00:03:01,800
data between a service provider
and an identity provider.

65
00:03:01,800 --> 00:03:03,300
So we start with a user.

66
00:03:03,300 --> 00:03:05,370
We have our user that's a subject,

67
00:03:05,370 --> 00:03:08,340
who needs access to multiple
systems or services,

68
00:03:08,340 --> 00:03:12,423
remember, independent ones with
a single set of credentials.

69
00:03:13,320 --> 00:03:15,840
Then we're going to have
an identity provider.

70
00:03:15,840 --> 00:03:18,600
Now the identity provider
is going to be the system

71
00:03:18,600 --> 00:03:21,870
responsible for authenticating
the user's identity,

72
00:03:21,870 --> 00:03:26,163
and then identity provider will
serve multiple enterprises.

73
00:03:27,360 --> 00:03:30,363
And then we have our
service provider, or our SP,

74
00:03:31,200 --> 00:03:33,930
that's the system or the
application that the user wants

75
00:03:33,930 --> 00:03:37,710
to access and it's gonna rely
on the identity provider's

76
00:03:37,710 --> 00:03:40,560
assertion to trust the user's identity,

77
00:03:40,560 --> 00:03:43,650
and grant access to its resources.

78
00:03:43,650 --> 00:03:45,120
So let me give you an illustration,

79
00:03:45,120 --> 00:03:47,700
and then we'll walk
through it step by step.

80
00:03:47,700 --> 00:03:49,590
So in SAML, we have three components.

81
00:03:49,590 --> 00:03:50,430
We have the end user,

82
00:03:50,430 --> 00:03:52,800
the end user is referred
to as a principle.

83
00:03:52,800 --> 00:03:55,500
We have the identity provider or the IDP,

84
00:03:55,500 --> 00:03:59,673
that's our SAML compliant
authentication service.

85
00:03:59,673 --> 00:04:00,960
And then we're gonna
have a service provider,

86
00:04:00,960 --> 00:04:03,990
and that's a SAML
compliant web application.

87
00:04:03,990 --> 00:04:06,660
Now, we'll have lots of service
providers that interact,

88
00:04:06,660 --> 00:04:09,330
with that single identity provider.

89
00:04:09,330 --> 00:04:12,600
So here I am, the end
user, I want to log into

90
00:04:12,600 --> 00:04:15,510
the service provider, I
access the service provider.

91
00:04:15,510 --> 00:04:17,730
I go to log into the service provider.

92
00:04:17,730 --> 00:04:20,250
The service provider says, "well, okay,

93
00:04:20,250 --> 00:04:22,500
but I'm really not the one
that's gonna log you in."

94
00:04:22,500 --> 00:04:25,359
And you know, either with my knowledge,

95
00:04:25,359 --> 00:04:27,960
or sometimes transparently
will send the request,

96
00:04:27,960 --> 00:04:29,730
over to the identity provider,

97
00:04:29,730 --> 00:04:32,490
who will then authenticate me, right?

98
00:04:32,490 --> 00:04:34,740
Ask me for my credentials.

99
00:04:34,740 --> 00:04:37,590
If I am appropriately authenticated,

100
00:04:37,590 --> 00:04:39,000
we'll create an access token.

101
00:04:39,000 --> 00:04:41,640
That access token will come
back to the service provider.

102
00:04:41,640 --> 00:04:44,400
The service provider will
layer on my authorization.

103
00:04:44,400 --> 00:04:47,520
And at that point, I will be allowed in.

104
00:04:47,520 --> 00:04:50,640
SAML in this configuration
is commonly used,

105
00:04:50,640 --> 00:04:53,070
by businesses that offer subscription,

106
00:04:53,070 --> 00:04:56,580
or pay services like Salesforce or Box.

107
00:04:56,580 --> 00:04:59,430
So let's kind of walk through
a little bit of a deeper dive.

108
00:04:59,430 --> 00:05:01,440
The user initiates a login process,

109
00:05:01,440 --> 00:05:03,120
with the service provider.

110
00:05:03,120 --> 00:05:05,190
The service provider redirects the user,

111
00:05:05,190 --> 00:05:07,200
to the identity provider.

112
00:05:07,200 --> 00:05:10,906
The identity provider prompts
the users for credentials.

113
00:05:10,906 --> 00:05:15,540
The identity provider
verifies the user credentials.

114
00:05:15,540 --> 00:05:16,770
And if accepted,

115
00:05:16,770 --> 00:05:19,500
the identity provider
generates that security token.

116
00:05:19,500 --> 00:05:21,300
That's the assertion.

117
00:05:21,300 --> 00:05:24,420
The user is redirected back
to the service provider,

118
00:05:24,420 --> 00:05:25,983
with the security token,

119
00:05:27,060 --> 00:05:29,700
the service provider
validates a security token,

120
00:05:29,700 --> 00:05:33,150
with the identity provider
to ensure authenticity.

121
00:05:33,150 --> 00:05:35,190
And then if the token is valid,

122
00:05:35,190 --> 00:05:38,193
the service provider grants
access to the resource.

123
00:05:39,757 --> 00:05:42,665
Next, let's look at OAuth 2.0.

124
00:05:42,665 --> 00:05:44,520
Now we're gonna look at OAuth
2.0 a little bit differently.

125
00:05:44,520 --> 00:05:46,073
We're gonna look at it,

126
00:05:46,073 --> 00:05:48,123
from an authorization
standpoint, where SAML,

127
00:05:48,123 --> 00:05:51,000
we looked at it from an
authentication standpoint.

128
00:05:51,000 --> 00:05:53,730
Now, OAuth 2.0 is an
open standard protocol,

129
00:05:53,730 --> 00:05:58,230
and framework designed to
provide secure delegated access,

130
00:05:58,230 --> 00:06:01,950
to resources without sharing credentials.

131
00:06:01,950 --> 00:06:03,390
What an interesting concept,

132
00:06:03,390 --> 00:06:05,700
so we're going to have three components.

133
00:06:05,700 --> 00:06:09,390
First, we're going to have
an authorization server, API,

134
00:06:09,390 --> 00:06:10,995
an application programming interface,

135
00:06:10,995 --> 00:06:11,828
and the resource itself.

136
00:06:11,828 --> 00:06:13,680
That's the server that
authenticated the user,

137
00:06:13,680 --> 00:06:17,190
and issues an access token
to the resource server.

138
00:06:17,190 --> 00:06:18,750
We'll have a client application,

139
00:06:18,750 --> 00:06:20,670
and that's the application or website,

140
00:06:20,670 --> 00:06:23,760
that wants access to a protected resource.

141
00:06:23,760 --> 00:06:25,560
And then we'll have a resource owner,

142
00:06:25,560 --> 00:06:28,890
which is the user who owns
the protected resource.

143
00:06:28,890 --> 00:06:31,740
Let's take a look at
OAuth 2.0 illustrated.

144
00:06:31,740 --> 00:06:33,690
We're going to have three components.

145
00:06:33,690 --> 00:06:37,170
Our resource owner, our
requesting client application,

146
00:06:37,170 --> 00:06:38,100
and then the resource,

147
00:06:38,100 --> 00:06:40,560
which also has an
authorization server, API,

148
00:06:40,560 --> 00:06:42,423
or application programming interface.

149
00:06:43,350 --> 00:06:45,690
So let me give you a
little story about this.

150
00:06:45,690 --> 00:06:48,210
I'm gonna be the resource
owner in my story here,

151
00:06:48,210 --> 00:06:49,350
and I'm gonna tell you,

152
00:06:49,350 --> 00:06:51,720
that I really love playing online poker.

153
00:06:51,720 --> 00:06:53,100
Now, I never play for money.

154
00:06:53,100 --> 00:06:55,800
I only play for for
chips, but I love playing.

155
00:06:55,800 --> 00:06:58,230
And so the requesting client application,

156
00:06:58,230 --> 00:07:00,480
let's say, is the poker game I play.

157
00:07:00,480 --> 00:07:04,297
And one day that requesting
client application says to me,

158
00:07:04,297 --> 00:07:05,130
"hey Sarah, wouldn't you really like

159
00:07:05,130 --> 00:07:06,925
to play poker with your friends?

160
00:07:06,925 --> 00:07:08,796
Wouldn't it be more fun
if they were at the table?

161
00:07:08,796 --> 00:07:09,930
Or, wouldn't you like to know
which one of your friends

162
00:07:09,930 --> 00:07:12,690
has accounts and you can
invite them to your table?"

163
00:07:12,690 --> 00:07:13,950
I think, yeah, that would be cool.

164
00:07:13,950 --> 00:07:15,390
I could stop playing with strangers.

165
00:07:15,390 --> 00:07:16,830
That would be really fun.

166
00:07:16,830 --> 00:07:19,740
So then the requesting client
application says, "okay,

167
00:07:19,740 --> 00:07:23,310
well do you wanna give me access
to your Facebook friends?"

168
00:07:23,310 --> 00:07:25,397
And that's the protected resource.

169
00:07:25,397 --> 00:07:27,690
Give me access to your Facebook friends,

170
00:07:27,690 --> 00:07:29,040
and I'll let you know,

171
00:07:29,040 --> 00:07:31,410
if they're playing or
if they have accounts.

172
00:07:31,410 --> 00:07:33,360
And I, as a resource owner,

173
00:07:33,360 --> 00:07:36,390
because I own my list of Facebook friends,

174
00:07:36,390 --> 00:07:37,620
I say, "okay, sure.

175
00:07:37,620 --> 00:07:40,860
I'm gonna give you permission
to access my friends list."

176
00:07:40,860 --> 00:07:43,020
So, I give that permission
slip, if you will,

177
00:07:43,020 --> 00:07:45,030
to the requesting client application.

178
00:07:45,030 --> 00:07:48,120
The requesting client
presents that permission slip,

179
00:07:48,120 --> 00:07:52,560
to the authorization server,
API, and if it's accepted,

180
00:07:52,560 --> 00:07:55,980
and the resource says,
"sure, okay, we can do that."

181
00:07:55,980 --> 00:07:57,270
In this case, Facebook.

182
00:07:57,270 --> 00:07:59,580
Facebook would give permission,

183
00:07:59,580 --> 00:08:02,130
to the poker game to get my friends list,

184
00:08:02,130 --> 00:08:04,470
and then we would move on from there.

185
00:08:04,470 --> 00:08:05,880
So that's really what's happening.

186
00:08:05,880 --> 00:08:08,550
I never have to give my
Facebook credentials,

187
00:08:08,550 --> 00:08:10,864
to the poker game, right?

188
00:08:10,864 --> 00:08:12,030
I just had to give them permission,

189
00:08:12,030 --> 00:08:14,850
to be able to access my friends list.

190
00:08:14,850 --> 00:08:16,550
Let's dive in a little bit deeper.

191
00:08:17,430 --> 00:08:19,890
So the application
requests an authorization,

192
00:08:19,890 --> 00:08:22,560
from the user to access
a protected resource.

193
00:08:22,560 --> 00:08:25,680
In my example, that was
my Facebook friends list.

194
00:08:25,680 --> 00:08:27,150
If the user agrees,

195
00:08:27,150 --> 00:08:30,150
the application receives
an authorization grant,

196
00:08:30,150 --> 00:08:32,910
that's what I was referring
to as a permission slip.

197
00:08:32,910 --> 00:08:35,010
Now the application
presents its credentials,

198
00:08:35,010 --> 00:08:38,553
and the authorization grant
to the authorization server.

199
00:08:39,597 --> 00:08:40,530
Now if accepted,

200
00:08:40,530 --> 00:08:45,030
the authorization server
issues a access token,

201
00:08:45,030 --> 00:08:47,250
the application presents the access token,

202
00:08:47,250 --> 00:08:50,730
to the resource server and request access.

203
00:08:50,730 --> 00:08:52,830
And if the token is valid,

204
00:08:52,830 --> 00:08:56,040
the service provider grants
access to the resource.

205
00:08:56,040 --> 00:09:00,900
Now, in our illustration,
both our authorization server,

206
00:09:00,900 --> 00:09:03,630
and our resource server,
were really the same device,

207
00:09:03,630 --> 00:09:06,603
with an API, an application
programming interface.

208
00:09:08,610 --> 00:09:09,443
So there you go.

209
00:09:09,443 --> 00:09:12,750
That's SAML and OAuth 2.0
and federated identity.

210
00:09:12,750 --> 00:09:15,060
So that takes us to a
three second challenge,

211
00:09:15,060 --> 00:09:18,030
five challenge questions,
three seconds each.

212
00:09:18,030 --> 00:09:18,930
Are you ready?

213
00:09:18,930 --> 00:09:21,030
1, 2, 3.

214
00:09:21,030 --> 00:09:23,550
The processes and technologies involved,

215
00:09:23,550 --> 00:09:26,280
in managing user
identities, access rights,

216
00:09:26,280 --> 00:09:29,580
and permissions across federated systems.

217
00:09:29,580 --> 00:09:31,263
1, 2, 3.

218
00:09:33,000 --> 00:09:35,550
It's gonna be FIM or
Federated Identity Management.

219
00:09:36,690 --> 00:09:39,270
Number two, an XML based open standard,

220
00:09:39,270 --> 00:09:43,260
for exchanging authentication
and authorization data,

221
00:09:43,260 --> 00:09:46,683
between a service provider
and an identity provider.

222
00:09:48,030 --> 00:09:49,683
1, 2, 3.

223
00:09:50,820 --> 00:09:52,070
And that's gonna be SAML.

224
00:09:53,550 --> 00:09:56,430
Number three, authorization
framework that enables

225
00:09:56,430 --> 00:10:00,813
applications to obtain limited
access to user accounts.

226
00:10:02,130 --> 00:10:05,040
That's the Facebook and
my poker game example.

227
00:10:05,040 --> 00:10:06,333
1, 2, 3.

228
00:10:07,560 --> 00:10:08,510
OAuth 2.0.

229
00:10:10,200 --> 00:10:13,800
Number four, the intermediary that allows

230
00:10:13,800 --> 00:10:16,113
two applications to communicate.

231
00:10:18,030 --> 00:10:19,833
1, 2, 3.

232
00:10:21,270 --> 00:10:23,411
And that's gonna be an API,

233
00:10:23,411 --> 00:10:26,010
an application programming interface.

234
00:10:26,010 --> 00:10:29,970
And lastly, number five, using
a single set of credentials

235
00:10:29,970 --> 00:10:34,680
to access multiple resources
within an enterprise.

236
00:10:34,680 --> 00:10:38,460
What does that refer to
as within an enterprise?

237
00:10:38,460 --> 00:10:39,813
1, 2, 3.

238
00:10:40,680 --> 00:10:42,330
That's gonna be single sign-on,

239
00:10:42,330 --> 00:10:44,883
often referred to as
legacy single sign-on.

240
00:10:46,770 --> 00:10:48,450
So that brings us to
a security and action,

241
00:10:48,450 --> 00:10:49,950
so we can apply our knowledge.

242
00:10:49,950 --> 00:10:53,070
This one's about website authentication.

243
00:10:53,070 --> 00:10:57,210
Your organization is developing
a new secure website.

244
00:10:57,210 --> 00:10:58,830
Now, you are suggesting offloading

245
00:10:58,830 --> 00:11:02,730
the authentication process
to a FIM identity provider,

246
00:11:02,730 --> 00:11:05,763
using SAML as the authentication protocol.

247
00:11:06,690 --> 00:11:09,000
So your boss says,
"well, that's interesting

248
00:11:09,000 --> 00:11:13,470
but can you give me a practical
example of how this works?"

249
00:11:13,470 --> 00:11:15,420
So what might you tell him?

250
00:11:15,420 --> 00:11:17,220
So go ahead and put me on pause.

251
00:11:17,220 --> 00:11:19,830
I gave a little hint there
in the other side for you,

252
00:11:19,830 --> 00:11:22,298
about the Google Identity platform,

253
00:11:22,298 --> 00:11:24,930
but come up with any
practical example you want.

254
00:11:24,930 --> 00:11:27,033
See what we get, then come on back.

255
00:11:30,342 --> 00:11:32,820
Well, I'd start with asking my boss,

256
00:11:32,820 --> 00:11:35,070
if they've ever used
their Google credentials,

257
00:11:35,070 --> 00:11:38,010
to log into a non-Google site.

258
00:11:38,010 --> 00:11:40,713
And my guess is gonna be, absolutely yes.

259
00:11:41,940 --> 00:11:43,260
Well, Google provides a service,

260
00:11:43,260 --> 00:11:46,560
called Google Identity
Platform which includes Google,

261
00:11:46,560 --> 00:11:49,473
as the IDP, the identity provider.

262
00:11:50,460 --> 00:11:53,490
Now the Google Identity
platform supports SAML.

263
00:11:53,490 --> 00:11:56,160
It allows organizations
to configure Google,

264
00:11:56,160 --> 00:11:59,130
as their SAML based identity provider,

265
00:11:59,130 --> 00:12:01,530
enabling users to log into applications,

266
00:12:01,530 --> 00:12:04,380
or services using their
Google credentials,

267
00:12:04,380 --> 00:12:06,183
their portable identity.

268
00:12:07,140 --> 00:12:08,580
This would be a great example,

269
00:12:08,580 --> 00:12:12,030
because everybody's really
familiar with doing this.

270
00:12:12,030 --> 00:12:13,800
So having this conversation
with your boss,

271
00:12:13,800 --> 00:12:16,110
and knowing what examples to provide,

272
00:12:16,110 --> 00:12:18,600
that, my friends, is security in action.

273
00:12:18,600 --> 00:12:21,730
There's your word cloud,
not particularly big,

274
00:12:21,730 --> 00:12:23,310
but make sure that you really
understand all these concepts

275
00:12:23,310 --> 00:12:26,354
and you can distinguish
between what's happening,

276
00:12:26,354 --> 00:12:28,620
with OAuth and what's happening with SAML.

277
00:12:28,620 --> 00:12:30,570
When you're ready, head on
over to the next lesson,

278
00:12:30,570 --> 00:12:31,770
and I'll be right there.