WEBVTT

1
00:00:01.080 --> 00:00:03.000
<v Speaker 1>How'd you like to listen to dot net rocks with

2
00:00:03.040 --> 00:00:07.879
<v Speaker 1>no ads? Easy? Become a patron for just five dollars

3
00:00:07.919 --> 00:00:10.800
<v Speaker 1>a month. You get access to a private RSS feed

4
00:00:10.839 --> 00:00:14.240
<v Speaker 1>where all the shows have no ads. Twenty dollars a month,

5
00:00:14.279 --> 00:00:16.879
<v Speaker 1>we'll get you that and a special dot net Rocks

6
00:00:16.960 --> 00:00:21.000
<v Speaker 1>patron mug. Sign up now at Patreon dot dot NetRocks

7
00:00:21.120 --> 00:00:36.640
<v Speaker 1>dot com. Hey, it's dot net rocks one more time.

8
00:00:36.840 --> 00:00:39.960
<v Speaker 1>I'm Carl Franklin, an amateur camp and man, we are

9
00:00:40.000 --> 00:00:42.240
<v Speaker 1>getting ready to go to build, aren't we getting there? Yeah?

10
00:00:42.320 --> 00:00:43.799
<v Speaker 1>Now that's just about that time.

11
00:00:44.600 --> 00:00:46.439
<v Speaker 2>There's a lot of you know, for me, I'm organizing

12
00:00:46.640 --> 00:00:50.520
<v Speaker 2>a dozen podcasters so right, and a bunch of different teams.

13
00:00:50.679 --> 00:00:52.799
<v Speaker 1>So it's an adventure. This is something that we did

14
00:00:52.799 --> 00:00:54.640
<v Speaker 1>in the past together and then you sort of just

15
00:00:54.679 --> 00:00:59.119
<v Speaker 1>took it over, which is fine because you've got all

16
00:00:59.200 --> 00:01:02.399
<v Speaker 1>of the podcasts wrangled from not just dot net, right,

17
00:01:02.520 --> 00:01:05.640
<v Speaker 1>and not just Microsoft, yeah, specifically not just dot net. Yeah.

18
00:01:05.680 --> 00:01:08.480
<v Speaker 2>We got a bunch of YouTubers well coming out this time,

19
00:01:08.519 --> 00:01:10.359
<v Speaker 2>Tim Corey, who has been on the show not.

20
00:01:10.280 --> 00:01:11.239
<v Speaker 1>In a long time anyway.

21
00:01:11.439 --> 00:01:14.040
<v Speaker 2>I love Tim Corey and Derek co Martin, which we

22
00:01:14.079 --> 00:01:16.480
<v Speaker 2>had on recently coming as well. We got one video

23
00:01:17.040 --> 00:01:19.799
<v Speaker 2>studio as well as a few audios do. Yeah, very cool.

24
00:01:20.680 --> 00:01:23.760
<v Speaker 2>So here's the deal, listeners. If you are going to

25
00:01:23.799 --> 00:01:25.120
<v Speaker 2>be at build, find us.

26
00:01:25.280 --> 00:01:27.920
<v Speaker 1>Yeah. Do you have any idea physically where we're going

27
00:01:28.000 --> 00:01:28.120
<v Speaker 1>to be.

28
00:01:28.200 --> 00:01:30.719
<v Speaker 2>Yeah, we're on the fourth floor, okay, which is the

29
00:01:30.799 --> 00:01:33.359
<v Speaker 2>community area. We're off on one side there. You'll find

30
00:01:33.400 --> 00:01:34.319
<v Speaker 2>us easy enough. We're there.

31
00:01:34.400 --> 00:01:36.519
<v Speaker 1>Yeah, stop in and say hi. Yep. All right, let's

32
00:01:36.560 --> 00:01:47.480
<v Speaker 1>get busy with better know a framework. Awesome? All right,

33
00:01:47.680 --> 00:01:50.840
<v Speaker 1>what do you got? So? I'm having a lot of

34
00:01:50.879 --> 00:01:55.560
<v Speaker 1>fun with a sister podcast Security this week, which is myself,

35
00:01:55.599 --> 00:01:57.799
<v Speaker 1>Patrick Hines and Dwayne Laflatte. And if you don't know

36
00:01:57.799 --> 00:02:01.120
<v Speaker 1>who these guys are, Patrick Hines was actually our first guests.

37
00:02:01.480 --> 00:02:03.959
<v Speaker 2>Well he's now our lucky charm, right, he's the first

38
00:02:03.959 --> 00:02:06.480
<v Speaker 2>guest on all shows we make it seems that's right.

39
00:02:06.519 --> 00:02:08.520
<v Speaker 1>He was your first guest on run As and I

40
00:02:08.560 --> 00:02:10.960
<v Speaker 1>think he was the first guest on Mondays too. I'm

41
00:02:10.960 --> 00:02:15.000
<v Speaker 1>not sure, but anyway, Patrick is a veteran and a

42
00:02:15.039 --> 00:02:20.599
<v Speaker 1>security expert, and Dwayne is his Red team leader. They

43
00:02:20.599 --> 00:02:26.319
<v Speaker 1>basically do penetration tests for customers. You know, customer says

44
00:02:26.319 --> 00:02:28.840
<v Speaker 1>go ahead, try to hack us and you know, try

45
00:02:28.840 --> 00:02:32.960
<v Speaker 1>to be all clever, and Dwayne was like, okay, done.

46
00:02:33.560 --> 00:02:37.879
<v Speaker 1>So it's just and here's the thing about Security this Week,

47
00:02:37.919 --> 00:02:40.560
<v Speaker 1>which is just the podcast name and Security this Week

48
00:02:40.639 --> 00:02:44.840
<v Speaker 1>dot Com is the page we laugh far more than

49
00:02:44.919 --> 00:02:48.520
<v Speaker 1>we should be laughing while talking about hacks that have

50
00:02:48.599 --> 00:02:51.439
<v Speaker 1>happened at the end of the universe. Yeah, because what

51
00:02:51.479 --> 00:02:55.039
<v Speaker 1>we're talking about is fundamentally scary, you know. Yeah. Sure,

52
00:02:55.319 --> 00:02:58.319
<v Speaker 1>security can be very frightening. Yeah, if you think your

53
00:02:58.360 --> 00:03:03.159
<v Speaker 1>passwords are safe. Mmm. So we have, you know, a

54
00:03:03.199 --> 00:03:05.919
<v Speaker 1>lot of mantras that we say over and over again,

55
00:03:06.000 --> 00:03:09.039
<v Speaker 1>like use a password manager and patch and update your

56
00:03:09.039 --> 00:03:12.319
<v Speaker 1>firmware on your Wi Fi, you know thing whatever all

57
00:03:12.360 --> 00:03:14.919
<v Speaker 1>the time. But I just wanted to mention we also

58
00:03:15.000 --> 00:03:17.400
<v Speaker 1>have a Discord server and it's getting a lot of

59
00:03:17.439 --> 00:03:23.840
<v Speaker 1>traction and we're even handing out swag which are lock

60
00:03:23.919 --> 00:03:27.120
<v Speaker 1>pick sets. Oh yeah, with the Security this Week logo

61
00:03:27.240 --> 00:03:30.479
<v Speaker 1>on them lock pick sets. Yeah. So, so if you

62
00:03:30.520 --> 00:03:33.840
<v Speaker 1>go to Discord dot Security this Week dot com and

63
00:03:33.919 --> 00:03:37.199
<v Speaker 1>don't put hddps in front of it or because it's

64
00:03:37.240 --> 00:03:42.439
<v Speaker 1>a URL DNS router, so just go on your browser

65
00:03:42.520 --> 00:03:45.319
<v Speaker 1>type Discord dot Security this week dot com. You'll get

66
00:03:45.319 --> 00:03:48.039
<v Speaker 1>to our discord server and if you, you know, engage

67
00:03:48.080 --> 00:03:50.039
<v Speaker 1>us and give us some things to think about, we'll

68
00:03:50.039 --> 00:03:52.520
<v Speaker 1>send you a lock pick set cool and that's my

69
00:03:52.639 --> 00:03:54.680
<v Speaker 1>better no framework, that's what you get. Who's talking to

70
00:03:54.719 --> 00:03:56.960
<v Speaker 1>us today? Richard Grab a comment off for show nineteen

71
00:03:57.080 --> 00:03:58.879
<v Speaker 1>forty eight. This is the one which is just a

72
00:03:58.919 --> 00:04:01.639
<v Speaker 1>couple of weeks ago with Rob talking about his open

73
00:04:01.719 --> 00:04:06.319
<v Speaker 1>source maintenance fee and Jimmy Scott had this comment back.

74
00:04:06.360 --> 00:04:07.520
<v Speaker 1>He said, thanks for your time. Rob.

75
00:04:07.560 --> 00:04:10.000
<v Speaker 2>We are users of wis, which is a product that

76
00:04:10.520 --> 00:04:13.280
<v Speaker 2>Rob maintains, and I was concerned that wicks was going commercial.

77
00:04:13.560 --> 00:04:17.079
<v Speaker 2>Like many others, we use numerous OS projects and I've

78
00:04:17.079 --> 00:04:18.759
<v Speaker 2>suscribed to several of them. The fee is more than

79
00:04:18.800 --> 00:04:21.079
<v Speaker 2>reasonable and we will be subscribing today.

80
00:04:21.160 --> 00:04:21.560
<v Speaker 1>Awesome.

81
00:04:21.639 --> 00:04:24.240
<v Speaker 2>Yeah, it was great, great news, and I was very

82
00:04:24.480 --> 00:04:27.680
<v Speaker 2>you know, we've been battling with this problem talking about

83
00:04:27.879 --> 00:04:29.839
<v Speaker 2>how we're going to create sustainable open source on it

84
00:04:29.920 --> 00:04:33.600
<v Speaker 2>for years now. So yeah, Rob's approach, you know, and

85
00:04:33.920 --> 00:04:36.519
<v Speaker 2>again I appreciate it. He's not just postulating. He set

86
00:04:36.560 --> 00:04:38.040
<v Speaker 2>it up. He set it up how to do it

87
00:04:38.040 --> 00:04:40.000
<v Speaker 2>through githubs so you can learn everything you need to

88
00:04:40.040 --> 00:04:42.720
<v Speaker 2>do about it, and clearly Jimmy's taking advantage that. So Jimmy,

89
00:04:43.240 --> 00:04:44.800
<v Speaker 2>thank you so much for your comment. And a copy

90
00:04:44.839 --> 00:04:46.360
<v Speaker 2>of music Goby is on its way to you. And

91
00:04:46.360 --> 00:04:47.839
<v Speaker 2>if you'd like a copy of music Go Buy, I

92
00:04:47.879 --> 00:04:50.319
<v Speaker 2>write a comment on the website dot NetRocks dot com

93
00:04:50.399 --> 00:04:52.000
<v Speaker 2>or on the facebooks. We publish every show there and

94
00:04:52.040 --> 00:04:53.720
<v Speaker 2>if you comment there and a reading the show will

95
00:04:53.759 --> 00:04:54.959
<v Speaker 2>send you copy Music to Go Buy.

96
00:04:55.079 --> 00:04:58.160
<v Speaker 1>Yeah, And I just wanted to say I'm standing by

97
00:04:58.360 --> 00:05:01.079
<v Speaker 1>sort of watching how it unfolds with other people other

98
00:05:01.160 --> 00:05:03.079
<v Speaker 1>than Rob and this guy or through the only two

99
00:05:03.120 --> 00:05:06.160
<v Speaker 1>people that I know who are using is systems. So

100
00:05:06.199 --> 00:05:08.480
<v Speaker 1>but I plan on jumping in as soon as I

101
00:05:08.519 --> 00:05:15.160
<v Speaker 1>see happy customers. So also a reminder that Music to

102
00:05:15.240 --> 00:05:18.480
<v Speaker 1>Code By is still going strong with twenty two tracks

103
00:05:18.720 --> 00:05:20.879
<v Speaker 1>and you can download the whole collection in MP three

104
00:05:21.000 --> 00:05:24.720
<v Speaker 1>flak or wave at music tocode by dot net. Awesome. Yeah,

105
00:05:24.759 --> 00:05:26.879
<v Speaker 1>and with that, do you want to do the history thing?

106
00:05:27.000 --> 00:05:29.560
<v Speaker 1>Are we done with it? Oh? That's a great idea.

107
00:05:29.680 --> 00:05:32.680
<v Speaker 1>I didn't. I didn't have time to assemble anything. But

108
00:05:32.839 --> 00:05:35.199
<v Speaker 1>it's nineteen fifty. I mean, what can we say, yes

109
00:05:35.240 --> 00:05:37.920
<v Speaker 1>besides el Wells or beginning of the Korean War.

110
00:05:38.920 --> 00:05:42.360
<v Speaker 2>Oh that that would be one.

111
00:05:42.519 --> 00:05:45.800
<v Speaker 1>There was that, yeah, yeah, okay.

112
00:05:46.040 --> 00:05:48.839
<v Speaker 2>But also the very first credit card, the Diner's Card,

113
00:05:49.000 --> 00:05:52.839
<v Speaker 2>no kidding, is nineteen fifty yeah, I said, sort of famous.

114
00:05:53.120 --> 00:05:55.600
<v Speaker 2>It's it's not an apocryphal story, but it's supposed to

115
00:05:55.639 --> 00:05:58.800
<v Speaker 2>be true that Frank McNamara. It was this sales guy

116
00:06:00.079 --> 00:06:03.120
<v Speaker 2>got his wallet in a different suit, took out his clients,

117
00:06:03.480 --> 00:06:06.000
<v Speaker 2>and his wife had to pay. He didn't have any

118
00:06:06.000 --> 00:06:07.879
<v Speaker 2>money on him, and thought, well, it's got to be

119
00:06:07.920 --> 00:06:10.720
<v Speaker 2>a better way and work with a group of folks,

120
00:06:10.720 --> 00:06:14.199
<v Speaker 2>including Alfred Bloomingdale, who was the heir to the Bloomingdale

121
00:06:14.399 --> 00:06:17.560
<v Speaker 2>d department store. So got it into Bloomingdale's right away

122
00:06:17.600 --> 00:06:19.279
<v Speaker 2>and it kicked that whole thing off. Of course, the

123
00:06:19.319 --> 00:06:21.920
<v Speaker 2>big card, what became Visa, comes along later in nineteen

124
00:06:21.920 --> 00:06:22.439
<v Speaker 2>towty eight.

125
00:06:23.120 --> 00:06:24.959
<v Speaker 1>So did you say it was the diners Club.

126
00:06:25.360 --> 00:06:27.079
<v Speaker 2>That's what became Diner's Club, but at the time it

127
00:06:27.120 --> 00:06:27.959
<v Speaker 2>was called Diner's Card.

128
00:06:28.040 --> 00:06:28.879
<v Speaker 1>The Diner's Card.

129
00:06:29.079 --> 00:06:32.199
<v Speaker 2>Interesting, and it was again focused on restaurants initially, although

130
00:06:32.480 --> 00:06:33.920
<v Speaker 2>rapidly branched into retail.

131
00:06:34.040 --> 00:06:36.839
<v Speaker 1>So you know, we're getting out of like the war

132
00:06:36.959 --> 00:06:39.439
<v Speaker 1>as well, we're getting into via the not the Vietnam,

133
00:06:39.519 --> 00:06:43.480
<v Speaker 1>the Korean War, but and more interesting things are happening

134
00:06:43.480 --> 00:06:47.600
<v Speaker 1>in compute around this time. Do you have any computer

135
00:06:48.079 --> 00:06:49.360
<v Speaker 1>kind of history.

136
00:06:49.480 --> 00:06:51.399
<v Speaker 2>The only comput story that's like a lot of things

137
00:06:51.439 --> 00:06:53.319
<v Speaker 2>will happen in the fifties but in fifty is not

138
00:06:53.680 --> 00:06:56.800
<v Speaker 2>a bunch except that at the Canadian World Exposition in

139
00:06:56.920 --> 00:07:00.839
<v Speaker 2>nineteen fifty they had a computer they called Birdie the

140
00:07:01.040 --> 00:07:04.759
<v Speaker 2>Brain and it played tic tac toe. Wow, And apparently

141
00:07:04.800 --> 00:07:07.040
<v Speaker 2>there was huge cues of people to play tic tac

142
00:07:07.160 --> 00:07:09.480
<v Speaker 2>toe against Berdie the Brain.

143
00:07:09.839 --> 00:07:13.480
<v Speaker 1>Wow. That's cool. Silly but yeah, no, that was silly

144
00:07:13.480 --> 00:07:13.920
<v Speaker 1>but cool.

145
00:07:14.040 --> 00:07:16.319
<v Speaker 2>And you know that all the write ups talk about

146
00:07:16.360 --> 00:07:19.199
<v Speaker 2>it being artificial intelligence, but none of the stuff at

147
00:07:19.240 --> 00:07:22.759
<v Speaker 2>the time called it artificial intelligence. Yeah, which is Bertie

148
00:07:22.759 --> 00:07:27.319
<v Speaker 2>the Brain. They just called it tic tac toe. Okay,

149
00:07:27.480 --> 00:07:31.399
<v Speaker 2>So with that, I'm going to introduce Erwin. Erwin van

150
00:07:31.399 --> 00:07:34.639
<v Speaker 2>der Walk is an experienced software engineer with the passion

151
00:07:34.720 --> 00:07:39.879
<v Speaker 2>for software design, development practices and web security. He works

152
00:07:39.879 --> 00:07:42.360
<v Speaker 2>as a principal engineer at Dwende Software and is the

153
00:07:42.399 --> 00:07:46.199
<v Speaker 2>product owner for the Dwende BFF That's not Best Friends Forever,

154
00:07:46.319 --> 00:07:49.839
<v Speaker 2>That's back in for front End Security Library and the

155
00:07:49.879 --> 00:07:54.360
<v Speaker 2>popular open source library dwende access token management. In his

156
00:07:54.399 --> 00:07:56.639
<v Speaker 2>spare time, he tries to learn as much as possible

157
00:07:56.680 --> 00:08:00.560
<v Speaker 2>about pretty much anything and everything tech, science, history, and

158
00:08:00.600 --> 00:08:06.360
<v Speaker 2>all things metal, listening, playing guitar, and fighting with historically

159
00:08:06.519 --> 00:08:08.360
<v Speaker 2>accurate long's words.

160
00:08:08.560 --> 00:08:09.759
<v Speaker 1>Well there's a hobby for you.

161
00:08:09.959 --> 00:08:10.160
<v Speaker 3>Yeah.

162
00:08:10.279 --> 00:08:14.120
<v Speaker 1>I don't even know what that means, but uh, welcome, Irwin.

163
00:08:14.199 --> 00:08:18.639
<v Speaker 1>I recently learned what dwen day is. Like, I'm not

164
00:08:18.720 --> 00:08:24.199
<v Speaker 1>the company, but the word. It's a Spanish word that means,

165
00:08:24.920 --> 00:08:28.560
<v Speaker 1>you know, it's sort of what do they what do

166
00:08:28.600 --> 00:08:30.439
<v Speaker 1>they call it? It's it's it's sort of a way

167
00:08:30.480 --> 00:08:33.879
<v Speaker 1>of life, right day. You would call something dwende if

168
00:08:33.919 --> 00:08:39.559
<v Speaker 1>it's amazing, if it's awesome, Yeah, that's the idea. Yeah,

169
00:08:39.600 --> 00:08:41.440
<v Speaker 1>so welcome, Well, thank you very much.

170
00:08:41.480 --> 00:08:43.200
<v Speaker 3>I'm super excited to be on the show. A long

171
00:08:43.240 --> 00:08:44.080
<v Speaker 3>time listener, so.

172
00:08:44.600 --> 00:08:49.799
<v Speaker 1>Yeah, we're super excited to have you BFF. Back End

173
00:08:49.879 --> 00:08:53.759
<v Speaker 1>for front end. Yeah, and why why is it back

174
00:08:53.879 --> 00:08:55.679
<v Speaker 1>end for front end and not just back end?

175
00:08:55.919 --> 00:08:59.519
<v Speaker 3>Well, they call it back and for front end because

176
00:09:00.960 --> 00:09:04.879
<v Speaker 3>tied to a particular front end, you have to have

177
00:09:05.440 --> 00:09:08.320
<v Speaker 3>one back end if you have a micro services or

178
00:09:08.399 --> 00:09:11.240
<v Speaker 3>just an appropriately sized services architecture, behind it. You can

179
00:09:11.279 --> 00:09:13.759
<v Speaker 3>have many services behind your front end, but in this

180
00:09:13.799 --> 00:09:16.360
<v Speaker 3>particular case, you only have one back end for that

181
00:09:16.399 --> 00:09:19.799
<v Speaker 3>front end. And you know, the back end for front

182
00:09:19.879 --> 00:09:23.440
<v Speaker 3>end pattern itself has been also around for quite a

183
00:09:23.440 --> 00:09:26.639
<v Speaker 3>long time, and in this particular case, we're explicitly talking

184
00:09:26.679 --> 00:09:29.480
<v Speaker 3>about adding the security layer on top of that. That's

185
00:09:29.519 --> 00:09:33.559
<v Speaker 3>also how the if the Internet Engineering Task Force defined

186
00:09:33.600 --> 00:09:37.960
<v Speaker 3>it now, but originally it was just if you have

187
00:09:38.080 --> 00:09:41.000
<v Speaker 3>multiple different types of front ends, maybe a mobile, maybe

188
00:09:41.039 --> 00:09:44.000
<v Speaker 3>a web application, you would build a specific back end

189
00:09:44.120 --> 00:09:47.639
<v Speaker 3>for that one front end. And in this particular case,

190
00:09:48.000 --> 00:09:51.480
<v Speaker 3>it's kind of similar, but you have a back end

191
00:09:51.840 --> 00:09:54.519
<v Speaker 3>for a particular front end, but also to provide it

192
00:09:54.639 --> 00:09:56.240
<v Speaker 3>with the authentication services.

193
00:09:56.600 --> 00:10:00.320
<v Speaker 1>So with MVC fall into that category, and MVC server

194
00:10:00.480 --> 00:10:03.639
<v Speaker 1>because if you think about it, it's serving up hdmun

195
00:10:03.879 --> 00:10:06.240
<v Speaker 1>JavaScript and front end stuff.

196
00:10:06.480 --> 00:10:09.279
<v Speaker 3>I think the primary goal is to look at what

197
00:10:09.360 --> 00:10:11.679
<v Speaker 3>we call browser based application. So it's a little bit

198
00:10:11.720 --> 00:10:16.480
<v Speaker 3>more like you know, spas applications built with React Angular Blazer,

199
00:10:16.559 --> 00:10:19.679
<v Speaker 3>those type of applications that live primarily in the browser.

200
00:10:20.240 --> 00:10:25.000
<v Speaker 3>They don't necessarily need a one single backhand for them.

201
00:10:25.039 --> 00:10:26.919
<v Speaker 3>I mean, they could use any types of back ends,

202
00:10:27.240 --> 00:10:31.120
<v Speaker 3>but in this particular case, and yeah, maybe it's good

203
00:10:31.120 --> 00:10:33.399
<v Speaker 3>to dive into why we need that thing in the

204
00:10:33.440 --> 00:10:37.759
<v Speaker 3>first place. It is to prevent you from using access

205
00:10:37.799 --> 00:10:40.279
<v Speaker 3>tokens in the browser. Now why would you want that,

206
00:10:40.360 --> 00:10:42.600
<v Speaker 3>Because for a long time, using access tokens in the

207
00:10:42.639 --> 00:10:45.480
<v Speaker 3>browser has been a recommended practice. Right, There's all these

208
00:10:45.480 --> 00:10:49.279
<v Speaker 3>libraries that are out there to handle those in JavaScript.

209
00:10:50.600 --> 00:10:54.600
<v Speaker 3>And that's because the field of security is constantly evolving, right.

210
00:10:54.879 --> 00:10:57.399
<v Speaker 3>I mean, things that were just completely valid in the

211
00:10:57.440 --> 00:11:02.360
<v Speaker 3>past of implicit grand flow for example, is now totally

212
00:11:02.399 --> 00:11:07.519
<v Speaker 3>not recommended anymore because you know, just clear security vulnerabilities

213
00:11:07.559 --> 00:11:08.440
<v Speaker 3>have been discovered in.

214
00:11:08.559 --> 00:11:13.440
<v Speaker 1>Yeah, you're increasing the surface, the attack surface by allowing

215
00:11:13.960 --> 00:11:17.000
<v Speaker 1>hackers to get in there and mess with the tokens

216
00:11:17.039 --> 00:11:19.279
<v Speaker 1>and try to spoof your back end and all of that,

217
00:11:19.360 --> 00:11:20.600
<v Speaker 1>all the things that hackers do.

218
00:11:21.000 --> 00:11:24.840
<v Speaker 3>Absolutely And there's the problem, right because within a browser

219
00:11:24.879 --> 00:11:28.759
<v Speaker 3>based application, all the code for that one application is

220
00:11:28.799 --> 00:11:32.080
<v Speaker 3>just mashed together in the same sandbox this week. So

221
00:11:32.159 --> 00:11:35.039
<v Speaker 3>if a hacker is able to inject code in there,

222
00:11:35.240 --> 00:11:38.879
<v Speaker 3>and unfortunately they do. Injection attacks are still the opity

223
00:11:39.159 --> 00:11:44.559
<v Speaker 3>top three absolutely issue. It just happens a lot. Then

224
00:11:45.039 --> 00:11:47.759
<v Speaker 3>an attacker can do exactly what your application is able

225
00:11:47.799 --> 00:11:51.240
<v Speaker 3>to do as well. Now, if that is just impersonating

226
00:11:51.240 --> 00:11:54.679
<v Speaker 3>you while you have your browser online, that's already a problem.

227
00:11:54.759 --> 00:11:56.960
<v Speaker 3>And sure there are ways that you can limit the

228
00:11:57.000 --> 00:12:00.000
<v Speaker 3>attack surface. Then, but if the attacker is able to

229
00:12:00.759 --> 00:12:03.639
<v Speaker 3>take an access token and take that offline, even when

230
00:12:03.679 --> 00:12:06.320
<v Speaker 3>you close down your browser, he's still able to impersonate you,

231
00:12:06.799 --> 00:12:09.480
<v Speaker 3>or even worse right, take what we call a refresh

232
00:12:09.519 --> 00:12:12.320
<v Speaker 3>token and be able to get more and more access

233
00:12:12.360 --> 00:12:14.960
<v Speaker 3>tokens all the time, then you really have a problem

234
00:12:15.360 --> 00:12:16.080
<v Speaker 3>if that happens.

235
00:12:17.039 --> 00:12:19.879
<v Speaker 1>But these things are require like a sort of a

236
00:12:19.919 --> 00:12:22.960
<v Speaker 1>man in the middle attack, right, This isn't something that

237
00:12:23.000 --> 00:12:25.279
<v Speaker 1>you're going to pick up some malware and somebody's going

238
00:12:25.360 --> 00:12:27.679
<v Speaker 1>to steal your tokens and whatever. Somebody has to really

239
00:12:27.679 --> 00:12:28.639
<v Speaker 1>target you, don't they.

240
00:12:28.840 --> 00:12:32.200
<v Speaker 3>Well, it is so easy to make a small mistake

241
00:12:32.559 --> 00:12:35.679
<v Speaker 3>while building your web application that opens you up to

242
00:12:35.960 --> 00:12:40.480
<v Speaker 3>cross side scripting attacks. Yeah, I myself not too long

243
00:12:40.519 --> 00:12:44.519
<v Speaker 3>ago found out that if you have a URL and

244
00:12:44.559 --> 00:12:47.799
<v Speaker 3>you add that URL into an image tag all of us,

245
00:12:47.840 --> 00:12:51.919
<v Speaker 3>and that URL comes from another source, that URL could

246
00:12:52.000 --> 00:12:55.799
<v Speaker 3>contain script and that will immediately be executed. So immediately

247
00:12:55.919 --> 00:12:59.279
<v Speaker 3>that turns it into a cross side scripting attack. I

248
00:12:59.320 --> 00:13:02.639
<v Speaker 3>didn't know that, and the library at the time React

249
00:13:03.120 --> 00:13:06.399
<v Speaker 3>doesn't handle that particular case. It does when you bind

250
00:13:06.879 --> 00:13:10.720
<v Speaker 3>a textbox to some data, but it doesn't handle that

251
00:13:10.759 --> 00:13:11.639
<v Speaker 3>particular problem.

252
00:13:11.759 --> 00:13:13.919
<v Speaker 1>So so you're saying that I could have you know,

253
00:13:14.480 --> 00:13:21.000
<v Speaker 1>IMG source equals HTDP Joe's discount, sharkcages dot com, slashcage

254
00:13:21.000 --> 00:13:26.039
<v Speaker 1>one dot jpeg, and that jpeg could no a jpeg

255
00:13:26.080 --> 00:13:28.480
<v Speaker 1>could contain a script or is it more like a

256
00:13:28.600 --> 00:13:33.879
<v Speaker 1>script tag that loads a JavaScript file from some other site.

257
00:13:33.919 --> 00:13:38.600
<v Speaker 3>This particular example is a URL that contains script itself.

258
00:13:38.600 --> 00:13:40.559
<v Speaker 3>So it's not necessarily even a URL. It doesn't even

259
00:13:40.600 --> 00:13:45.000
<v Speaker 3>start with htps or something, but it just contains script.

260
00:13:45.080 --> 00:13:47.000
<v Speaker 3>And if you put that into an image tag, it

261
00:13:47.039 --> 00:13:49.120
<v Speaker 3>gets executed and you have a vulnerability.

262
00:13:49.200 --> 00:13:51.080
<v Speaker 1>Oh if you put it into an image to ic.

263
00:13:51.440 --> 00:13:53.240
<v Speaker 1>So if you set the source for an image tag

264
00:13:53.279 --> 00:13:55.840
<v Speaker 1>to a script file, the script is going to get executed.

265
00:13:56.039 --> 00:13:59.679
<v Speaker 3>Yes, And this is just one tiny example. I mean,

266
00:14:00.120 --> 00:14:03.600
<v Speaker 3>when you build a browser based application using React or something,

267
00:14:03.840 --> 00:14:06.759
<v Speaker 3>you get a million node files. How do you know

268
00:14:06.840 --> 00:14:09.240
<v Speaker 3>that not one of those tiny node files has a problem.

269
00:14:09.480 --> 00:14:12.080
<v Speaker 2>I wish you were exaggerating that it was a million

270
00:14:12.159 --> 00:14:15.279
<v Speaker 2>node files, because you're right, so it's so many.

271
00:14:16.159 --> 00:14:18.679
<v Speaker 3>So here's the point, right, I mean, if you do

272
00:14:18.799 --> 00:14:23.360
<v Speaker 3>everything perfect, then doing what we call public client public

273
00:14:23.440 --> 00:14:29.120
<v Speaker 3>client authorization code flow works and it's secure. But as

274
00:14:29.120 --> 00:14:32.360
<v Speaker 3>soon as you have a tiny little hole in your

275
00:14:32.360 --> 00:14:36.360
<v Speaker 3>browser based security, then what you want to do is

276
00:14:37.000 --> 00:14:39.960
<v Speaker 3>put layers in there. Security is all about adding more

277
00:14:40.039 --> 00:14:43.840
<v Speaker 3>layers and reducing the blast radius if something goes wrong.

278
00:14:43.960 --> 00:14:45.799
<v Speaker 1>Right, and before you go down that rabbit hole, let

279
00:14:45.879 --> 00:14:48.200
<v Speaker 1>me just say that it's not just a mistake that

280
00:14:48.240 --> 00:14:51.759
<v Speaker 1>you could make. But in your software bill of materials,

281
00:14:51.759 --> 00:14:56.480
<v Speaker 1>which you have right everybody listening, yes, all right, that

282
00:14:56.679 --> 00:14:59.600
<v Speaker 1>is all of the dependencies that you are taking on

283
00:14:59.759 --> 00:15:03.120
<v Speaker 1>in that list, and that list, as Richard said, could

284
00:15:03.159 --> 00:15:08.720
<v Speaker 1>be millions of JavaScript files down the line. And there's

285
00:15:08.720 --> 00:15:11.720
<v Speaker 1>been examples of these where we've depended on a particular

286
00:15:11.759 --> 00:15:15.279
<v Speaker 1>JavaScript library and that library contained a bug and everything crashed.

287
00:15:16.120 --> 00:15:18.759
<v Speaker 1>You're depending on those things, and how are you going

288
00:15:18.840 --> 00:15:23.480
<v Speaker 1>to know if somebody gets in there maliciously does a

289
00:15:23.519 --> 00:15:27.320
<v Speaker 1>pull request and approves it and absolutely Bob's your uncle,

290
00:15:27.559 --> 00:15:28.559
<v Speaker 1>and you won't know.

291
00:15:28.759 --> 00:15:31.840
<v Speaker 3>Exactly so, and it doesn't even have to be that right,

292
00:15:32.120 --> 00:15:34.799
<v Speaker 3>script injection attacks is just one of the vectors. I mean,

293
00:15:34.840 --> 00:15:37.600
<v Speaker 3>not too long ago, we had Spector. Right, Spector was

294
00:15:37.639 --> 00:15:41.600
<v Speaker 3>a processor based issue. There's a proof of concept that.

295
00:15:41.799 --> 00:15:45.399
<v Speaker 1>It was a vulnerability in the micro code of Intel processors.

296
00:15:45.639 --> 00:15:48.639
<v Speaker 3>Exactly. There was a proof of concept out there that

297
00:15:48.759 --> 00:15:53.320
<v Speaker 3>proved that by somehow from one browser window to another

298
00:15:53.360 --> 00:15:56.519
<v Speaker 3>browser window, they could find poke into the memory of

299
00:15:56.639 --> 00:15:59.279
<v Speaker 3>the other browser window. Now that's scary as well, right,

300
00:16:00.000 --> 00:16:02.480
<v Speaker 3>I mean, the point that I'm making is that you

301
00:16:02.600 --> 00:16:05.759
<v Speaker 3>have code running that you know, comes from all kinds

302
00:16:05.759 --> 00:16:10.000
<v Speaker 3>of sources, maybe even you know, add links or whatever. Right,

303
00:16:10.039 --> 00:16:13.679
<v Speaker 3>it comes from all kinds of sources, just execute together,

304
00:16:13.879 --> 00:16:16.600
<v Speaker 3>and anything that that code does, it will you know

305
00:16:17.120 --> 00:16:19.360
<v Speaker 3>that the code can do, you know it might do.

306
00:16:19.720 --> 00:16:24.360
<v Speaker 3>And that's that's a problem. So the BFF pattern comes

307
00:16:24.360 --> 00:16:27.159
<v Speaker 3>in to try and help that. Now, like I mentioned,

308
00:16:27.240 --> 00:16:30.919
<v Speaker 3>the i ETF Enginet Engineering Task Force. That's the group

309
00:16:30.960 --> 00:16:33.480
<v Speaker 3>that's responsible for creating all of these standards in the

310
00:16:33.480 --> 00:16:37.360
<v Speaker 3>first place. Right, they created the OALTH to specification, open

311
00:16:37.360 --> 00:16:41.000
<v Speaker 3>and deconnect all of that, and every now and then

312
00:16:41.080 --> 00:16:43.919
<v Speaker 3>they come out with what they call a best current

313
00:16:43.960 --> 00:16:47.240
<v Speaker 3>Practice document and in there they try to document well,

314
00:16:47.279 --> 00:16:49.759
<v Speaker 3>you know, looking at the landscape, looking at what we

315
00:16:49.799 --> 00:16:53.320
<v Speaker 3>know right now, what is what do we recommend and

316
00:16:53.360 --> 00:16:55.480
<v Speaker 3>what don't we recommend. And one of the things that

317
00:16:55.480 --> 00:16:59.440
<v Speaker 3>they're recommending is to use the BFF pattern. If you

318
00:16:59.519 --> 00:17:02.159
<v Speaker 3>look at it, the BFF pattern consists of a couple

319
00:17:02.240 --> 00:17:05.720
<v Speaker 3>of things. The first thing really important is that the

320
00:17:05.759 --> 00:17:09.880
<v Speaker 3>authentication needs to happen on the server. So in the

321
00:17:09.880 --> 00:17:12.279
<v Speaker 3>server you have what we call a confidential client, and

322
00:17:12.319 --> 00:17:15.759
<v Speaker 3>the confidential client handles all of the authentication with your

323
00:17:16.000 --> 00:17:20.480
<v Speaker 3>identity provider. Now the browser is still involved, but not

324
00:17:20.599 --> 00:17:25.319
<v Speaker 3>the browser based application. It's not the JavaScript based So

325
00:17:25.400 --> 00:17:28.400
<v Speaker 3>all that the front end has to do is redirect

326
00:17:28.480 --> 00:17:31.240
<v Speaker 3>to a log in page or the logout page, and

327
00:17:32.359 --> 00:17:37.039
<v Speaker 3>the server then takes care of the rest. After the

328
00:17:37.079 --> 00:17:41.079
<v Speaker 3>authentication has completed. What the server then does is it

329
00:17:41.119 --> 00:17:44.079
<v Speaker 3>places a cookie on your machine. Now, cookies have a

330
00:17:44.079 --> 00:17:47.039
<v Speaker 3>bit of a bad rep for privacy reasons, of course,

331
00:17:47.359 --> 00:17:52.200
<v Speaker 3>but also you know, for a cross side request forgery attacks,

332
00:17:52.440 --> 00:17:54.000
<v Speaker 3>and we might get into those in a little bit

333
00:17:54.000 --> 00:17:56.839
<v Speaker 3>in a minute, but they're very easily to protect you

334
00:17:56.920 --> 00:18:01.240
<v Speaker 3>against those actually pretty much. Yeah, but cookies have been

335
00:18:01.279 --> 00:18:03.680
<v Speaker 3>around for a long time and actually they you know,

336
00:18:04.480 --> 00:18:07.640
<v Speaker 3>when you apply them properly. They're actually really secure. Sure,

337
00:18:08.039 --> 00:18:11.000
<v Speaker 3>so what happens if you set your cookie to HTTP only.

338
00:18:11.480 --> 00:18:14.319
<v Speaker 3>That means that your JavaScript can't reach them, and they're

339
00:18:14.359 --> 00:18:18.279
<v Speaker 3>just added by the browser implicitly. Now, you can also

340
00:18:18.400 --> 00:18:21.160
<v Speaker 3>set some policies on there, like same site policies, maybe

341
00:18:21.200 --> 00:18:24.319
<v Speaker 3>even underscore underscore host prefix. It's a little bit technical,

342
00:18:24.400 --> 00:18:26.839
<v Speaker 3>but all these flags that you can turn onto your

343
00:18:26.839 --> 00:18:30.200
<v Speaker 3>cookies so that it's more difficult for attackers to to

344
00:18:31.119 --> 00:18:33.200
<v Speaker 3>you know, accidentally get access to those things.

345
00:18:33.519 --> 00:18:35.079
<v Speaker 1>Got to keep the cookie monster away.

346
00:18:35.519 --> 00:18:39.160
<v Speaker 3>Yeah, but then once you've once you've configured those cookies correctly,

347
00:18:39.440 --> 00:18:42.559
<v Speaker 3>the authentication just happens. Any call that you make to

348
00:18:42.680 --> 00:18:47.119
<v Speaker 3>your backhand service is just authenticated automatically in a simple

349
00:18:47.240 --> 00:18:50.480
<v Speaker 3>application what you just mentioned, right, just an MVC application,

350
00:18:50.519 --> 00:18:54.319
<v Speaker 3>but then maybe one that exposes APIs the authentication just flows.

351
00:18:54.720 --> 00:18:59.240
<v Speaker 3>Everything's fine, But now if you want to access external services,

352
00:18:59.720 --> 00:19:02.599
<v Speaker 3>you know, micro services that you have running somewhere else,

353
00:19:03.000 --> 00:19:05.319
<v Speaker 3>you don't want the cookie to flow over there because

354
00:19:05.319 --> 00:19:09.559
<v Speaker 3>it can't read those cookies, can't do anything with them there.

355
00:19:09.079 --> 00:19:13.759
<v Speaker 1>So you need some federated kind of multiple server communication

356
00:19:13.920 --> 00:19:14.240
<v Speaker 1>going on.

357
00:19:14.400 --> 00:19:17.160
<v Speaker 3>Right, Yeah, Well, what you then do is you exchange

358
00:19:17.279 --> 00:19:20.000
<v Speaker 3>the cookie for an access token, and from that point

359
00:19:20.039 --> 00:19:24.880
<v Speaker 3>on you just have a request from the BFF to

360
00:19:24.960 --> 00:19:28.079
<v Speaker 3>your API using access tokens. And that's just a very

361
00:19:28.119 --> 00:19:32.880
<v Speaker 3>well known pattern to flow, just credentials and information and

362
00:19:33.119 --> 00:19:38.319
<v Speaker 3>security context. Yeah, okay, that is pretty much it. I mean,

363
00:19:38.359 --> 00:19:39.920
<v Speaker 3>there's more that you can add to that.

364
00:19:40.279 --> 00:19:42.720
<v Speaker 1>But so the access tokens are kind of made up

365
00:19:42.720 --> 00:19:47.160
<v Speaker 1>on the fly, whereas the cookie identifies you to your server. Yeah,

366
00:19:47.200 --> 00:19:50.359
<v Speaker 1>but when you say exchange, you mean, hey, this is

367
00:19:50.440 --> 00:19:52.359
<v Speaker 1>me because I have this cookie, you know who I am.

368
00:19:52.480 --> 00:19:54.720
<v Speaker 1>Give me an authentication token that I can use over

369
00:19:54.759 --> 00:19:55.440
<v Speaker 1>in this API.

370
00:19:55.599 --> 00:19:58.400
<v Speaker 3>Yes, yeah, and you can still have the choice. I mean,

371
00:19:58.440 --> 00:20:02.079
<v Speaker 3>some APIs they don't want what we call a user

372
00:20:02.119 --> 00:20:04.799
<v Speaker 3>based a token, right, They just want to have a

373
00:20:04.839 --> 00:20:08.079
<v Speaker 3>client credentials token and that's it. You might want to

374
00:20:08.079 --> 00:20:11.279
<v Speaker 3>have a token that's very narrow for that one particular service,

375
00:20:11.839 --> 00:20:14.680
<v Speaker 3>because you might want to have multiple tokens for different services,

376
00:20:14.960 --> 00:20:17.720
<v Speaker 3>and some other service might actually want to have a

377
00:20:17.799 --> 00:20:20.200
<v Speaker 3>token with the subject identifier in it and all kinds

378
00:20:20.240 --> 00:20:21.480
<v Speaker 3>of claims in there as well.

379
00:20:21.960 --> 00:20:27.200
<v Speaker 1>So we're really talking about authorization at this point, not authentication.

380
00:20:27.279 --> 00:20:31.720
<v Speaker 1>You're authenticated by that cookie. Now authorization takes on this

381
00:20:32.039 --> 00:20:33.240
<v Speaker 1>whole other topic.

382
00:20:33.519 --> 00:20:37.400
<v Speaker 3>Well, think about it from the perspective of your API.

383
00:20:38.160 --> 00:20:42.079
<v Speaker 3>You're still authenticating, right, because a request comes in, there's

384
00:20:42.119 --> 00:20:45.599
<v Speaker 3>an access token that says who is calling this thing?

385
00:20:45.640 --> 00:20:47.799
<v Speaker 3>And that may just be hey, it's just a BFF

386
00:20:47.839 --> 00:20:51.359
<v Speaker 3>that's calling you. Trust a BFF, right, do your thing,

387
00:20:51.559 --> 00:20:53.400
<v Speaker 3>But it may also be no, this is an access

388
00:20:53.400 --> 00:20:57.279
<v Speaker 3>token that has user information in it, so a subject identifier,

389
00:20:57.400 --> 00:21:00.440
<v Speaker 3>maybe all kinds of other claims that then the might

390
00:21:00.480 --> 00:21:04.119
<v Speaker 3>also use to make coarse grained authorization decisions.

391
00:21:04.200 --> 00:21:06.640
<v Speaker 1>Sure, sure, okay, So.

392
00:21:08.039 --> 00:21:13.319
<v Speaker 3>Now on top of that, you can also look at sessions. Now,

393
00:21:14.680 --> 00:21:18.480
<v Speaker 3>the cookie, that's the thing that identifies you as a

394
00:21:19.079 --> 00:21:21.160
<v Speaker 3>but you can store information in the cookie. If you

395
00:21:21.160 --> 00:21:24.599
<v Speaker 3>wanted to, you could store the access token in the cookie.

396
00:21:24.759 --> 00:21:27.160
<v Speaker 3>Now it's still secure. It goes to the browser, but

397
00:21:27.480 --> 00:21:31.839
<v Speaker 3>the browser based application can't reach it, and then that's sorry.

398
00:21:31.880 --> 00:21:36.440
<v Speaker 3>The advantage of that is is that your BFF is

399
00:21:36.680 --> 00:21:40.160
<v Speaker 3>relatively stateless, right, it doesn't need to store that session

400
00:21:40.200 --> 00:21:43.279
<v Speaker 3>information somewhere. But if you were to store that session

401
00:21:43.319 --> 00:21:46.240
<v Speaker 3>information in a database, then you can also do things

402
00:21:46.319 --> 00:21:50.440
<v Speaker 3>like remote sign out, for example, because if you delete

403
00:21:50.440 --> 00:21:52.720
<v Speaker 3>the record from the database, the user is signed out

404
00:21:52.759 --> 00:21:54.839
<v Speaker 3>and you can't access to the system anymore and needs

405
00:21:54.880 --> 00:21:58.000
<v Speaker 3>to log back in again. So there are benefits and

406
00:21:58.039 --> 00:22:02.240
<v Speaker 3>downside of store. You know, your your session information in

407
00:22:02.279 --> 00:22:02.880
<v Speaker 3>a database.

408
00:22:03.119 --> 00:22:07.200
<v Speaker 1>Sure, and if you have something like Blazer server you

409
00:22:07.240 --> 00:22:10.319
<v Speaker 1>can use or server based stuff. You can use a

410
00:22:10.359 --> 00:22:13.279
<v Speaker 1>protected browser storage, which I guess gives you what five

411
00:22:13.400 --> 00:22:18.519
<v Speaker 1>megabytes of encrypted data on the on the browser per

412
00:22:18.680 --> 00:22:21.440
<v Speaker 1>user per r L. Yeah. Yeah.

413
00:22:21.559 --> 00:22:26.480
<v Speaker 3>The downside of of these storages in the browser is

414
00:22:26.519 --> 00:22:29.519
<v Speaker 3>that it is still the browser application that reaches into that.

415
00:22:29.960 --> 00:22:33.200
<v Speaker 3>And there's been quite a number of things that have

416
00:22:33.279 --> 00:22:36.559
<v Speaker 3>been tried to to do that. I mean storing things

417
00:22:36.599 --> 00:22:40.680
<v Speaker 3>inside of web workers to to keep them, keep them hidden,

418
00:22:40.960 --> 00:22:44.119
<v Speaker 3>you know, encrypted storage, all of that stuff. But ultimately,

419
00:22:44.200 --> 00:22:47.359
<v Speaker 3>if the browser based application can reach it, you know,

420
00:22:47.440 --> 00:22:52.160
<v Speaker 3>you're exposing that information also to potentially malicious actors.

421
00:22:52.400 --> 00:22:55.079
<v Speaker 1>I remember one thing that Dom I think it was dumb,

422
00:22:55.119 --> 00:22:57.240
<v Speaker 1>it might have been Brock said, these are the one

423
00:22:57.319 --> 00:23:03.559
<v Speaker 1>day guys over and over again, is that you want

424
00:23:03.599 --> 00:23:08.640
<v Speaker 1>your authorization system to be totally separate from your authentication system. Yes,

425
00:23:08.839 --> 00:23:12.519
<v Speaker 1>you know want those two tied together. And in what

426
00:23:12.680 --> 00:23:15.400
<v Speaker 1>is the asp net core identity where you have just

427
00:23:15.440 --> 00:23:21.119
<v Speaker 1>these databases that do that hold both the authentication passwords,

428
00:23:21.279 --> 00:23:26.960
<v Speaker 1>hashes and also you know, claims, roles and that kind

429
00:23:27.000 --> 00:23:29.440
<v Speaker 1>of stuff. You're really kind of tying the two together.

430
00:23:30.119 --> 00:23:33.039
<v Speaker 1>And I didn't really understand what he meant by that,

431
00:23:33.279 --> 00:23:37.640
<v Speaker 1>but but I get it that that having it separate

432
00:23:39.039 --> 00:23:41.680
<v Speaker 1>just it doesn't tie them together.

433
00:23:42.039 --> 00:23:45.680
<v Speaker 3>Yeah. I think the key thing to keep in mind

434
00:23:45.720 --> 00:23:49.039
<v Speaker 3>here is that what you get from your identity provider,

435
00:23:49.240 --> 00:23:51.880
<v Speaker 3>and maybe you layer a little bit on top of

436
00:23:51.920 --> 00:23:54.720
<v Speaker 3>that inside of your application, and you could do that

437
00:23:54.799 --> 00:23:58.079
<v Speaker 3>in the BFF as well. Should say something about the

438
00:23:58.160 --> 00:24:02.640
<v Speaker 3>user itself. Right, So I am irwin, I have you

439
00:24:02.680 --> 00:24:06.720
<v Speaker 3>know this role in the organization, right, But as soon

440
00:24:06.759 --> 00:24:10.160
<v Speaker 3>as you start to think about other things like I

441
00:24:10.240 --> 00:24:14.359
<v Speaker 3>have created this particular document, or I am a manager

442
00:24:14.519 --> 00:24:19.119
<v Speaker 3>of that particular department, and therefore I that is not

443
00:24:19.279 --> 00:24:22.559
<v Speaker 3>information that you want to store and managing your identity provider.

444
00:24:22.680 --> 00:24:25.279
<v Speaker 3>That's not part of your identity. That's much more part

445
00:24:25.279 --> 00:24:30.599
<v Speaker 3>of your application domain. And therefore those authorization decisions you

446
00:24:30.680 --> 00:24:33.880
<v Speaker 3>do not want to take purely based on information that's

447
00:24:33.880 --> 00:24:36.839
<v Speaker 3>stored in your cookie and sorting your access token, you

448
00:24:36.880 --> 00:24:40.759
<v Speaker 3>actually want to say no no, no, I am. I'm

449
00:24:40.839 --> 00:24:43.680
<v Speaker 3>defining what we call a policy, and that policy says,

450
00:24:43.720 --> 00:24:46.279
<v Speaker 3>am I allowed to do this given who I am?

451
00:24:46.640 --> 00:24:50.079
<v Speaker 3>And then inside of the code that executes that policy,

452
00:24:50.319 --> 00:24:54.200
<v Speaker 3>you can do lookups like are you the right manager

453
00:24:54.200 --> 00:24:57.960
<v Speaker 3>for this particular thing? Do you have access to that thing.

454
00:24:57.839 --> 00:25:01.000
<v Speaker 1>If you're rolling your own Well, but I've seen many

455
00:25:01.000 --> 00:25:03.200
<v Speaker 1>customers and I do this myself, is that you have

456
00:25:03.799 --> 00:25:08.720
<v Speaker 1>you know, your your aspnet user's table in identity Core

457
00:25:09.839 --> 00:25:12.720
<v Speaker 1>ASPN Core Identity and then basically what we would do

458
00:25:12.799 --> 00:25:15.319
<v Speaker 1>is create a separate user's table that has all the

459
00:25:15.400 --> 00:25:20.880
<v Speaker 1>application specific data about that user, and then it's related

460
00:25:20.920 --> 00:25:23.240
<v Speaker 1>with a foreign key to that aspnet user in case

461
00:25:23.400 --> 00:25:26.799
<v Speaker 1>you know, so that that's how they're tied together, but

462
00:25:27.000 --> 00:25:28.359
<v Speaker 1>they're still in the same database.

463
00:25:28.640 --> 00:25:32.960
<v Speaker 3>Yeah, and authorization can become really complex.

464
00:25:33.240 --> 00:25:33.400
<v Speaker 1>Right.

465
00:25:33.960 --> 00:25:37.640
<v Speaker 3>You can imagine inside of a big enterprise, one system

466
00:25:37.680 --> 00:25:41.039
<v Speaker 3>controls this particular aspect, that other system controls that particular aspect.

467
00:25:41.279 --> 00:25:45.319
<v Speaker 3>Now there are these systems, you know, policy server being

468
00:25:45.359 --> 00:25:49.000
<v Speaker 3>one of them as an example, right, that might actually say, okay,

469
00:25:49.599 --> 00:25:52.599
<v Speaker 3>you replicate some of the information that's part of your

470
00:25:52.640 --> 00:25:56.440
<v Speaker 3>domain into that server and then you know, since that

471
00:25:56.519 --> 00:25:59.920
<v Speaker 3>information is also stored in there. You can create association

472
00:26:00.079 --> 00:26:04.720
<v Speaker 3>is there. You can say, because this particular person has

473
00:26:04.839 --> 00:26:08.319
<v Speaker 3>this role, this relationship with that other thing, that's why

474
00:26:08.359 --> 00:26:10.680
<v Speaker 3>he's allowed to do these particular things, and those things

475
00:26:10.680 --> 00:26:14.079
<v Speaker 3>can inherit from each other. You can basically model your

476
00:26:14.359 --> 00:26:18.200
<v Speaker 3>authorization domain, but that is only if you have an

477
00:26:18.279 --> 00:26:23.000
<v Speaker 3>application landscape that is complex enough to warrant extracting that.

478
00:26:23.240 --> 00:26:27.599
<v Speaker 1>Multiple applications from the same vendor. For example. Yeah, and

479
00:26:27.680 --> 00:26:31.079
<v Speaker 1>some customers have access to this application and that application,

480
00:26:31.119 --> 00:26:32.039
<v Speaker 1>but not that one.

481
00:26:32.119 --> 00:26:35.839
<v Speaker 2>But I also look at it from a administrative versus

482
00:26:35.920 --> 00:26:38.200
<v Speaker 2>regular user role within an app or you can even

483
00:26:38.240 --> 00:26:40.920
<v Speaker 2>be more gradiated that HR can see some things that

484
00:26:41.000 --> 00:26:44.160
<v Speaker 2>sales can't see, Like you need to have someplace for

485
00:26:44.200 --> 00:26:46.200
<v Speaker 2>all of those different levels of authorization to live.

486
00:26:46.359 --> 00:26:50.559
<v Speaker 3>Yeah, and you know, in an enterprise, what you typically

487
00:26:50.599 --> 00:26:52.720
<v Speaker 3>see is that, you know, especially if the enterprise has

488
00:26:52.720 --> 00:26:56.240
<v Speaker 3>built their own custom software for certain types of things,

489
00:26:56.359 --> 00:26:59.640
<v Speaker 3>that it really warrants you to store that that centrally.

490
00:27:00.119 --> 00:27:04.000
<v Speaker 3>Sometimes you literally have islands where each application stores its

491
00:27:04.000 --> 00:27:05.839
<v Speaker 3>own and has its own logic.

492
00:27:05.519 --> 00:27:09.480
<v Speaker 1>Around right, yeah, right, you want to take a break,

493
00:27:09.599 --> 00:27:11.319
<v Speaker 1>or yeah, it's a good time. Oh well, yeah, okay,

494
00:27:11.319 --> 00:27:13.440
<v Speaker 1>we'll take a break. We'll be right back after these

495
00:27:13.640 --> 00:27:17.799
<v Speaker 1>very important messages. Stay tuned. Do you have a complex

496
00:27:17.839 --> 00:27:20.359
<v Speaker 1>dot net monolith you'd like to refactor to a micro

497
00:27:20.480 --> 00:27:24.880
<v Speaker 1>services architecture? The micro Service Extractor for dot Net tool

498
00:27:25.039 --> 00:27:29.720
<v Speaker 1>visualizes your app and helps progressively extract code into micro services.

499
00:27:30.079 --> 00:27:38.279
<v Speaker 1>Learn more at aws dot Amazon dot com, slash modernize

500
00:27:38.559 --> 00:27:42.079
<v Speaker 1>and we're back. It's dot NetRocks. I'm Carl Franklin. That's

501
00:27:42.079 --> 00:27:44.920
<v Speaker 1>my friend Richard Campbell. Hey, and that's our friend Erwin

502
00:27:45.039 --> 00:27:50.559
<v Speaker 1>van Dervach from Duende. We're talking about interestingly enough policy

503
00:27:50.640 --> 00:27:53.880
<v Speaker 1>server and why it's such a good idea to separate

504
00:27:55.200 --> 00:27:59.359
<v Speaker 1>authorization policies from authentication databases.

505
00:27:59.480 --> 00:28:02.599
<v Speaker 3>Yeah, and of course you really have to think, you know,

506
00:28:03.920 --> 00:28:06.319
<v Speaker 3>how complex is your application and do you need to

507
00:28:06.359 --> 00:28:10.039
<v Speaker 3>externalize those decisions? And then you know, is it complex

508
00:28:10.160 --> 00:28:12.519
<v Speaker 3>enough that you need a product for that, because.

509
00:28:12.279 --> 00:28:14.960
<v Speaker 2>There's an awful lot of cases where identity enough and

510
00:28:15.119 --> 00:28:19.319
<v Speaker 2>authorization are essentially identical. You identify with this so you

511
00:28:19.440 --> 00:28:22.200
<v Speaker 2>get all right, so this app. There is no granularization

512
00:28:22.359 --> 00:28:23.559
<v Speaker 2>of the rights within the app.

513
00:28:23.839 --> 00:28:28.440
<v Speaker 1>Yeah, and if it's complex enough, you'll know, Yeah, absolutely,

514
00:28:28.680 --> 00:28:29.599
<v Speaker 1>you'll fit that point.

515
00:28:29.640 --> 00:28:31.599
<v Speaker 2>It's one of those things where the moment I want

516
00:28:31.640 --> 00:28:34.319
<v Speaker 2>to granularize the rights within an app, I probably should

517
00:28:34.319 --> 00:28:34.559
<v Speaker 2>have a.

518
00:28:34.480 --> 00:28:35.720
<v Speaker 1>Place for all that stuff to live.

519
00:28:35.799 --> 00:28:39.039
<v Speaker 3>Yeah, coming back to the BFF pattern, right, one of

520
00:28:39.039 --> 00:28:42.720
<v Speaker 3>the things I mentioned is c surf protection. You know,

521
00:28:43.319 --> 00:28:46.559
<v Speaker 3>the challenge with issuing cookies is that cookies are sent

522
00:28:46.680 --> 00:28:53.240
<v Speaker 3>automatically when the browser makes a request to a particular domain.

523
00:28:54.119 --> 00:28:57.880
<v Speaker 3>And the challenge there could be is that if a

524
00:28:58.000 --> 00:29:02.400
<v Speaker 3>malicious actor lures you your users to a malicious site

525
00:29:02.799 --> 00:29:05.359
<v Speaker 3>and he then makes a call from that malicious site

526
00:29:05.519 --> 00:29:09.960
<v Speaker 3>to your application, you don't want, you know, authorized requests

527
00:29:10.000 --> 00:29:13.920
<v Speaker 3>to be sent. Now, browsers already have pretty good protection

528
00:29:14.240 --> 00:29:17.599
<v Speaker 3>baked in there, I mean, and also there's a process

529
00:29:17.599 --> 00:29:21.519
<v Speaker 3>for that, what we call cross origin resource sharing. You

530
00:29:21.559 --> 00:29:25.559
<v Speaker 3>can define policies around that course to define well is

531
00:29:25.599 --> 00:29:28.960
<v Speaker 3>this allowed or not. But unfortunately, there are a couple

532
00:29:29.000 --> 00:29:33.519
<v Speaker 3>of holes that are still allowed by the course you know,

533
00:29:33.599 --> 00:29:36.720
<v Speaker 3>that wouldn't trigger a course policy check, and that could

534
00:29:36.759 --> 00:29:38.559
<v Speaker 3>potentially be dangerous.

535
00:29:38.400 --> 00:29:40.720
<v Speaker 1>Allow all for example, Well.

536
00:29:40.920 --> 00:29:43.440
<v Speaker 3>That's if you have a course policy in the first place.

537
00:29:43.480 --> 00:29:46.519
<v Speaker 3>But what I'm talking about here is that there are

538
00:29:46.599 --> 00:29:50.319
<v Speaker 3>certain requests that the browser deemed safe and therefore won't

539
00:29:50.319 --> 00:29:55.599
<v Speaker 3>trigger a course check, and because of that, you know

540
00:29:55.680 --> 00:29:59.079
<v Speaker 3>you could be in trouble. Now, to be fair, dot

541
00:29:59.160 --> 00:30:01.440
<v Speaker 3>net already does a pretty good job of protecting you

542
00:30:01.480 --> 00:30:06.839
<v Speaker 3>against those because they those type of requests would be gets.

543
00:30:07.039 --> 00:30:10.440
<v Speaker 3>Now gets shouldn't manipulate states, so you shouldn't be able

544
00:30:10.480 --> 00:30:13.279
<v Speaker 3>to get into trouble with those. And they can be

545
00:30:14.319 --> 00:30:17.119
<v Speaker 3>simple posts, but as soon as you try to do

546
00:30:17.200 --> 00:30:21.519
<v Speaker 3>a post with a specific content type, that's when you

547
00:30:21.559 --> 00:30:24.559
<v Speaker 3>know the course policy would be would be triggered.

548
00:30:24.559 --> 00:30:25.119
<v Speaker 1>For example.

549
00:30:25.680 --> 00:30:30.480
<v Speaker 3>Now, some frameworks, you know, some server side frameworks, they

550
00:30:30.799 --> 00:30:33.559
<v Speaker 3>don't do a very good job of checking those content types.

551
00:30:33.599 --> 00:30:35.559
<v Speaker 3>But dot Net, by default, if you say, hey, you know,

552
00:30:35.640 --> 00:30:38.720
<v Speaker 3>I'm expecting a post that's just an adjacent document, you know,

553
00:30:39.000 --> 00:30:44.160
<v Speaker 3>it will not accept it if it's not adjacent post.

554
00:30:44.359 --> 00:30:45.279
<v Speaker 1>Is it just raise an error?

555
00:30:45.359 --> 00:30:46.799
<v Speaker 3>Yeah, it would just say hey, this is the wrong

556
00:30:46.799 --> 00:30:48.240
<v Speaker 3>content type, I go away.

557
00:30:48.440 --> 00:30:48.680
<v Speaker 1>Yeah.

558
00:30:48.799 --> 00:30:51.359
<v Speaker 3>Right, So fortunately dot net also helps you with that.

559
00:30:51.480 --> 00:30:54.759
<v Speaker 3>But again, right, security is about more layers. So there's

560
00:30:54.799 --> 00:30:59.480
<v Speaker 3>a very simple way of tackling this. Now, Microsoft provides

561
00:30:59.519 --> 00:31:03.440
<v Speaker 3>you with se SERF protection, right, so cross side request

562
00:31:03.440 --> 00:31:07.880
<v Speaker 3>forger reprotection, but it is based on encryption, and you

563
00:31:07.920 --> 00:31:11.359
<v Speaker 3>need to specify the data protection keys and all your servers,

564
00:31:11.359 --> 00:31:13.359
<v Speaker 3>and if you make a mistake there, you know it

565
00:31:13.400 --> 00:31:17.480
<v Speaker 3>doesn't work. But the very simple thing is just to

566
00:31:17.519 --> 00:31:21.720
<v Speaker 3>say in your BFF server to demand that a specific

567
00:31:21.759 --> 00:31:24.319
<v Speaker 3>header is there. And I'm saying specific header. It really

568
00:31:24.359 --> 00:31:26.279
<v Speaker 3>doesn't matter what the header is as long as it's

569
00:31:26.319 --> 00:31:30.599
<v Speaker 3>a custom header. So your front end just always sends

570
00:31:30.640 --> 00:31:33.039
<v Speaker 3>that header, no problem, right, It could be you know

571
00:31:33.640 --> 00:31:37.160
<v Speaker 3>x SE serf equals one, doesn't matter, right, Your front

572
00:31:37.240 --> 00:31:41.559
<v Speaker 3>end just always sends that. If the malicious site wants

573
00:31:41.599 --> 00:31:45.240
<v Speaker 3>to call your service, it doesn't have that header, so

574
00:31:45.480 --> 00:31:49.079
<v Speaker 3>it will that your your BFF will say I'm not

575
00:31:49.160 --> 00:31:52.279
<v Speaker 3>letting you in. If the malicious site then tries to

576
00:31:52.519 --> 00:31:55.920
<v Speaker 3>add that header, now you're adding a custom header to

577
00:31:55.960 --> 00:31:58.880
<v Speaker 3>the request and that triggers the course policies in a browser,

578
00:31:58.920 --> 00:32:02.480
<v Speaker 3>so it stops all the sea surf attacks dead. So

579
00:32:03.279 --> 00:32:07.599
<v Speaker 3>just by demanding in your server you must have a

580
00:32:07.640 --> 00:32:10.480
<v Speaker 3>custom header, and as long as you have an agreement

581
00:32:10.519 --> 00:32:13.039
<v Speaker 3>between your backhand and your front end, hey, send that header.

582
00:32:13.599 --> 00:32:14.119
<v Speaker 1>You're safe.

583
00:32:15.440 --> 00:32:16.119
<v Speaker 3>That's kind of cool.

584
00:32:16.440 --> 00:32:17.160
<v Speaker 1>That's kind of cool.

585
00:32:17.519 --> 00:32:20.079
<v Speaker 2>And can you read something in that header that's like

586
00:32:20.359 --> 00:32:23.160
<v Speaker 2>a security key or something not easily spoofed.

587
00:32:23.480 --> 00:32:27.279
<v Speaker 3>You don't have to. That's the thing. I mean, this

588
00:32:27.359 --> 00:32:30.279
<v Speaker 3>confused me in the beginning quite a bit because I thought, well.

589
00:32:30.240 --> 00:32:32.240
<v Speaker 1>Why headers or headers? They should be able to make

590
00:32:32.240 --> 00:32:32.880
<v Speaker 1>anything I want.

591
00:32:33.319 --> 00:32:37.680
<v Speaker 3>Yeah, But the point is is that the browser standards

592
00:32:37.839 --> 00:32:41.799
<v Speaker 3>they dictate that if you do a cross origin call

593
00:32:43.119 --> 00:32:47.240
<v Speaker 3>and you do that with a specific header, that first

594
00:32:47.319 --> 00:32:50.839
<v Speaker 3>you must do a course policy check and then that

595
00:32:50.920 --> 00:32:53.039
<v Speaker 3>course policy comes into play. Now, if you screw up

596
00:32:53.079 --> 00:32:56.200
<v Speaker 3>your course policy, if you say course policy allow all, sure,

597
00:32:56.240 --> 00:32:58.920
<v Speaker 3>you're still vulnerable. But here's the point, right, if you

598
00:32:59.000 --> 00:33:02.720
<v Speaker 3>do it correctly, then you're secure. And by default, by

599
00:33:02.720 --> 00:33:04.960
<v Speaker 3>the way, if you don't specify a course policy, the

600
00:33:05.000 --> 00:33:08.279
<v Speaker 3>course policy is deny. So you're pretty secure if you

601
00:33:08.319 --> 00:33:11.200
<v Speaker 3>don't do anything there. There's a couple of other things

602
00:33:11.200 --> 00:33:13.920
<v Speaker 3>that you could look at. I mean, Blazer support is

603
00:33:13.960 --> 00:33:18.400
<v Speaker 3>an interesting one. I Mean, the thing with Blazer is

604
00:33:18.400 --> 00:33:22.279
<v Speaker 3>is that it's a really powerful framework, but because of

605
00:33:22.319 --> 00:33:26.920
<v Speaker 3>all of its rendering modes, you have to pay attention, right,

606
00:33:26.960 --> 00:33:29.960
<v Speaker 3>I mean, if you're doing purely service side rendering, then

607
00:33:30.079 --> 00:33:34.880
<v Speaker 3>you're just building a regular application. But if you start

608
00:33:34.960 --> 00:33:39.559
<v Speaker 3>mixing those interactivity modes, especially in the auto rendering mode.

609
00:33:39.799 --> 00:33:43.839
<v Speaker 3>Then some communication might go over web sockets, some communication

610
00:33:44.000 --> 00:33:48.160
<v Speaker 3>might be with web requests, and yeah, you just have

611
00:33:48.240 --> 00:33:51.039
<v Speaker 3>to you know, look at all, how are you going

612
00:33:51.079 --> 00:33:54.799
<v Speaker 3>to set the you know, as soon as you start

613
00:33:54.799 --> 00:34:00.000
<v Speaker 3>doing web requests, right, so regularates to be requests. Yeah,

614
00:33:59.839 --> 00:34:03.519
<v Speaker 3>you just have to make sure that you're calling it

615
00:34:04.480 --> 00:34:07.799
<v Speaker 3>with the right credentials. Now, inside of the do end,

616
00:34:07.799 --> 00:34:10.719
<v Speaker 3>the BFF framework, the one that I'm responsible for as well,

617
00:34:10.800 --> 00:34:13.199
<v Speaker 3>we try to make sure that that is all unified

618
00:34:13.199 --> 00:34:15.000
<v Speaker 3>so that you just have a single programming model that

619
00:34:15.039 --> 00:34:17.559
<v Speaker 3>you can code in your Blazer back end, in your

620
00:34:17.559 --> 00:34:21.400
<v Speaker 3>front end, and the auto rendering modes just work work seamlessly.

621
00:34:21.760 --> 00:34:24.039
<v Speaker 3>But if you don't use that framework, if you just

622
00:34:24.079 --> 00:34:26.079
<v Speaker 3>want to build your own then of course. And if

623
00:34:26.119 --> 00:34:28.840
<v Speaker 3>you do use Blazer, then that's one thing to watch

624
00:34:28.840 --> 00:34:29.559
<v Speaker 3>out for as well.

625
00:34:30.320 --> 00:34:32.760
<v Speaker 2>And does the Blazer mode matter, like you have to

626
00:34:32.800 --> 00:34:34.719
<v Speaker 2>be in client mode for this to make sense or

627
00:34:34.760 --> 00:34:36.199
<v Speaker 2>do It'll work the same either way.

628
00:34:36.840 --> 00:34:40.760
<v Speaker 3>Now, well, so here's the thing. Right with the auto

629
00:34:40.840 --> 00:34:43.880
<v Speaker 3>rendering mode. If you say I want to display a

630
00:34:43.960 --> 00:34:47.960
<v Speaker 3>list on the screen, there's three things that can happen.

631
00:34:48.360 --> 00:34:50.199
<v Speaker 3>One is it get rented on the server, and that's

632
00:34:50.199 --> 00:34:52.599
<v Speaker 3>actually what happens initially, right, it's rented on the server

633
00:34:52.719 --> 00:34:55.719
<v Speaker 3>and then send to the browsers HTML. So then you

634
00:34:55.800 --> 00:34:57.880
<v Speaker 3>need to have on the server. You need to be

635
00:34:57.880 --> 00:34:59.960
<v Speaker 3>able to get to that data. That might either be

636
00:35:00.400 --> 00:35:02.639
<v Speaker 3>just go directly to the database because you're in the

637
00:35:02.679 --> 00:35:06.280
<v Speaker 3>same space, or you're doing a call to an external service,

638
00:35:06.519 --> 00:35:08.320
<v Speaker 3>and therefore you need to make sure that there's an

639
00:35:08.320 --> 00:35:10.480
<v Speaker 3>access token on the ah top client to call that

640
00:35:10.519 --> 00:35:16.719
<v Speaker 3>external service. When you are in interactive mode, right, so

641
00:35:16.800 --> 00:35:21.320
<v Speaker 3>it's running on the in the it switches over to

642
00:35:22.079 --> 00:35:25.239
<v Speaker 3>web assembly mode. Then all of a sudden, it's the

643
00:35:25.239 --> 00:35:28.000
<v Speaker 3>browser that does that request, right, And you can't go

644
00:35:28.119 --> 00:35:31.239
<v Speaker 3>from the browser directly to that API in point because

645
00:35:31.559 --> 00:35:33.880
<v Speaker 3>first of all, it might just be in an internal network, right,

646
00:35:34.000 --> 00:35:36.199
<v Speaker 3>the browser doesn't have access directly to that API in

647
00:35:36.239 --> 00:35:38.239
<v Speaker 3>point right, And second of all, you don't have that

648
00:35:38.320 --> 00:35:41.239
<v Speaker 3>access token. You don't want that access token there, so

649
00:35:41.280 --> 00:35:44.079
<v Speaker 3>then you need to proxy that request using a reverse

650
00:35:44.119 --> 00:35:48.039
<v Speaker 3>proxy through the BFF, and then the BFF does that token,

651
00:35:48.280 --> 00:35:50.960
<v Speaker 3>the cookie exchange for the token, and then goes out

652
00:35:51.400 --> 00:35:56.679
<v Speaker 3>to that external service. So that's how that's supposed to

653
00:35:56.679 --> 00:35:58.239
<v Speaker 3>work together.

654
00:35:58.320 --> 00:36:01.039
<v Speaker 2>Then as well, trying to figure out how much work

655
00:36:01.039 --> 00:36:02.920
<v Speaker 2>I actually have to do to implement this framework. It

656
00:36:03.000 --> 00:36:05.039
<v Speaker 2>sounds almost like a drop in thing and that should

657
00:36:05.079 --> 00:36:05.639
<v Speaker 2>be good to go.

658
00:36:05.840 --> 00:36:09.159
<v Speaker 3>Yeah, I mean, if you want to build it yourself,

659
00:36:09.199 --> 00:36:10.840
<v Speaker 3>then of course you need to know what you're doing,

660
00:36:10.920 --> 00:36:13.920
<v Speaker 3>and you know, Microsoft provides a bunch of things, but.

661
00:36:14.000 --> 00:36:15.639
<v Speaker 1>That's never stopping before or when.

662
00:36:15.760 --> 00:36:19.960
<v Speaker 3>Come on, yeah, of course, but I mean you know

663
00:36:20.000 --> 00:36:21.840
<v Speaker 3>you need to You can use YARP, that's a really

664
00:36:21.880 --> 00:36:24.440
<v Speaker 3>good reverse proxy. I mean, you can use the Microsoft

665
00:36:24.440 --> 00:36:27.840
<v Speaker 3>libraries for that. We provide an open source library for

666
00:36:27.840 --> 00:36:30.519
<v Speaker 3>access token management, so that there's a bunch of things

667
00:36:30.519 --> 00:36:32.119
<v Speaker 3>that you can do, and if you know what you're doing,

668
00:36:32.360 --> 00:36:36.039
<v Speaker 3>then you can just do that. If you rather use

669
00:36:36.079 --> 00:36:38.079
<v Speaker 3>a product, then of course, you know, we provide a

670
00:36:38.239 --> 00:36:40.960
<v Speaker 3>product that you can also. You know, if you uh,

671
00:36:41.519 --> 00:36:41.800
<v Speaker 3>it is.

672
00:36:41.800 --> 00:36:43.800
<v Speaker 1>A new GET package, right like this isn't it.

673
00:36:43.800 --> 00:36:45.559
<v Speaker 3>It's just a new Get packaging. You plug it in

674
00:36:45.639 --> 00:36:47.639
<v Speaker 3>with a couple of lines of code, you have it working,

675
00:36:47.719 --> 00:36:50.199
<v Speaker 3>and you know, we have a community license as well,

676
00:36:50.239 --> 00:36:53.880
<v Speaker 3>so that if you uh, you know, I think it's

677
00:36:54.239 --> 00:36:56.719
<v Speaker 3>if you make less than a couple of million of years,

678
00:36:56.760 --> 00:36:58.880
<v Speaker 3>then you can just use the product for free. Right

679
00:36:58.920 --> 00:37:01.119
<v Speaker 3>if you make over that then you know, you pay

680
00:37:01.119 --> 00:37:04.920
<v Speaker 3>a little bit and then you get a nice product

681
00:37:04.960 --> 00:37:05.119
<v Speaker 3>for that.

682
00:37:05.280 --> 00:37:08.239
<v Speaker 2>So yeah, no, and you said, drop in a couple

683
00:37:08.239 --> 00:37:12.760
<v Speaker 2>of configuration things. You're working and you've you're using this

684
00:37:12.800 --> 00:37:15.000
<v Speaker 2>whole TLS approach, like your life is better.

685
00:37:15.320 --> 00:37:19.519
<v Speaker 3>Absolutely. Now there's one thing that we're also working on,

686
00:37:19.639 --> 00:37:24.000
<v Speaker 3>and it kind of bleeds into more operations, right because

687
00:37:24.880 --> 00:37:28.119
<v Speaker 3>if you have a purely browser based application, you can

688
00:37:28.159 --> 00:37:30.159
<v Speaker 3>just host that on a CD and and you know,

689
00:37:31.000 --> 00:37:33.159
<v Speaker 3>run that somewhere and now all of a sudden, you

690
00:37:33.199 --> 00:37:35.800
<v Speaker 3>do need a back end component for that. Now, if

691
00:37:35.840 --> 00:37:37.519
<v Speaker 3>you do that for your first application, you have a

692
00:37:37.559 --> 00:37:39.079
<v Speaker 3>really nice you know, you've got a nice back end

693
00:37:39.079 --> 00:37:42.159
<v Speaker 3>for your front end. It's all good. But typically, you know,

694
00:37:42.239 --> 00:37:45.400
<v Speaker 3>especially enterprises, they have a lot of applications and then

695
00:37:45.440 --> 00:37:47.960
<v Speaker 3>they come to the conclusions like I have a lot

696
00:37:48.000 --> 00:37:51.039
<v Speaker 3>of BFFs here, you know, can't we do anything about that? Right,

697
00:37:51.280 --> 00:37:53.800
<v Speaker 3>So one of the things that we're about to release

698
00:37:54.239 --> 00:37:56.440
<v Speaker 3>is multi front end support as well, So you can

699
00:37:56.440 --> 00:38:00.159
<v Speaker 3>have a single BFF that just you know, from the

700
00:38:00.199 --> 00:38:03.280
<v Speaker 3>perspective of the front end, it is just a single

701
00:38:03.320 --> 00:38:05.800
<v Speaker 3>back end for front end, but physically it's a single

702
00:38:05.800 --> 00:38:07.079
<v Speaker 3>host that can serve many of.

703
00:38:07.039 --> 00:38:09.039
<v Speaker 2>Them, right, so you don't end up with one for

704
00:38:09.159 --> 00:38:13.280
<v Speaker 2>every app, which can get untenable. You have exactly collective

705
00:38:13.800 --> 00:38:16.039
<v Speaker 2>because they're all using the same right sets and so forth. Like,

706
00:38:16.079 --> 00:38:18.679
<v Speaker 2>this is all very shareable, and I suspet it's like

707
00:38:18.800 --> 00:38:21.239
<v Speaker 2>ninety five percent in common between apps and there's just

708
00:38:21.239 --> 00:38:22.119
<v Speaker 2>a few exceptions.

709
00:38:22.400 --> 00:38:24.880
<v Speaker 3>Yeah, exactly. Now, now there's a couple of other things

710
00:38:24.880 --> 00:38:27.760
<v Speaker 3>that I mean, I've applied this pattern a lot of

711
00:38:27.760 --> 00:38:30.400
<v Speaker 3>times already in my career, and one of the things

712
00:38:30.400 --> 00:38:33.639
<v Speaker 3>that I'm finding is that it also helps my collaboration

713
00:38:33.840 --> 00:38:36.239
<v Speaker 3>with front end developers. I mean, I am primarily a

714
00:38:36.239 --> 00:38:38.559
<v Speaker 3>back end developer. I know enough about a front end

715
00:38:38.599 --> 00:38:42.599
<v Speaker 3>to being dangerous, but primarily a back end developer. But

716
00:38:43.599 --> 00:38:46.480
<v Speaker 3>when I'm working with front end developers, it's really nice

717
00:38:46.760 --> 00:38:49.760
<v Speaker 3>to have what I typically call then a dev server.

718
00:38:49.920 --> 00:38:53.079
<v Speaker 3>Nowadays you would build that with Aspire. You have something

719
00:38:53.360 --> 00:38:56.039
<v Speaker 3>that front end engineers can just run and it's just

720
00:38:56.039 --> 00:38:58.760
<v Speaker 3>just running there nicely, and they can iterate on building

721
00:38:58.760 --> 00:39:01.400
<v Speaker 3>their front ends. And as a back end engineer, I

722
00:39:01.440 --> 00:39:03.800
<v Speaker 3>mean I just spin up the front end and my

723
00:39:03.880 --> 00:39:05.920
<v Speaker 3>back end is there, and I can iterate on my

724
00:39:05.960 --> 00:39:08.079
<v Speaker 3>back end. And if you have a branch. Where you

725
00:39:08.119 --> 00:39:10.599
<v Speaker 3>have both of them, you can easily work together on

726
00:39:10.639 --> 00:39:12.559
<v Speaker 3>them with the front end. You compare program. Hey, I

727
00:39:12.559 --> 00:39:14.039
<v Speaker 3>build this in the front end, build this in the

728
00:39:14.039 --> 00:39:17.800
<v Speaker 3>back end, work together. It's just a really nice flow

729
00:39:17.880 --> 00:39:21.440
<v Speaker 3>to to collaborate together.

730
00:39:21.840 --> 00:39:26.320
<v Speaker 2>So and then is the BFF security framework. It's again,

731
00:39:26.320 --> 00:39:28.320
<v Speaker 2>it's just a new GET package. So is it just

732
00:39:28.320 --> 00:39:32.519
<v Speaker 2>a line in Aspire to say include this and just

733
00:39:32.559 --> 00:39:34.039
<v Speaker 2>another part of the equation.

734
00:39:34.199 --> 00:39:36.880
<v Speaker 3>Right now, it is just a new GET package that

735
00:39:36.920 --> 00:39:40.480
<v Speaker 3>you need to install inside of your web application. In

736
00:39:40.559 --> 00:39:43.960
<v Speaker 3>the near future, yes, it's going to be just a

737
00:39:44.000 --> 00:39:46.320
<v Speaker 3>container that you can just run and aspire and from

738
00:39:46.360 --> 00:39:48.960
<v Speaker 3>that point on you can use that as a development experience.

739
00:39:49.079 --> 00:39:50.639
<v Speaker 1>Very cool. Yeah, I'd like it. I just like that

740
00:39:50.719 --> 00:39:51.360
<v Speaker 1>in my template.

741
00:39:51.440 --> 00:39:53.800
<v Speaker 2>I'm thinking, I'm thinking very enterprising here about how do

742
00:39:53.880 --> 00:39:57.239
<v Speaker 2>I get my devs on the path to using these

743
00:39:57.280 --> 00:39:58.440
<v Speaker 2>tools from the outset?

744
00:39:58.679 --> 00:40:02.239
<v Speaker 3>Yeah, yeah, absolutely, And that's exactly what we see people

745
00:40:02.280 --> 00:40:04.760
<v Speaker 3>do for this, and you know, and there's nice tricks

746
00:40:04.760 --> 00:40:06.840
<v Speaker 3>that you can do there with that, because one of

747
00:40:06.840 --> 00:40:08.760
<v Speaker 3>the things that you know, as a back end engineer,

748
00:40:08.880 --> 00:40:11.719
<v Speaker 3>I don't sometimes even have all the front end tools installed,

749
00:40:11.719 --> 00:40:15.320
<v Speaker 3>and there's like a gazillion of them. So what I

750
00:40:15.320 --> 00:40:16.320
<v Speaker 3>typically do then.

751
00:40:16.320 --> 00:40:19.599
<v Speaker 1>Is again not an exaggeration, no, and gazillion.

752
00:40:20.239 --> 00:40:22.440
<v Speaker 3>So when I just start up the back end, it

753
00:40:22.599 --> 00:40:25.199
<v Speaker 3>just loads the most recent front end from my dev

754
00:40:25.360 --> 00:40:27.960
<v Speaker 3>environment in the clouds. It gets it from a CDN

755
00:40:28.239 --> 00:40:30.639
<v Speaker 3>right right. But then if I start up both of them,

756
00:40:30.679 --> 00:40:33.679
<v Speaker 3>I can detect, hey, the front end code is running locally.

757
00:40:33.920 --> 00:40:35.960
<v Speaker 3>Let me just take the front end code locally and

758
00:40:36.000 --> 00:40:42.280
<v Speaker 3>serve that from there instead of them from the CDN server.

759
00:40:42.599 --> 00:40:44.559
<v Speaker 3>So that's a really nice experience. Then. You know, if

760
00:40:44.599 --> 00:40:46.239
<v Speaker 3>I don't care about the front end, I can just

761
00:40:46.280 --> 00:40:48.800
<v Speaker 3>start it up. If I do care about it, especially

762
00:40:48.800 --> 00:40:51.079
<v Speaker 3>when working together, you start them up both and they

763
00:40:51.079 --> 00:40:53.639
<v Speaker 3>just start working together. That's a really nice experience there

764
00:40:53.679 --> 00:40:54.000
<v Speaker 3>as well.

765
00:40:54.119 --> 00:40:57.480
<v Speaker 2>For sure, What about the telemetry side, is there any

766
00:40:57.679 --> 00:41:01.360
<v Speaker 2>information coming out of this framework that helps me as

767
00:41:01.440 --> 00:41:05.320
<v Speaker 2>an on the administrator side knowing what privileges are being

768
00:41:05.360 --> 00:41:06.039
<v Speaker 2>gained and so forth.

769
00:41:06.159 --> 00:41:08.039
<v Speaker 1>Is that still be part of the regular system.

770
00:41:08.199 --> 00:41:18.199
<v Speaker 3>Yeah, that's the actual authentication bit. I mean, we track

771
00:41:18.519 --> 00:41:21.960
<v Speaker 3>how many tokens are being exchanged, and we do metrics

772
00:41:21.960 --> 00:41:25.719
<v Speaker 3>for those type of things. And of course if you

773
00:41:25.800 --> 00:41:28.559
<v Speaker 3>use service side sessions, you know exactly how many people

774
00:41:28.639 --> 00:41:31.719
<v Speaker 3>are online at any point in time, so you can

775
00:41:31.760 --> 00:41:35.599
<v Speaker 3>also do metrics for those, but actually publishing these metrics

776
00:41:35.639 --> 00:41:39.760
<v Speaker 3>as open telemetry is something that we haven't built in yet, right,

777
00:41:39.920 --> 00:41:43.159
<v Speaker 3>And there is a reason for that as well, is

778
00:41:43.199 --> 00:41:47.239
<v Speaker 3>that all of the traffic between your front end and

779
00:41:47.599 --> 00:41:51.360
<v Speaker 3>your APIs flows through the BFF, so it has to

780
00:41:51.400 --> 00:41:54.639
<v Speaker 3>reverse proxy those otherwise the cookie won't flow and therefore

781
00:41:54.920 --> 00:42:00.280
<v Speaker 3>the reverse proxy is very secured, very performance sensitive. I mean,

782
00:42:00.320 --> 00:42:04.800
<v Speaker 3>you don't want delays in there for reasons. So if

783
00:42:04.800 --> 00:42:07.159
<v Speaker 3>you were to add if we were to add code

784
00:42:07.159 --> 00:42:09.760
<v Speaker 3>in there that says every five minutes, look how many

785
00:42:09.840 --> 00:42:12.079
<v Speaker 3>users there are, look how many you know, and publish

786
00:42:12.159 --> 00:42:18.840
<v Speaker 3>those as statistics, right, we might, you know, negatively impact

787
00:42:18.880 --> 00:42:21.440
<v Speaker 3>your performance. So we don't want to do that obviously.

788
00:42:21.480 --> 00:42:25.559
<v Speaker 2>Sure, I'm just thinking about additional telemetry you'd have access to,

789
00:42:25.760 --> 00:42:28.920
<v Speaker 2>just because you can see these tokens flowing around. But yeah,

790
00:42:29.159 --> 00:42:31.360
<v Speaker 2>and it's always a debate as to how much what

791
00:42:31.400 --> 00:42:32.679
<v Speaker 2>do you want, Like where is that?

792
00:42:32.719 --> 00:42:33.800
<v Speaker 1>What is that useful for?

793
00:42:33.960 --> 00:42:34.480
<v Speaker 3>Absolutely?

794
00:42:34.519 --> 00:42:38.400
<v Speaker 2>Certainly when you're trying to do a call chain, knowing

795
00:42:38.559 --> 00:42:41.599
<v Speaker 2>what token was issued, when it was issued, when it expired,

796
00:42:41.639 --> 00:42:43.199
<v Speaker 2>like that's all part of that chain.

797
00:42:43.320 --> 00:42:47.079
<v Speaker 3>Oh yeah, well, and access to cam management does alog

798
00:42:47.159 --> 00:42:48.239
<v Speaker 3>quite a lot of information.

799
00:42:49.000 --> 00:42:50.840
<v Speaker 2>Yeah, that's the thing that's a lot of that's already

800
00:42:50.880 --> 00:42:53.320
<v Speaker 2>handled for you. Absolutely not your problem. You're just calling

801
00:42:53.360 --> 00:42:54.159
<v Speaker 2>into those services.

802
00:42:55.000 --> 00:42:58.239
<v Speaker 3>Technically, it's my problem because I'm also the product owner

803
00:42:58.239 --> 00:42:59.239
<v Speaker 3>for access to com management.

804
00:42:59.480 --> 00:43:01.239
<v Speaker 2>Well you're also the COGA provider. But that's not the

805
00:43:01.280 --> 00:43:04.880
<v Speaker 2>security framework's fault. No, exactly, exactly. Now I'll get that

806
00:43:04.920 --> 00:43:08.480
<v Speaker 2>telemetry for identity server. Yeah, but I mean, yeah, I'm

807
00:43:08.519 --> 00:43:10.039
<v Speaker 2>just thin get through all the issues.

808
00:43:10.599 --> 00:43:12.400
<v Speaker 3>No, absolutely, absolutely so.

809
00:43:13.440 --> 00:43:17.119
<v Speaker 1>Yeah, So is there anything that we missed, any gotchas

810
00:43:17.599 --> 00:43:22.400
<v Speaker 1>that people might run into, or any other issues around

811
00:43:23.079 --> 00:43:26.559
<v Speaker 1>this BFF pattern that people find tricky.

812
00:43:26.880 --> 00:43:29.440
<v Speaker 3>Well, I mean there's a couple of ways that you

813
00:43:29.480 --> 00:43:32.519
<v Speaker 3>can host this really in production that might be interesting

814
00:43:32.559 --> 00:43:36.760
<v Speaker 3>to have a look at. So the absolute simplest way

815
00:43:36.800 --> 00:43:40.119
<v Speaker 3>of hosting this is to say, hey, it's just like

816
00:43:40.159 --> 00:43:45.000
<v Speaker 3>you know, you're bundling your back end code with your

817
00:43:45.000 --> 00:43:47.360
<v Speaker 3>front end code and publishing that as a single unit,

818
00:43:47.559 --> 00:43:50.119
<v Speaker 3>deploy that into the cloud or wherever you deploy it,

819
00:43:50.320 --> 00:43:53.719
<v Speaker 3>and then your back end just serves that, right. And

820
00:43:54.360 --> 00:43:56.039
<v Speaker 3>challenge with that is is that every time you want

821
00:43:56.079 --> 00:43:57.320
<v Speaker 3>to make a change to your front end, you have

822
00:43:57.360 --> 00:43:59.239
<v Speaker 3>to redeploy your back end as well, and that's just

823
00:43:59.559 --> 00:44:02.639
<v Speaker 3>very common. So what we typically see is that front

824
00:44:02.719 --> 00:44:05.440
<v Speaker 3>end engineers they bundle their software and they deploy that

825
00:44:05.480 --> 00:44:10.039
<v Speaker 3>to a CDN, and the back end is deployed, you know,

826
00:44:10.800 --> 00:44:13.719
<v Speaker 3>via a different channel, and they might even have different cadences.

827
00:44:13.760 --> 00:44:17.920
<v Speaker 3>It depends on how you structure your organization.

828
00:44:18.199 --> 00:44:20.039
<v Speaker 2>You would hope like that's kind of a cool thing,

829
00:44:20.119 --> 00:44:23.239
<v Speaker 2>right in my perfect world, As a new version of

830
00:44:23.280 --> 00:44:26.159
<v Speaker 2>the client is coming up, the back end's already been deployed.

831
00:44:26.519 --> 00:44:28.639
<v Speaker 2>It's been running for a while, well just with some

832
00:44:28.760 --> 00:44:29.440
<v Speaker 2>dark features.

833
00:44:29.679 --> 00:44:33.519
<v Speaker 3>Sure, I mean, but when you make a new version,

834
00:44:33.800 --> 00:44:36.760
<v Speaker 3>right you can You know, if you work, for example,

835
00:44:36.760 --> 00:44:39.159
<v Speaker 3>in a mono RepA where both your front end code

836
00:44:39.199 --> 00:44:41.199
<v Speaker 3>and your back end code is in the same repository,

837
00:44:42.159 --> 00:44:44.440
<v Speaker 3>you could have some logic in your bill pipeline that says,

838
00:44:44.480 --> 00:44:46.639
<v Speaker 3>if only a change happens in the back end code,

839
00:44:46.719 --> 00:44:48.599
<v Speaker 3>I will only deploy the back end if it change

840
00:44:48.639 --> 00:44:49.960
<v Speaker 3>only happens in the front end code.

841
00:44:50.079 --> 00:44:51.400
<v Speaker 1>Yeah. That scares me.

842
00:44:51.480 --> 00:44:53.360
<v Speaker 2>I think I want my back end and it container

843
00:44:53.400 --> 00:44:54.639
<v Speaker 2>my front and deployed a CD end.

844
00:44:54.760 --> 00:44:54.960
<v Speaker 1>Yeah.

845
00:44:55.000 --> 00:44:56.719
<v Speaker 3>Yeah, but you can still do that. But then you

846
00:44:56.719 --> 00:45:01.519
<v Speaker 3>can have different deployment pipelines for each of them. Now,

847
00:45:02.480 --> 00:45:05.400
<v Speaker 3>so what you then still have a choice, And the

848
00:45:05.519 --> 00:45:08.559
<v Speaker 3>choice is because your code is running in a CD

849
00:45:08.679 --> 00:45:11.559
<v Speaker 3>and your your BFF is running UH and a container

850
00:45:11.559 --> 00:45:13.920
<v Speaker 3>app somewhere, you still have the choice to say the

851
00:45:13.960 --> 00:45:16.760
<v Speaker 3>initial request and the domain name where you're going to

852
00:45:17.360 --> 00:45:19.440
<v Speaker 3>is that owned by the b f F or is

853
00:45:19.480 --> 00:45:22.599
<v Speaker 3>that owned by the front end. Now, the difference is

854
00:45:22.599 --> 00:45:24.639
<v Speaker 3>is that if it's owned by the front end, you're

855
00:45:24.679 --> 00:45:28.000
<v Speaker 3>going to to the CDN directly, so to speak, and

856
00:45:28.039 --> 00:45:30.760
<v Speaker 3>then you're getting the index ahe tmail there, and then

857
00:45:30.800 --> 00:45:34.199
<v Speaker 3>you want to do calls to the BFF that has

858
00:45:34.320 --> 00:45:39.639
<v Speaker 3>to be on the same what we call the same site.

859
00:45:39.719 --> 00:45:44.000
<v Speaker 3>It can be a subdomain, but a site unfortunately is

860
00:45:44.079 --> 00:45:48.159
<v Speaker 3>defined as top level domain minus one, so it also

861
00:45:48.320 --> 00:45:52.199
<v Speaker 3>can include subdomains there. So within subdom you can say,

862
00:45:52.519 --> 00:45:55.880
<v Speaker 3>I've got you know API dot my company dot com,

863
00:45:55.880 --> 00:45:58.599
<v Speaker 3>and I've got you know frontend dot A my company

864
00:45:58.639 --> 00:46:01.880
<v Speaker 3>dot com. And they can share cookies, they can send

865
00:46:01.880 --> 00:46:04.440
<v Speaker 3>cookies to each other if you can figure that correctly.

866
00:46:04.480 --> 00:46:06.880
<v Speaker 1>If it was easy, we could buy it at seven eleven. Right.

867
00:46:07.000 --> 00:46:08.760
<v Speaker 1>That's why developers.

868
00:46:09.079 --> 00:46:11.960
<v Speaker 3>The other option and that's the one that I personally prefer,

869
00:46:12.079 --> 00:46:15.079
<v Speaker 3>but you know that's just me. Is that you go

870
00:46:15.199 --> 00:46:18.960
<v Speaker 3>to your BFF. The BFF serves the index document, which

871
00:46:18.960 --> 00:46:20.840
<v Speaker 3>it gets from the CDN by the way, but it

872
00:46:20.840 --> 00:46:24.360
<v Speaker 3>can catch that. And then in the index document you

873
00:46:24.519 --> 00:46:27.119
<v Speaker 3>have all the links to your CDN and that can

874
00:46:27.199 --> 00:46:29.920
<v Speaker 3>be just in an other domain, it doesn't really matter.

875
00:46:30.039 --> 00:46:32.280
<v Speaker 3>That's just static content that gets loaded from your CDN.

876
00:46:32.760 --> 00:46:35.000
<v Speaker 3>And then you have also the option to inject some

877
00:46:35.119 --> 00:46:37.639
<v Speaker 3>script in your in your htmail page if you want to.

878
00:46:37.719 --> 00:46:40.559
<v Speaker 3>You have a little bit more flexibility in you know,

879
00:46:41.599 --> 00:46:46.559
<v Speaker 3>setting up some things and you don't have to you know,

880
00:46:46.840 --> 00:46:51.199
<v Speaker 3>the secured communication is always going onto the same same

881
00:46:51.239 --> 00:46:54.079
<v Speaker 3>domain name, so that's kind of nice. So that's my preference,

882
00:46:54.199 --> 00:46:56.000
<v Speaker 3>but you know, you can you can decide how you

883
00:46:56.039 --> 00:46:57.840
<v Speaker 3>want to deploy these these things.

884
00:46:57.960 --> 00:47:01.519
<v Speaker 1>I'll stick with your preference. Thank you very much. The

885
00:47:01.679 --> 00:47:05.719
<v Speaker 1>tried and true. Right, what's next for you? What are

886
00:47:05.719 --> 00:47:07.719
<v Speaker 1>you what's coming up in your inbox?

887
00:47:07.840 --> 00:47:11.320
<v Speaker 3>All right, Well, we're working on two big releases. Access

888
00:47:11.320 --> 00:47:14.280
<v Speaker 3>to com Management fee for is going to come out.

889
00:47:14.719 --> 00:47:17.719
<v Speaker 3>And you know access to com Management has been you know,

890
00:47:17.800 --> 00:47:21.360
<v Speaker 3>originally created by Dom and Brock and it's it's quite

891
00:47:21.719 --> 00:47:24.039
<v Speaker 3>you know, quite an old library. It's been it's been

892
00:47:24.079 --> 00:47:25.800
<v Speaker 3>around for quite a while and it's been of course

893
00:47:25.880 --> 00:47:29.480
<v Speaker 3>updated to the latest specifications. But now we're finding that

894
00:47:29.519 --> 00:47:31.360
<v Speaker 3>we you know, we want to update it a little

895
00:47:31.360 --> 00:47:34.639
<v Speaker 3>bit more to also the most modern coding standards. So

896
00:47:34.679 --> 00:47:37.199
<v Speaker 3>that's the thing that we're that we're working on. And

897
00:47:37.280 --> 00:47:39.400
<v Speaker 3>we're working on b f F FEE for which which

898
00:47:39.440 --> 00:47:42.000
<v Speaker 3>includes that multi funt ten support. So that's going to

899
00:47:42.079 --> 00:47:45.480
<v Speaker 3>come out fairly soon and it's also quite a big release.

900
00:47:45.639 --> 00:47:47.320
<v Speaker 1>Well when did when did three come out?

901
00:47:47.519 --> 00:47:49.960
<v Speaker 3>Actually? I think two months ago.

902
00:47:49.920 --> 00:47:53.239
<v Speaker 1>So okay, so back in like February.

903
00:47:52.840 --> 00:47:55.079
<v Speaker 3>Yeah, February March timeframe, I think.

904
00:47:55.239 --> 00:47:57.519
<v Speaker 2>So yeah, okay, you guys are on a fast cadence

905
00:47:57.519 --> 00:47:59.679
<v Speaker 2>then if you're digging before.

906
00:48:00.239 --> 00:48:02.760
<v Speaker 3>That's the advantage when you know d when they went

907
00:48:02.960 --> 00:48:07.639
<v Speaker 3>commercial obviously, right, I mean before it was just Dominic

908
00:48:07.719 --> 00:48:10.320
<v Speaker 3>and Brock working on this in the spare time that

909
00:48:10.360 --> 00:48:13.480
<v Speaker 3>they had between consultancy engagements. And now there is just

910
00:48:13.519 --> 00:48:16.199
<v Speaker 3>a fully flexed company with an amazing team. You know,

911
00:48:16.280 --> 00:48:17.599
<v Speaker 3>dom and Brock are still there.

912
00:48:17.440 --> 00:48:19.760
<v Speaker 1>With a development team that can work full time and

913
00:48:19.800 --> 00:48:20.559
<v Speaker 1>they're going to keep.

914
00:48:20.400 --> 00:48:23.800
<v Speaker 3>Coming alutely absolutely, and you know, we can just provide

915
00:48:23.840 --> 00:48:27.639
<v Speaker 3>better support, faster feature delivery, and you know, we've got

916
00:48:27.679 --> 00:48:29.920
<v Speaker 3>a great team working on it. So it's yeah, going

917
00:48:29.920 --> 00:48:30.440
<v Speaker 3>pretty well.

918
00:48:30.400 --> 00:48:32.800
<v Speaker 2>And still with a community option if you're small, but

919
00:48:32.840 --> 00:48:36.079
<v Speaker 2>if you're making money off this stuff, contribute, Yeah.

920
00:48:35.840 --> 00:48:36.880
<v Speaker 3>Yeah, absolutely, it's.

921
00:48:36.760 --> 00:48:39.039
<v Speaker 1>A good model. Yeah. Or when it's been a delight

922
00:48:39.119 --> 00:48:40.400
<v Speaker 1>talking to you, thank you very.

923
00:48:40.360 --> 00:48:42.320
<v Speaker 3>Much, Thank you so much. It was great to be

924
00:48:42.360 --> 00:48:43.079
<v Speaker 3>on the show.

925
00:48:43.280 --> 00:48:45.079
<v Speaker 1>All right, and we'll see you next time.

926
00:48:45.239 --> 00:49:05.800
<v Speaker 4>I will talk to you next time on dot net frocks.

927
00:49:08.119 --> 00:49:10.840
<v Speaker 1>Dot net Rocks is brought to you by Franklin's Net

928
00:49:10.920 --> 00:49:14.840
<v Speaker 1>and produced by Pop Studios, a full service audio, video

929
00:49:14.960 --> 00:49:19.039
<v Speaker 1>and post production facility located physically in New London, Connecticut,

930
00:49:19.280 --> 00:49:24.079
<v Speaker 1>and of course in the cloud online at pwop dot com.

931
00:49:24.280 --> 00:49:26.400
<v Speaker 1>Visit our website at d O T N E t

932
00:49:26.639 --> 00:49:30.679
<v Speaker 1>R O c k S dot com for RSS feeds, downloads,

933
00:49:30.840 --> 00:49:34.519
<v Speaker 1>mobile apps, comments, and access to the full archives going

934
00:49:34.559 --> 00:49:37.920
<v Speaker 1>back to show number one, recorded in September two thousand

935
00:49:37.960 --> 00:49:40.599
<v Speaker 1>and two. And make sure you check out our sponsors.

936
00:49:40.760 --> 00:49:43.719
<v Speaker 1>They keep us in business. Now go write some code,

937
00:49:44.119 --> 00:49:44.880
<v Speaker 1>see you next time.

938
00:49:45.800 --> 00:50:01.480
<v Speaker 3>You got jam vanst the Bos