May 14, 2025 • 50 mins
How do you secure browser-based frontends with ASP.NET Core backends? Carl and Richard discuss the Backend for Frontend (BFF) Security Framework with Erwin van der Valk. Erwin talks about Sam Newman's BFF Pattern and how it helps deal with the diversity of clients, including web, desktop, and mobile, to work with a common backend. OAuth 2.0 is capable of dealing with this complexity, but there are many moving parts, and that's where the security framework can help!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
(00:21):
dot com. Hey, it's dot net rocks one more time.
I'm Carl Franklin, an amateur camp and man, we are
getting ready to go to build, aren't we getting there? Yeah?
(00:42):
Now that's just about that time.
Speaker 2 (00:44):
There's a lot of you know, for me, I'm organizing
a dozen podcasters so right, and a bunch of different teams.
Speaker 1 (00:50):
So it's an adventure. This is something that we did
in the past together and then you sort of just
took it over, which is fine because you've got all
of the podcasts wrangled from not just dot net, right,
and not just Microsoft, yeah, specifically not just dot net. Yeah.
Speaker 2 (01:05):
We got a bunch of YouTubers well coming out this time,
Tim Corey, who has been on the show not.
Speaker 1 (01:10):
In a long time anyway.
Speaker 2 (01:11):
I love Tim Corey and Derek co Martin, which we
had on recently coming as well. We got one video
studio as well as a few audios do. Yeah, very cool.
So here's the deal, listeners. If you are going to
be at build, find us.
Speaker 1 (01:25):
Yeah. Do you have any idea physically where we're going
to be.
Speaker 2 (01:28):
Yeah, we're on the fourth floor, okay, which is the
community area. We're off on one side there. You'll find
us easy enough. We're there.
Speaker 1 (01:34):
Yeah, stop in and say hi. Yep. All right, let's
get busy with better know a framework. Awesome? All right,
what do you got? So? I'm having a lot of
fun with a sister podcast Security this week, which is myself,
(01:55):
Patrick Hines and Dwayne Laflatte. And if you don't know
who these guys are, Patrick Hines was actually our first guests.
Speaker 2 (02:01):
Well he's now our lucky charm, right, he's the first
guest on all shows we make it seems that's right.
Speaker 1 (02:06):
He was your first guest on run As and I
think he was the first guest on Mondays too. I'm
not sure, but anyway, Patrick is a veteran and a
security expert, and Dwayne is his Red team leader. They
basically do penetration tests for customers. You know, customer says
go ahead, try to hack us and you know, try
(02:28):
to be all clever, and Dwayne was like, okay, done.
So it's just and here's the thing about Security this Week,
which is just the podcast name and Security this Week
dot Com is the page we laugh far more than
we should be laughing while talking about hacks that have
happened at the end of the universe. Yeah, because what
(02:51):
we're talking about is fundamentally scary, you know. Yeah. Sure,
security can be very frightening. Yeah, if you think your
passwords are safe. Mmm. So we have, you know, a
lot of mantras that we say over and over again,
like use a password manager and patch and update your
firmware on your Wi Fi, you know thing whatever all
(03:12):
the time. But I just wanted to mention we also
have a Discord server and it's getting a lot of
traction and we're even handing out swag which are lock
pick sets. Oh yeah, with the Security this Week logo
on them lock pick sets. Yeah. So, so if you
go to Discord dot Security this Week dot com and
(03:33):
don't put hddps in front of it or because it's
a URL DNS router, so just go on your browser
type Discord dot Security this week dot com. You'll get
to our discord server and if you, you know, engage
us and give us some things to think about, we'll
send you a lock pick set cool and that's my
better no framework, that's what you get. Who's talking to
(03:54):
us today? Richard Grab a comment off for show nineteen
forty eight. This is the one which is just a
couple of weeks ago with Rob talking about his open
source maintenance fee and Jimmy Scott had this comment back.
He said, thanks for your time. Rob.
Speaker 2 (04:07):
We are users of wis, which is a product that
Rob maintains, and I was concerned that wicks was going commercial.
Like many others, we use numerous OS projects and I've
suscribed to several of them. The fee is more than
reasonable and we will be subscribing today.
Speaker 1 (04:21):
Awesome.
Speaker 2 (04:21):
Yeah, it was great, great news, and I was very
you know, we've been battling with this problem talking about
how we're going to create sustainable open source on it
for years now. So yeah, Rob's approach, you know, and
again I appreciate it. He's not just postulating. He set
it up. He set it up how to do it
through githubs so you can learn everything you need to
do about it, and clearly Jimmy's taking advantage that. So Jimmy,
(04:43):
thank you so much for your comment. And a copy
of music Goby is on its way to you. And
if you'd like a copy of music Go Buy, I
write a comment on the website dot NetRocks dot com
or on the facebooks. We publish every show there and
if you comment there and a reading the show will
send you copy Music to Go Buy.
Speaker 1 (04:55):
Yeah, And I just wanted to say I'm standing by
sort of watching how it unfolds with other people other
than Rob and this guy or through the only two
people that I know who are using is systems. So
but I plan on jumping in as soon as I
see happy customers. So also a reminder that Music to
(05:15):
Code By is still going strong with twenty two tracks
and you can download the whole collection in MP three
flak or wave at music tocode by dot net. Awesome. Yeah,
and with that, do you want to do the history thing?
Are we done with it? Oh? That's a great idea.
I didn't. I didn't have time to assemble anything. But
it's nineteen fifty. I mean, what can we say, yes
besides el Wells or beginning of the Korean War.
Speaker 2 (05:38):
Oh that that would be one.
Speaker 1 (05:42):
There was that, yeah, yeah, okay.
Speaker 2 (05:46):
But also the very first credit card, the Diner's Card,
no kidding, is nineteen fifty yeah, I said, sort of famous.
It's it's not an apocryphal story, but it's supposed to
be true that Frank McNamara. It was this sales guy
got his wallet in a different suit, took out his clients,
and his wife had to pay. He didn't have any
money on him, and thought, well, it's got to be
(06:07):
a better way and work with a group of folks,
including Alfred Bloomingdale, who was the heir to the Bloomingdale
d department store. So got it into Bloomingdale's right away
and it kicked that whole thing off. Of course, the
big card, what became Visa, comes along later in nineteen
towty eight.
Speaker 1 (06:23):
So did you say it was the diners Club.
Speaker 2 (06:25):
That's what became Diner's Club, but at the time it
was called Diner's Card.
Speaker 1 (06:28):
The Diner's Card.
Speaker 2 (06:29):
Interesting, and it was again focused on restaurants initially, although
rapidly branched into retail.
Speaker 1 (06:34):
So you know, we're getting out of like the war
as well, we're getting into via the not the Vietnam,
the Korean War, but and more interesting things are happening
in compute around this time. Do you have any computer
kind of history.
Speaker 2 (06:49):
The only comput story that's like a lot of things
will happen in the fifties but in fifty is not
a bunch except that at the Canadian World Exposition in
nineteen fifty they had a computer they called Birdie the
Brain and it played tic tac toe. Wow, And apparently
there was huge cues of people to play tic tac
toe against Berdie the Brain.
Speaker 1 (07:09):
Wow. That's cool. Silly but yeah, no, that was silly
but cool.
Speaker 2 (07:14):
And you know that all the write ups talk about
it being artificial intelligence, but none of the stuff at
the time called it artificial intelligence. Yeah, which is Bertie
the Brain. They just called it tic tac toe. Okay,
So with that, I'm going to introduce Erwin. Erwin van
der Walk is an experienced software engineer with the passion
(07:34):
for software design, development practices and web security. He works
as a principal engineer at Dwende Software and is the
product owner for the Dwende BFF That's not Best Friends Forever,
That's back in for front End Security Library and the
popular open source library dwende access token management. In his
spare time, he tries to learn as much as possible
(07:56):
about pretty much anything and everything tech, science, history, and
all things metal, listening, playing guitar, and fighting with historically
accurate long's words.
Speaker 1 (08:08):
Well there's a hobby for you.
Speaker 3 (08:09):
Yeah.
Speaker 1 (08:10):
I don't even know what that means, but uh, welcome, Irwin.
I recently learned what dwen day is. Like, I'm not
the company, but the word. It's a Spanish word that means,
you know, it's sort of what do they what do
they call it? It's it's it's sort of a way
(08:30):
of life, right day. You would call something dwende if
it's amazing, if it's awesome, Yeah, that's the idea. Yeah,
so welcome, Well, thank you very much.
Speaker 3 (08:41):
I'm super excited to be on the show. A long
time listener, so.
Speaker 1 (08:44):
Yeah, we're super excited to have you BFF. Back End
for front end. Yeah, and why why is it back
end for front end and not just back end?
Speaker 3 (08:55):
Well, they call it back and for front end because
tied to a particular front end, you have to have
one back end if you have a micro services or
just an appropriately sized services architecture, behind it. You can
have many services behind your front end, but in this
particular case, you only have one back end for that
(09:16):
front end. And you know, the back end for front
end pattern itself has been also around for quite a
long time, and in this particular case, we're explicitly talking
about adding the security layer on top of that. That's
also how the if the Internet Engineering Task Force defined
it now, but originally it was just if you have
(09:38):
multiple different types of front ends, maybe a mobile, maybe
a web application, you would build a specific back end
for that one front end. And in this particular case,
it's kind of similar, but you have a back end
for a particular front end, but also to provide it
with the authentication services.
Speaker 1 (09:56):
So with MVC fall into that category, and MVC server
because if you think about it, it's serving up hdmun
JavaScript and front end stuff.
Speaker 3 (10:06):
I think the primary goal is to look at what
we call browser based application. So it's a little bit
more like you know, spas applications built with React Angular Blazer,
those type of applications that live primarily in the browser.
They don't necessarily need a one single backhand for them.
I mean, they could use any types of back ends,
(10:27):
but in this particular case, and yeah, maybe it's good
to dive into why we need that thing in the
first place. It is to prevent you from using access
tokens in the browser. Now why would you want that,
Because for a long time, using access tokens in the
browser has been a recommended practice. Right, There's all these
libraries that are out there to handle those in JavaScript.
(10:50):
And that's because the field of security is constantly evolving, right.
I mean, things that were just completely valid in the
past of implicit grand flow for example, is now totally
not recommended anymore because you know, just clear security vulnerabilities
have been discovered in.
Speaker 1 (11:08):
Yeah, you're increasing the surface, the attack surface by allowing
hackers to get in there and mess with the tokens
and try to spoof your back end and all of that,
all the things that hackers do.
Speaker 3 (11:21):
Absolutely And there's the problem, right because within a browser
based application, all the code for that one application is
just mashed together in the same sandbox this week. So
if a hacker is able to inject code in there,
and unfortunately they do. Injection attacks are still the opity
top three absolutely issue. It just happens a lot. Then
(11:45):
an attacker can do exactly what your application is able
to do as well. Now, if that is just impersonating
you while you have your browser online, that's already a problem.
And sure there are ways that you can limit the
attack surface. Then, but if the attacker is able to
take an access token and take that offline, even when
you close down your browser, he's still able to impersonate you,
(12:06):
or even worse right, take what we call a refresh
token and be able to get more and more access
tokens all the time, then you really have a problem
if that happens.
Speaker 1 (12:17):
But these things are require like a sort of a
man in the middle attack, right, This isn't something that
you're going to pick up some malware and somebody's going
to steal your tokens and whatever. Somebody has to really
target you, don't they.
Speaker 3 (12:28):
Well, it is so easy to make a small mistake
while building your web application that opens you up to
cross side scripting attacks. Yeah, I myself not too long
ago found out that if you have a URL and
you add that URL into an image tag all of us,
and that URL comes from another source, that URL could
(12:52):
contain script and that will immediately be executed. So immediately
that turns it into a cross side scripting attack. I
didn't know that, and the library at the time React
doesn't handle that particular case. It does when you bind
a textbox to some data, but it doesn't handle that
particular problem.
Speaker 1 (13:11):
So so you're saying that I could have you know,
IMG source equals HTDP Joe's discount, sharkcages dot com, slashcage
one dot jpeg, and that jpeg could no a jpeg
could contain a script or is it more like a
script tag that loads a JavaScript file from some other site.
Speaker 3 (13:33):
This particular example is a URL that contains script itself.
So it's not necessarily even a URL. It doesn't even
start with htps or something, but it just contains script.
And if you put that into an image tag, it
gets executed and you have a vulnerability.
Speaker 1 (13:49):
Oh if you put it into an image to ic.
So if you set the source for an image tag
to a script file, the script is going to get executed.
Speaker 3 (13:56):
Yes, And this is just one tiny example. I mean,
when you build a browser based application using React or something,
you get a million node files. How do you know
that not one of those tiny node files has a problem.
Speaker 2 (14:09):
I wish you were exaggerating that it was a million
node files, because you're right, so it's so many.
Speaker 3 (14:16):
So here's the point, right, I mean, if you do
everything perfect, then doing what we call public client public
client authorization code flow works and it's secure. But as
soon as you have a tiny little hole in your
browser based security, then what you want to do is
(14:37):
put layers in there. Security is all about adding more
layers and reducing the blast radius if something goes wrong.
Speaker 1 (14:43):
Right, and before you go down that rabbit hole, let
me just say that it's not just a mistake that
you could make. But in your software bill of materials,
which you have right everybody listening, yes, all right, that
is all of the dependencies that you are taking on
in that list, and that list, as Richard said, could
be millions of JavaScript files down the line. And there's
(15:08):
been examples of these where we've depended on a particular
JavaScript library and that library contained a bug and everything crashed.
You're depending on those things, and how are you going
to know if somebody gets in there maliciously does a
pull request and approves it and absolutely Bob's your uncle,
and you won't know.
Speaker 3 (15:28):
Exactly so, and it doesn't even have to be that right,
script injection attacks is just one of the vectors. I mean,
not too long ago, we had Spector. Right, Spector was
a processor based issue. There's a proof of concept that.
Speaker 1 (15:41):
It was a vulnerability in the micro code of Intel processors.
Speaker 3 (15:45):
Exactly. There was a proof of concept out there that
proved that by somehow from one browser window to another
browser window, they could find poke into the memory of
the other browser window. Now that's scary as well, right,
I mean, the point that I'm making is that you
have code running that you know, comes from all kinds
(16:05):
of sources, maybe even you know, add links or whatever. Right,
it comes from all kinds of sources, just execute together,
and anything that that code does, it will you know
that the code can do, you know it might do.
And that's that's a problem. So the BFF pattern comes
in to try and help that. Now, like I mentioned,
(16:27):
the i ETF Enginet Engineering Task Force. That's the group
that's responsible for creating all of these standards in the
first place. Right, they created the OALTH to specification, open
and deconnect all of that, and every now and then
they come out with what they call a best current
Practice document and in there they try to document well,
(16:47):
you know, looking at the landscape, looking at what we
know right now, what is what do we recommend and
what don't we recommend. And one of the things that
they're recommending is to use the BFF pattern. If you
look at it, the BFF pattern consists of a couple
of things. The first thing really important is that the
authentication needs to happen on the server. So in the
(17:09):
server you have what we call a confidential client, and
the confidential client handles all of the authentication with your
identity provider. Now the browser is still involved, but not
the browser based application. It's not the JavaScript based So
all that the front end has to do is redirect
to a log in page or the logout page, and
(17:32):
the server then takes care of the rest. After the
authentication has completed. What the server then does is it
places a cookie on your machine. Now, cookies have a
bit of a bad rep for privacy reasons, of course,
but also you know, for a cross side request forgery attacks,
(17:52):
and we might get into those in a little bit
in a minute, but they're very easily to protect you
against those actually pretty much. Yeah, but cookies have been
around for a long time and actually they you know,
when you apply them properly. They're actually really secure. Sure,
so what happens if you set your cookie to HTTP only.
That means that your JavaScript can't reach them, and they're
(18:14):
just added by the browser implicitly. Now, you can also
set some policies on there, like same site policies, maybe
even underscore underscore host prefix. It's a little bit technical,
but all these flags that you can turn onto your
cookies so that it's more difficult for attackers to to
you know, accidentally get access to those things.
Speaker 1 (18:33):
Got to keep the cookie monster away.
Speaker 3 (18:35):
Yeah, but then once you've once you've configured those cookies correctly,
the authentication just happens. Any call that you make to
your backhand service is just authenticated automatically in a simple
application what you just mentioned, right, just an MVC application,
but then maybe one that exposes APIs the authentication just flows.
Everything's fine, But now if you want to access external services,
(18:59):
you know, micro services that you have running somewhere else,
you don't want the cookie to flow over there because
it can't read those cookies, can't do anything with them there.
Speaker 1 (19:09):
So you need some federated kind of multiple server communication
going on.
Speaker 3 (19:14):
Right, Yeah, Well, what you then do is you exchange
the cookie for an access token, and from that point
on you just have a request from the BFF to
your API using access tokens. And that's just a very
well known pattern to flow, just credentials and information and
security context. Yeah, okay, that is pretty much it. I mean,
(19:38):
there's more that you can add to that.
Speaker 1 (19:40):
But so the access tokens are kind of made up
on the fly, whereas the cookie identifies you to your server. Yeah,
but when you say exchange, you mean, hey, this is
me because I have this cookie, you know who I am.
Give me an authentication token that I can use over
in this API.
Speaker 3 (19:55):
Yes, yeah, and you can still have the choice. I mean,
some APIs they don't want what we call a user
based a token, right, They just want to have a
client credentials token and that's it. You might want to
have a token that's very narrow for that one particular service,
because you might want to have multiple tokens for different services,
and some other service might actually want to have a
(20:17):
token with the subject identifier in it and all kinds
of claims in there as well.
Speaker 1 (20:21):
So we're really talking about authorization at this point, not authentication.
You're authenticated by that cookie. Now authorization takes on this
whole other topic.
Speaker 3 (20:33):
Well, think about it from the perspective of your API.
You're still authenticating, right, because a request comes in, there's
an access token that says who is calling this thing?
And that may just be hey, it's just a BFF
that's calling you. Trust a BFF, right, do your thing,
But it may also be no, this is an access
token that has user information in it, so a subject identifier,
(20:57):
maybe all kinds of other claims that then the might
also use to make coarse grained authorization decisions.
Speaker 1 (21:04):
Sure, sure, okay, So.
Speaker 3 (21:08):
Now on top of that, you can also look at sessions. Now,
the cookie, that's the thing that identifies you as a
but you can store information in the cookie. If you
wanted to, you could store the access token in the cookie.
Now it's still secure. It goes to the browser, but
the browser based application can't reach it, and then that's sorry.
(21:31):
The advantage of that is is that your BFF is
relatively stateless, right, it doesn't need to store that session
information somewhere. But if you were to store that session
information in a database, then you can also do things
like remote sign out, for example, because if you delete
the record from the database, the user is signed out
(21:52):
and you can't access to the system anymore and needs
to log back in again. So there are benefits and
downside of store. You know, your your session information in
a database.
Speaker 1 (22:03):
Sure, and if you have something like Blazer server you
can use or server based stuff. You can use a
protected browser storage, which I guess gives you what five
megabytes of encrypted data on the on the browser per
user per r L. Yeah. Yeah.
Speaker 3 (22:21):
The downside of of these storages in the browser is
that it is still the browser application that reaches into that.
And there's been quite a number of things that have
been tried to to do that. I mean storing things
inside of web workers to to keep them, keep them hidden,
you know, encrypted storage, all of that stuff. But ultimately,
(22:44):
if the browser based application can reach it, you know,
you're exposing that information also to potentially malicious actors.
Speaker 1 (22:52):
I remember one thing that Dom I think it was dumb,
it might have been Brock said, these are the one
day guys over and over again, is that you want
your authorization system to be totally separate from your authentication system. Yes,
you know want those two tied together. And in what
(23:12):
is the asp net core identity where you have just
these databases that do that hold both the authentication passwords,
hashes and also you know, claims, roles and that kind
of stuff. You're really kind of tying the two together.
And I didn't really understand what he meant by that,
(23:33):
but but I get it that that having it separate
just it doesn't tie them together.
Speaker 3 (23:42):
Yeah. I think the key thing to keep in mind
here is that what you get from your identity provider,
and maybe you layer a little bit on top of
that inside of your application, and you could do that
in the BFF as well. Should say something about the
user itself. Right, So I am irwin, I have you
(24:02):
know this role in the organization, right, But as soon
as you start to think about other things like I
have created this particular document, or I am a manager
of that particular department, and therefore I that is not
information that you want to store and managing your identity provider.
That's not part of your identity. That's much more part
(24:25):
of your application domain. And therefore those authorization decisions you
do not want to take purely based on information that's
stored in your cookie and sorting your access token, you
actually want to say no no, no, I am. I'm
defining what we call a policy, and that policy says,
am I allowed to do this given who I am?
(24:46):
And then inside of the code that executes that policy,
you can do lookups like are you the right manager
for this particular thing? Do you have access to that thing.
Speaker 1 (24:57):
If you're rolling your own Well, but I've seen many
customers and I do this myself, is that you have
you know, your your aspnet user's table in identity Core
ASPN Core Identity and then basically what we would do
is create a separate user's table that has all the
application specific data about that user, and then it's related
(25:20):
with a foreign key to that aspnet user in case
you know, so that that's how they're tied together, but
they're still in the same database.
Speaker 3 (25:28):
Yeah, and authorization can become really complex.
Speaker 1 (25:33):
Right.
Speaker 3 (25:33):
You can imagine inside of a big enterprise, one system
controls this particular aspect, that other system controls that particular aspect.
Now there are these systems, you know, policy server being
one of them as an example, right, that might actually say, okay,
you replicate some of the information that's part of your
domain into that server and then you know, since that
(25:56):
information is also stored in there. You can create association
is there. You can say, because this particular person has
this role, this relationship with that other thing, that's why
he's allowed to do these particular things, and those things
can inherit from each other. You can basically model your
authorization domain, but that is only if you have an
(26:18):
application landscape that is complex enough to warrant extracting that.
Speaker 1 (26:23):
Multiple applications from the same vendor. For example. Yeah, and
some customers have access to this application and that application,
but not that one.
Speaker 2 (26:32):
But I also look at it from a administrative versus
regular user role within an app or you can even
be more gradiated that HR can see some things that
sales can't see, Like you need to have someplace for
all of those different levels of authorization to live.
Speaker 3 (26:46):
Yeah, and you know, in an enterprise, what you typically
see is that, you know, especially if the enterprise has
built their own custom software for certain types of things,
that it really warrants you to store that that centrally.
Sometimes you literally have islands where each application stores its
own and has its own logic.
Speaker 1 (27:05):
Around right, yeah, right, you want to take a break,
or yeah, it's a good time. Oh well, yeah, okay,
we'll take a break. We'll be right back after these
very important messages. Stay tuned. Do you have a complex
dot net monolith you'd like to refactor to a micro
services architecture? The micro Service Extractor for dot Net tool
visualizes your app and helps progressively extract code into micro services.
(27:30):
Learn more at aws dot Amazon dot com, slash modernize
and we're back. It's dot NetRocks. I'm Carl Franklin. That's
my friend Richard Campbell. Hey, and that's our friend Erwin
van Dervach from Duende. We're talking about interestingly enough policy
(27:50):
server and why it's such a good idea to separate
authorization policies from authentication databases.
Speaker 3 (27:59):
Yeah, and of course you really have to think, you know,
how complex is your application and do you need to
externalize those decisions? And then you know, is it complex
enough that you need a product for that, because.
Speaker 2 (28:12):
There's an awful lot of cases where identity enough and
authorization are essentially identical. You identify with this so you
get all right, so this app. There is no granularization
of the rights within the app.
Speaker 1 (28:23):
Yeah, and if it's complex enough, you'll know, Yeah, absolutely,
you'll fit that point.
Speaker 2 (28:29):
It's one of those things where the moment I want
to granularize the rights within an app, I probably should
have a.
Speaker 1 (28:34):
Place for all that stuff to live.
Speaker 3 (28:35):
Yeah, coming back to the BFF pattern, right, one of
the things I mentioned is c surf protection. You know,
the challenge with issuing cookies is that cookies are sent
automatically when the browser makes a request to a particular domain.
And the challenge there could be is that if a
(28:58):
malicious actor lures you your users to a malicious site
and he then makes a call from that malicious site
to your application, you don't want, you know, authorized requests
to be sent. Now, browsers already have pretty good protection
baked in there, I mean, and also there's a process
for that, what we call cross origin resource sharing. You
(29:21):
can define policies around that course to define well is
this allowed or not. But unfortunately, there are a couple
of holes that are still allowed by the course you know,
that wouldn't trigger a course policy check, and that could
potentially be dangerous.
Speaker 1 (29:38):
Allow all for example, Well.
Speaker 3 (29:40):
That's if you have a course policy in the first place.
But what I'm talking about here is that there are
certain requests that the browser deemed safe and therefore won't
trigger a course check, and because of that, you know
you could be in trouble. Now, to be fair, dot
net already does a pretty good job of protecting you
(30:01):
against those because they those type of requests would be gets.
Now gets shouldn't manipulate states, so you shouldn't be able
to get into trouble with those. And they can be
simple posts, but as soon as you try to do
a post with a specific content type, that's when you
(30:21):
know the course policy would be would be triggered.
Speaker 1 (30:24):
For example.
Speaker 3 (30:25):
Now, some frameworks, you know, some server side frameworks, they
don't do a very good job of checking those content types.
But dot Net, by default, if you say, hey, you know,
I'm expecting a post that's just an adjacent document, you know,
it will not accept it if it's not adjacent post.
Speaker 1 (30:44):
Is it just raise an error?
Speaker 3 (30:45):
Yeah, it would just say hey, this is the wrong
content type, I go away.
Speaker 1 (30:48):
Yeah.
Speaker 3 (30:48):
Right, So fortunately dot net also helps you with that.
But again, right, security is about more layers. So there's
a very simple way of tackling this. Now, Microsoft provides
you with se SERF protection, right, so cross side request
forger reprotection, but it is based on encryption, and you
need to specify the data protection keys and all your servers,
(31:11):
and if you make a mistake there, you know it
doesn't work. But the very simple thing is just to
say in your BFF server to demand that a specific
header is there. And I'm saying specific header. It really
doesn't matter what the header is as long as it's
a custom header. So your front end just always sends
that header, no problem, right, It could be you know
(31:33):
x SE serf equals one, doesn't matter, right, Your front
end just always sends that. If the malicious site wants
to call your service, it doesn't have that header, so
it will that your your BFF will say I'm not
letting you in. If the malicious site then tries to
add that header, now you're adding a custom header to
(31:55):
the request and that triggers the course policies in a browser,
so it stops all the sea surf attacks dead. So
just by demanding in your server you must have a
custom header, and as long as you have an agreement
between your backhand and your front end, hey, send that header.
Speaker 1 (32:13):
You're safe.
Speaker 3 (32:15):
That's kind of cool.
Speaker 1 (32:16):
That's kind of cool.
Speaker 2 (32:17):
And can you read something in that header that's like
a security key or something not easily spoofed.
Speaker 3 (32:23):
You don't have to. That's the thing. I mean, this
confused me in the beginning quite a bit because I thought, well.
Speaker 1 (32:30):
Why headers or headers? They should be able to make
anything I want.
Speaker 3 (32:33):
Yeah, But the point is is that the browser standards
they dictate that if you do a cross origin call
and you do that with a specific header, that first
you must do a course policy check and then that
course policy comes into play. Now, if you screw up
your course policy, if you say course policy allow all, sure,
(32:56):
you're still vulnerable. But here's the point, right, if you
do it correctly, then you're secure. And by default, by
the way, if you don't specify a course policy, the
course policy is deny. So you're pretty secure if you
don't do anything there. There's a couple of other things
that you could look at. I mean, Blazer support is
an interesting one. I Mean, the thing with Blazer is
(33:18):
is that it's a really powerful framework, but because of
all of its rendering modes, you have to pay attention, right,
I mean, if you're doing purely service side rendering, then
you're just building a regular application. But if you start
mixing those interactivity modes, especially in the auto rendering mode.
(33:39):
Then some communication might go over web sockets, some communication
might be with web requests, and yeah, you just have
to you know, look at all, how are you going
to set the you know, as soon as you start
doing web requests, right, so regularates to be requests. Yeah,
(33:59):
you just have to make sure that you're calling it
with the right credentials. Now, inside of the do end,
the BFF framework, the one that I'm responsible for as well,
we try to make sure that that is all unified
so that you just have a single programming model that
you can code in your Blazer back end, in your
front end, and the auto rendering modes just work work seamlessly.
(34:21):
But if you don't use that framework, if you just
want to build your own then of course. And if
you do use Blazer, then that's one thing to watch
out for as well.
Speaker 2 (34:30):
And does the Blazer mode matter, like you have to
be in client mode for this to make sense or
do It'll work the same either way.
Speaker 3 (34:36):
Now, well, so here's the thing. Right with the auto
rendering mode. If you say I want to display a
list on the screen, there's three things that can happen.
One is it get rented on the server, and that's
actually what happens initially, right, it's rented on the server
and then send to the browsers HTML. So then you
need to have on the server. You need to be
(34:57):
able to get to that data. That might either be
just go directly to the database because you're in the
same space, or you're doing a call to an external service,
and therefore you need to make sure that there's an
access token on the ah top client to call that
external service. When you are in interactive mode, right, so
it's running on the in the it switches over to
(35:22):
web assembly mode. Then all of a sudden, it's the
browser that does that request, right, And you can't go
from the browser directly to that API in point because
first of all, it might just be in an internal network, right,
the browser doesn't have access directly to that API in
point right, And second of all, you don't have that
access token. You don't want that access token there, so
then you need to proxy that request using a reverse
(35:44):
proxy through the BFF, and then the BFF does that token,
the cookie exchange for the token, and then goes out
to that external service. So that's how that's supposed to
work together.
Speaker 2 (35:58):
Then as well, trying to figure out how much work
I actually have to do to implement this framework. It
sounds almost like a drop in thing and that should
be good to go.
Speaker 3 (36:05):
Yeah, I mean, if you want to build it yourself,
then of course you need to know what you're doing,
and you know, Microsoft provides a bunch of things, but.
Speaker 1 (36:14):
That's never stopping before or when.
Speaker 3 (36:15):
Come on, yeah, of course, but I mean you know
you need to You can use YARP, that's a really
good reverse proxy. I mean, you can use the Microsoft
libraries for that. We provide an open source library for
access token management, so that there's a bunch of things
that you can do, and if you know what you're doing,
then you can just do that. If you rather use
(36:36):
a product, then of course, you know, we provide a
product that you can also. You know, if you uh,
it is.
Speaker 1 (36:41):
A new GET package, right like this isn't it.
Speaker 3 (36:43):
It's just a new Get packaging. You plug it in
with a couple of lines of code, you have it working,
and you know, we have a community license as well,
so that if you uh, you know, I think it's
if you make less than a couple of million of years,
then you can just use the product for free. Right
if you make over that then you know, you pay
a little bit and then you get a nice product
(37:04):
for that.
Speaker 2 (37:05):
So yeah, no, and you said, drop in a couple
of configuration things. You're working and you've you're using this
whole TLS approach, like your life is better.
Speaker 3 (37:15):
Absolutely. Now there's one thing that we're also working on,
and it kind of bleeds into more operations, right because
if you have a purely browser based application, you can
just host that on a CD and and you know,
run that somewhere and now all of a sudden, you
do need a back end component for that. Now, if
(37:35):
you do that for your first application, you have a
really nice you know, you've got a nice back end
for your front end. It's all good. But typically, you know,
especially enterprises, they have a lot of applications and then
they come to the conclusions like I have a lot
of BFFs here, you know, can't we do anything about that? Right,
So one of the things that we're about to release
is multi front end support as well, So you can
(37:56):
have a single BFF that just you know, from the
perspective of the front end, it is just a single
back end for front end, but physically it's a single
host that can serve many of.
Speaker 2 (38:07):
Them, right, so you don't end up with one for
every app, which can get untenable. You have exactly collective
because they're all using the same right sets and so forth. Like,
this is all very shareable, and I suspet it's like
ninety five percent in common between apps and there's just
a few exceptions.
Speaker 3 (38:22):
Yeah, exactly. Now, now there's a couple of other things
that I mean, I've applied this pattern a lot of
times already in my career, and one of the things
that I'm finding is that it also helps my collaboration
with front end developers. I mean, I am primarily a
back end developer. I know enough about a front end
to being dangerous, but primarily a back end developer. But
(38:43):
when I'm working with front end developers, it's really nice
to have what I typically call then a dev server.
Nowadays you would build that with Aspire. You have something
that front end engineers can just run and it's just
just running there nicely, and they can iterate on building
their front ends. And as a back end engineer, I
mean I just spin up the front end and my
(39:03):
back end is there, and I can iterate on my
back end. And if you have a branch. Where you
have both of them, you can easily work together on
them with the front end. You compare program. Hey, I
build this in the front end, build this in the
back end, work together. It's just a really nice flow
to to collaborate together.
Speaker 2 (39:21):
So and then is the BFF security framework. It's again,
it's just a new GET package. So is it just
a line in Aspire to say include this and just
another part of the equation.
Speaker 3 (39:34):
Right now, it is just a new GET package that
you need to install inside of your web application. In
the near future, yes, it's going to be just a
container that you can just run and aspire and from
that point on you can use that as a development experience.
Speaker 1 (39:49):
Very cool. Yeah, I'd like it. I just like that
in my template.
Speaker 2 (39:51):
I'm thinking, I'm thinking very enterprising here about how do
I get my devs on the path to using these
tools from the outset?
Speaker 3 (39:58):
Yeah, yeah, absolutely, And that's exactly what we see people
do for this, and you know, and there's nice tricks
that you can do there with that, because one of
the things that you know, as a back end engineer,
I don't sometimes even have all the front end tools installed,
and there's like a gazillion of them. So what I
typically do then.
Speaker 1 (40:16):
Is again not an exaggeration, no, and gazillion.
Speaker 3 (40:20):
So when I just start up the back end, it
just loads the most recent front end from my dev
environment in the clouds. It gets it from a CDN
right right. But then if I start up both of them,
I can detect, hey, the front end code is running locally.
Let me just take the front end code locally and
serve that from there instead of them from the CDN server.
(40:42):
So that's a really nice experience. Then. You know, if
I don't care about the front end, I can just
start it up. If I do care about it, especially
when working together, you start them up both and they
just start working together. That's a really nice experience there
as well.
Speaker 2 (40:54):
For sure, What about the telemetry side, is there any
information coming out of this framework that helps me as
an on the administrator side knowing what privileges are being
gained and so forth.
Speaker 1 (41:06):
Is that still be part of the regular system.
Speaker 3 (41:08):
Yeah, that's the actual authentication bit. I mean, we track
how many tokens are being exchanged, and we do metrics
for those type of things. And of course if you
use service side sessions, you know exactly how many people
(41:28):
are online at any point in time, so you can
also do metrics for those, but actually publishing these metrics
as open telemetry is something that we haven't built in yet, right,
And there is a reason for that as well, is
that all of the traffic between your front end and
your APIs flows through the BFF, so it has to
(41:51):
reverse proxy those otherwise the cookie won't flow and therefore
the reverse proxy is very secured, very performance sensitive. I mean,
you don't want delays in there for reasons. So if
you were to add if we were to add code
in there that says every five minutes, look how many
users there are, look how many you know, and publish
(42:12):
those as statistics, right, we might, you know, negatively impact
your performance. So we don't want to do that obviously.
Speaker 2 (42:21):
Sure, I'm just thinking about additional telemetry you'd have access to,
just because you can see these tokens flowing around. But yeah,
and it's always a debate as to how much what
do you want, Like where is that?
Speaker 1 (42:32):
What is that useful for?
Speaker 3 (42:33):
Absolutely?
Speaker 2 (42:34):
Certainly when you're trying to do a call chain, knowing
what token was issued, when it was issued, when it expired,
like that's all part of that chain.
Speaker 3 (42:43):
Oh yeah, well, and access to cam management does alog
quite a lot of information.
Speaker 2 (42:49):
Yeah, that's the thing that's a lot of that's already
handled for you. Absolutely not your problem. You're just calling
into those services.
Speaker 3 (42:55):
Technically, it's my problem because I'm also the product owner
for access to com management.
Speaker 2 (42:59):
Well you're also the COGA provider. But that's not the
security framework's fault. No, exactly, exactly. Now I'll get that
telemetry for identity server. Yeah, but I mean, yeah, I'm
just thin get through all the issues.
Speaker 3 (43:10):
No, absolutely, absolutely so.
Speaker 1 (43:13):
Yeah, So is there anything that we missed, any gotchas
that people might run into, or any other issues around
this BFF pattern that people find tricky.
Speaker 3 (43:26):
Well, I mean there's a couple of ways that you
can host this really in production that might be interesting
to have a look at. So the absolute simplest way
of hosting this is to say, hey, it's just like
you know, you're bundling your back end code with your
front end code and publishing that as a single unit,
(43:47):
deploy that into the cloud or wherever you deploy it,
and then your back end just serves that, right. And
challenge with that is is that every time you want
to make a change to your front end, you have
to redeploy your back end as well, and that's just
very common. So what we typically see is that front
end engineers they bundle their software and they deploy that
to a CDN, and the back end is deployed, you know,
(44:10):
via a different channel, and they might even have different cadences.
It depends on how you structure your organization.
Speaker 2 (44:18):
You would hope like that's kind of a cool thing,
right in my perfect world, As a new version of
the client is coming up, the back end's already been deployed.
It's been running for a while, well just with some
dark features.
Speaker 3 (44:29):
Sure, I mean, but when you make a new version,
right you can You know, if you work, for example,
in a mono RepA where both your front end code
and your back end code is in the same repository,
you could have some logic in your bill pipeline that says,
if only a change happens in the back end code,
I will only deploy the back end if it change
only happens in the front end code.
Speaker 1 (44:50):
Yeah. That scares me.
Speaker 2 (44:51):
I think I want my back end and it container
my front and deployed a CD end.
Speaker 1 (44:54):
Yeah.
Speaker 3 (44:55):
Yeah, but you can still do that. But then you
can have different deployment pipelines for each of them. Now,
so what you then still have a choice, And the
choice is because your code is running in a CD
and your your BFF is running UH and a container
app somewhere, you still have the choice to say the
initial request and the domain name where you're going to
(45:17):
is that owned by the b f F or is
that owned by the front end. Now, the difference is
is that if it's owned by the front end, you're
going to to the CDN directly, so to speak, and
then you're getting the index ahe tmail there, and then
you want to do calls to the BFF that has
to be on the same what we call the same site.
(45:39):
It can be a subdomain, but a site unfortunately is
defined as top level domain minus one, so it also
can include subdomains there. So within subdom you can say,
I've got you know API dot my company dot com,
and I've got you know frontend dot A my company
dot com. And they can share cookies, they can send
(46:01):
cookies to each other if you can figure that correctly.
Speaker 1 (46:04):
If it was easy, we could buy it at seven eleven. Right.
That's why developers.
Speaker 3 (46:09):
The other option and that's the one that I personally prefer,
but you know that's just me. Is that you go
to your BFF. The BFF serves the index document, which
it gets from the CDN by the way, but it
can catch that. And then in the index document you
have all the links to your CDN and that can
be just in an other domain, it doesn't really matter.
(46:30):
That's just static content that gets loaded from your CDN.
And then you have also the option to inject some
script in your in your htmail page if you want to.
You have a little bit more flexibility in you know,
setting up some things and you don't have to you know,
the secured communication is always going onto the same same
(46:51):
domain name, so that's kind of nice. So that's my preference,
but you know, you can you can decide how you
want to deploy these these things.
Speaker 1 (46:57):
I'll stick with your preference. Thank you very much. The
tried and true. Right, what's next for you? What are
you what's coming up in your inbox?
Speaker 3 (47:07):
All right, Well, we're working on two big releases. Access
to com Management fee for is going to come out.
And you know access to com Management has been you know,
originally created by Dom and Brock and it's it's quite
you know, quite an old library. It's been it's been
around for quite a while and it's been of course
updated to the latest specifications. But now we're finding that
(47:29):
we you know, we want to update it a little
bit more to also the most modern coding standards. So
that's the thing that we're that we're working on. And
we're working on b f F FEE for which which
includes that multi funt ten support. So that's going to
come out fairly soon and it's also quite a big release.
Speaker 1 (47:45):
Well when did when did three come out?
Speaker 3 (47:47):
Actually? I think two months ago.
Speaker 1 (47:49):
So okay, so back in like February.
Speaker 3 (47:52):
Yeah, February March timeframe, I think.
Speaker 2 (47:55):
So yeah, okay, you guys are on a fast cadence
then if you're digging before.
Speaker 3 (48:00):
That's the advantage when you know d when they went
commercial obviously, right, I mean before it was just Dominic
and Brock working on this in the spare time that
they had between consultancy engagements. And now there is just
a fully flexed company with an amazing team. You know,
dom and Brock are still there.
Speaker 1 (48:17):
With a development team that can work full time and
they're going to keep.
Speaker 3 (48:20):
Coming alutely absolutely, and you know, we can just provide
better support, faster feature delivery, and you know, we've got
a great team working on it. So it's yeah, going
pretty well.
Speaker 2 (48:30):
And still with a community option if you're small, but
if you're making money off this stuff, contribute, Yeah.
Speaker 3 (48:35):
Yeah, absolutely, it's.
Speaker 1 (48:36):
A good model. Yeah. Or when it's been a delight
talking to you, thank you very.
Speaker 3 (48:40):
Much, Thank you so much. It was great to be
on the show.
Speaker 1 (48:43):
All right, and we'll see you next time.
Speaker 4 (48:45):
I will talk to you next time on dot net frocks.
Speaker 1 (49:08):
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com.
Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
(49:30):
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two thousand
and two. And make sure you check out our sponsors.
They keep us in business. Now go write some code,
see you next time.
Speaker 3 (49:45):
You got jam vanst the Bos
How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
(00:21):
dot com. Hey, it's dot net rocks one more time.
I'm Carl Franklin, an amateur camp and man, we are
getting ready to go to build, aren't we getting there? Yeah?
(00:42):
Now that's just about that time.
Speaker 2 (00:44):
There's a lot of you know, for me, I'm organizing
a dozen podcasters so right, and a bunch of different teams.
Speaker 1 (00:50):
So it's an adventure. This is something that we did
in the past together and then you sort of just
took it over, which is fine because you've got all
of the podcasts wrangled from not just dot net, right,
and not just Microsoft, yeah, specifically not just dot net. Yeah.
Speaker 2 (01:05):
We got a bunch of YouTubers well coming out this time,
Tim Corey, who has been on the show not.
Speaker 1 (01:10):
In a long time anyway.
Speaker 2 (01:11):
I love Tim Corey and Derek co Martin, which we
had on recently coming as well. We got one video
studio as well as a few audios do. Yeah, very cool.
So here's the deal, listeners. If you are going to
be at build, find us.
Speaker 1 (01:25):
Yeah. Do you have any idea physically where we're going
to be.
Speaker 2 (01:28):
Yeah, we're on the fourth floor, okay, which is the
community area. We're off on one side there. You'll find
us easy enough. We're there.
Speaker 1 (01:34):
Yeah, stop in and say hi. Yep. All right, let's
get busy with better know a framework. Awesome? All right,
what do you got? So? I'm having a lot of
fun with a sister podcast Security this week, which is myself,
(01:55):
Patrick Hines and Dwayne Laflatte. And if you don't know
who these guys are, Patrick Hines was actually our first guests.
Speaker 2 (02:01):
Well he's now our lucky charm, right, he's the first
guest on all shows we make it seems that's right.
Speaker 1 (02:06):
He was your first guest on run As and I
think he was the first guest on Mondays too. I'm
not sure, but anyway, Patrick is a veteran and a
security expert, and Dwayne is his Red team leader. They
basically do penetration tests for customers. You know, customer says
go ahead, try to hack us and you know, try
(02:28):
to be all clever, and Dwayne was like, okay, done.
So it's just and here's the thing about Security this Week,
which is just the podcast name and Security this Week
dot Com is the page we laugh far more than
we should be laughing while talking about hacks that have
happened at the end of the universe. Yeah, because what
(02:51):
we're talking about is fundamentally scary, you know. Yeah. Sure,
security can be very frightening. Yeah, if you think your
passwords are safe. Mmm. So we have, you know, a
lot of mantras that we say over and over again,
like use a password manager and patch and update your
firmware on your Wi Fi, you know thing whatever all
(03:12):
the time. But I just wanted to mention we also
have a Discord server and it's getting a lot of
traction and we're even handing out swag which are lock
pick sets. Oh yeah, with the Security this Week logo
on them lock pick sets. Yeah. So, so if you
go to Discord dot Security this Week dot com and
(03:33):
don't put hddps in front of it or because it's
a URL DNS router, so just go on your browser
type Discord dot Security this week dot com. You'll get
to our discord server and if you, you know, engage
us and give us some things to think about, we'll
send you a lock pick set cool and that's my
better no framework, that's what you get. Who's talking to
(03:54):
us today? Richard Grab a comment off for show nineteen
forty eight. This is the one which is just a
couple of weeks ago with Rob talking about his open
source maintenance fee and Jimmy Scott had this comment back.
He said, thanks for your time. Rob.
Speaker 2 (04:07):
We are users of wis, which is a product that
Rob maintains, and I was concerned that wicks was going commercial.
Like many others, we use numerous OS projects and I've
suscribed to several of them. The fee is more than
reasonable and we will be subscribing today.
Speaker 1 (04:21):
Awesome.
Speaker 2 (04:21):
Yeah, it was great, great news, and I was very
you know, we've been battling with this problem talking about
how we're going to create sustainable open source on it
for years now. So yeah, Rob's approach, you know, and
again I appreciate it. He's not just postulating. He set
it up. He set it up how to do it
through githubs so you can learn everything you need to
do about it, and clearly Jimmy's taking advantage that. So Jimmy,
(04:43):
thank you so much for your comment. And a copy
of music Goby is on its way to you. And
if you'd like a copy of music Go Buy, I
write a comment on the website dot NetRocks dot com
or on the facebooks. We publish every show there and
if you comment there and a reading the show will
send you copy Music to Go Buy.
Speaker 1 (04:55):
Yeah, And I just wanted to say I'm standing by
sort of watching how it unfolds with other people other
than Rob and this guy or through the only two
people that I know who are using is systems. So
but I plan on jumping in as soon as I
see happy customers. So also a reminder that Music to
(05:15):
Code By is still going strong with twenty two tracks
and you can download the whole collection in MP three
flak or wave at music tocode by dot net. Awesome. Yeah,
and with that, do you want to do the history thing?
Are we done with it? Oh? That's a great idea.
I didn't. I didn't have time to assemble anything. But
it's nineteen fifty. I mean, what can we say, yes
besides el Wells or beginning of the Korean War.
Speaker 2 (05:38):
Oh that that would be one.
Speaker 1 (05:42):
There was that, yeah, yeah, okay.
Speaker 2 (05:46):
But also the very first credit card, the Diner's Card,
no kidding, is nineteen fifty yeah, I said, sort of famous.
It's it's not an apocryphal story, but it's supposed to
be true that Frank McNamara. It was this sales guy
got his wallet in a different suit, took out his clients,
and his wife had to pay. He didn't have any
money on him, and thought, well, it's got to be
(06:07):
a better way and work with a group of folks,
including Alfred Bloomingdale, who was the heir to the Bloomingdale
d department store. So got it into Bloomingdale's right away
and it kicked that whole thing off. Of course, the
big card, what became Visa, comes along later in nineteen
towty eight.
Speaker 1 (06:23):
So did you say it was the diners Club.
Speaker 2 (06:25):
That's what became Diner's Club, but at the time it
was called Diner's Card.
Speaker 1 (06:28):
The Diner's Card.
Speaker 2 (06:29):
Interesting, and it was again focused on restaurants initially, although
rapidly branched into retail.
Speaker 1 (06:34):
So you know, we're getting out of like the war
as well, we're getting into via the not the Vietnam,
the Korean War, but and more interesting things are happening
in compute around this time. Do you have any computer
kind of history.
Speaker 2 (06:49):
The only comput story that's like a lot of things
will happen in the fifties but in fifty is not
a bunch except that at the Canadian World Exposition in
nineteen fifty they had a computer they called Birdie the
Brain and it played tic tac toe. Wow, And apparently
there was huge cues of people to play tic tac
toe against Berdie the Brain.
Speaker 1 (07:09):
Wow. That's cool. Silly but yeah, no, that was silly
but cool.
Speaker 2 (07:14):
And you know that all the write ups talk about
it being artificial intelligence, but none of the stuff at
the time called it artificial intelligence. Yeah, which is Bertie
the Brain. They just called it tic tac toe. Okay,
So with that, I'm going to introduce Erwin. Erwin van
der Walk is an experienced software engineer with the passion
(07:34):
for software design, development practices and web security. He works
as a principal engineer at Dwende Software and is the
product owner for the Dwende BFF That's not Best Friends Forever,
That's back in for front End Security Library and the
popular open source library dwende access token management. In his
spare time, he tries to learn as much as possible
(07:56):
about pretty much anything and everything tech, science, history, and
all things metal, listening, playing guitar, and fighting with historically
accurate long's words.
Speaker 1 (08:08):
Well there's a hobby for you.
Speaker 3 (08:09):
Yeah.
Speaker 1 (08:10):
I don't even know what that means, but uh, welcome, Irwin.
I recently learned what dwen day is. Like, I'm not
the company, but the word. It's a Spanish word that means,
you know, it's sort of what do they what do
they call it? It's it's it's sort of a way
(08:30):
of life, right day. You would call something dwende if
it's amazing, if it's awesome, Yeah, that's the idea. Yeah,
so welcome, Well, thank you very much.
Speaker 3 (08:41):
I'm super excited to be on the show. A long
time listener, so.
Speaker 1 (08:44):
Yeah, we're super excited to have you BFF. Back End
for front end. Yeah, and why why is it back
end for front end and not just back end?
Speaker 3 (08:55):
Well, they call it back and for front end because
tied to a particular front end, you have to have
one back end if you have a micro services or
just an appropriately sized services architecture, behind it. You can
have many services behind your front end, but in this
particular case, you only have one back end for that
(09:16):
front end. And you know, the back end for front
end pattern itself has been also around for quite a
long time, and in this particular case, we're explicitly talking
about adding the security layer on top of that. That's
also how the if the Internet Engineering Task Force defined
it now, but originally it was just if you have
(09:38):
multiple different types of front ends, maybe a mobile, maybe
a web application, you would build a specific back end
for that one front end. And in this particular case,
it's kind of similar, but you have a back end
for a particular front end, but also to provide it
with the authentication services.
Speaker 1 (09:56):
So with MVC fall into that category, and MVC server
because if you think about it, it's serving up hdmun
JavaScript and front end stuff.
Speaker 3 (10:06):
I think the primary goal is to look at what
we call browser based application. So it's a little bit
more like you know, spas applications built with React Angular Blazer,
those type of applications that live primarily in the browser.
They don't necessarily need a one single backhand for them.
I mean, they could use any types of back ends,
(10:27):
but in this particular case, and yeah, maybe it's good
to dive into why we need that thing in the
first place. It is to prevent you from using access
tokens in the browser. Now why would you want that,
Because for a long time, using access tokens in the
browser has been a recommended practice. Right, There's all these
libraries that are out there to handle those in JavaScript.
(10:50):
And that's because the field of security is constantly evolving, right.
I mean, things that were just completely valid in the
past of implicit grand flow for example, is now totally
not recommended anymore because you know, just clear security vulnerabilities
have been discovered in.
Speaker 1 (11:08):
Yeah, you're increasing the surface, the attack surface by allowing
hackers to get in there and mess with the tokens
and try to spoof your back end and all of that,
all the things that hackers do.
Speaker 3 (11:21):
Absolutely And there's the problem, right because within a browser
based application, all the code for that one application is
just mashed together in the same sandbox this week. So
if a hacker is able to inject code in there,
and unfortunately they do. Injection attacks are still the opity
top three absolutely issue. It just happens a lot. Then
(11:45):
an attacker can do exactly what your application is able
to do as well. Now, if that is just impersonating
you while you have your browser online, that's already a problem.
And sure there are ways that you can limit the
attack surface. Then, but if the attacker is able to
take an access token and take that offline, even when
you close down your browser, he's still able to impersonate you,
(12:06):
or even worse right, take what we call a refresh
token and be able to get more and more access
tokens all the time, then you really have a problem
if that happens.
Speaker 1 (12:17):
But these things are require like a sort of a
man in the middle attack, right, This isn't something that
you're going to pick up some malware and somebody's going
to steal your tokens and whatever. Somebody has to really
target you, don't they.
Speaker 3 (12:28):
Well, it is so easy to make a small mistake
while building your web application that opens you up to
cross side scripting attacks. Yeah, I myself not too long
ago found out that if you have a URL and
you add that URL into an image tag all of us,
and that URL comes from another source, that URL could
(12:52):
contain script and that will immediately be executed. So immediately
that turns it into a cross side scripting attack. I
didn't know that, and the library at the time React
doesn't handle that particular case. It does when you bind
a textbox to some data, but it doesn't handle that
particular problem.
Speaker 1 (13:11):
So so you're saying that I could have you know,
IMG source equals HTDP Joe's discount, sharkcages dot com, slashcage
one dot jpeg, and that jpeg could no a jpeg
could contain a script or is it more like a
script tag that loads a JavaScript file from some other site.
Speaker 3 (13:33):
This particular example is a URL that contains script itself.
So it's not necessarily even a URL. It doesn't even
start with htps or something, but it just contains script.
And if you put that into an image tag, it
gets executed and you have a vulnerability.
Speaker 1 (13:49):
Oh if you put it into an image to ic.
So if you set the source for an image tag
to a script file, the script is going to get executed.
Speaker 3 (13:56):
Yes, And this is just one tiny example. I mean,
when you build a browser based application using React or something,
you get a million node files. How do you know
that not one of those tiny node files has a problem.
Speaker 2 (14:09):
I wish you were exaggerating that it was a million
node files, because you're right, so it's so many.
Speaker 3 (14:16):
So here's the point, right, I mean, if you do
everything perfect, then doing what we call public client public
client authorization code flow works and it's secure. But as
soon as you have a tiny little hole in your
browser based security, then what you want to do is
(14:37):
put layers in there. Security is all about adding more
layers and reducing the blast radius if something goes wrong.
Speaker 1 (14:43):
Right, and before you go down that rabbit hole, let
me just say that it's not just a mistake that
you could make. But in your software bill of materials,
which you have right everybody listening, yes, all right, that
is all of the dependencies that you are taking on
in that list, and that list, as Richard said, could
be millions of JavaScript files down the line. And there's
(15:08):
been examples of these where we've depended on a particular
JavaScript library and that library contained a bug and everything crashed.
You're depending on those things, and how are you going
to know if somebody gets in there maliciously does a
pull request and approves it and absolutely Bob's your uncle,
and you won't know.
Speaker 3 (15:28):
Exactly so, and it doesn't even have to be that right,
script injection attacks is just one of the vectors. I mean,
not too long ago, we had Spector. Right, Spector was
a processor based issue. There's a proof of concept that.
Speaker 1 (15:41):
It was a vulnerability in the micro code of Intel processors.
Speaker 3 (15:45):
Exactly. There was a proof of concept out there that
proved that by somehow from one browser window to another
browser window, they could find poke into the memory of
the other browser window. Now that's scary as well, right,
I mean, the point that I'm making is that you
have code running that you know, comes from all kinds
(16:05):
of sources, maybe even you know, add links or whatever. Right,
it comes from all kinds of sources, just execute together,
and anything that that code does, it will you know
that the code can do, you know it might do.
And that's that's a problem. So the BFF pattern comes
in to try and help that. Now, like I mentioned,
(16:27):
the i ETF Enginet Engineering Task Force. That's the group
that's responsible for creating all of these standards in the
first place. Right, they created the OALTH to specification, open
and deconnect all of that, and every now and then
they come out with what they call a best current
Practice document and in there they try to document well,
(16:47):
you know, looking at the landscape, looking at what we
know right now, what is what do we recommend and
what don't we recommend. And one of the things that
they're recommending is to use the BFF pattern. If you
look at it, the BFF pattern consists of a couple
of things. The first thing really important is that the
authentication needs to happen on the server. So in the
(17:09):
server you have what we call a confidential client, and
the confidential client handles all of the authentication with your
identity provider. Now the browser is still involved, but not
the browser based application. It's not the JavaScript based So
all that the front end has to do is redirect
to a log in page or the logout page, and
(17:32):
the server then takes care of the rest. After the
authentication has completed. What the server then does is it
places a cookie on your machine. Now, cookies have a
bit of a bad rep for privacy reasons, of course,
but also you know, for a cross side request forgery attacks,
(17:52):
and we might get into those in a little bit
in a minute, but they're very easily to protect you
against those actually pretty much. Yeah, but cookies have been
around for a long time and actually they you know,
when you apply them properly. They're actually really secure. Sure,
so what happens if you set your cookie to HTTP only.
That means that your JavaScript can't reach them, and they're
(18:14):
just added by the browser implicitly. Now, you can also
set some policies on there, like same site policies, maybe
even underscore underscore host prefix. It's a little bit technical,
but all these flags that you can turn onto your
cookies so that it's more difficult for attackers to to
you know, accidentally get access to those things.
Speaker 1 (18:33):
Got to keep the cookie monster away.
Speaker 3 (18:35):
Yeah, but then once you've once you've configured those cookies correctly,
the authentication just happens. Any call that you make to
your backhand service is just authenticated automatically in a simple
application what you just mentioned, right, just an MVC application,
but then maybe one that exposes APIs the authentication just flows.
Everything's fine, But now if you want to access external services,
(18:59):
you know, micro services that you have running somewhere else,
you don't want the cookie to flow over there because
it can't read those cookies, can't do anything with them there.
Speaker 1 (19:09):
So you need some federated kind of multiple server communication
going on.
Speaker 3 (19:14):
Right, Yeah, Well, what you then do is you exchange
the cookie for an access token, and from that point
on you just have a request from the BFF to
your API using access tokens. And that's just a very
well known pattern to flow, just credentials and information and
security context. Yeah, okay, that is pretty much it. I mean,
(19:38):
there's more that you can add to that.
Speaker 1 (19:40):
But so the access tokens are kind of made up
on the fly, whereas the cookie identifies you to your server. Yeah,
but when you say exchange, you mean, hey, this is
me because I have this cookie, you know who I am.
Give me an authentication token that I can use over
in this API.
Speaker 3 (19:55):
Yes, yeah, and you can still have the choice. I mean,
some APIs they don't want what we call a user
based a token, right, They just want to have a
client credentials token and that's it. You might want to
have a token that's very narrow for that one particular service,
because you might want to have multiple tokens for different services,
and some other service might actually want to have a
(20:17):
token with the subject identifier in it and all kinds
of claims in there as well.
Speaker 1 (20:21):
So we're really talking about authorization at this point, not authentication.
You're authenticated by that cookie. Now authorization takes on this
whole other topic.
Speaker 3 (20:33):
Well, think about it from the perspective of your API.
You're still authenticating, right, because a request comes in, there's
an access token that says who is calling this thing?
And that may just be hey, it's just a BFF
that's calling you. Trust a BFF, right, do your thing,
But it may also be no, this is an access
token that has user information in it, so a subject identifier,
(20:57):
maybe all kinds of other claims that then the might
also use to make coarse grained authorization decisions.
Speaker 1 (21:04):
Sure, sure, okay, So.
Speaker 3 (21:08):
Now on top of that, you can also look at sessions. Now,
the cookie, that's the thing that identifies you as a
but you can store information in the cookie. If you
wanted to, you could store the access token in the cookie.
Now it's still secure. It goes to the browser, but
the browser based application can't reach it, and then that's sorry.
(21:31):
The advantage of that is is that your BFF is
relatively stateless, right, it doesn't need to store that session
information somewhere. But if you were to store that session
information in a database, then you can also do things
like remote sign out, for example, because if you delete
the record from the database, the user is signed out
(21:52):
and you can't access to the system anymore and needs
to log back in again. So there are benefits and
downside of store. You know, your your session information in
a database.
Speaker 1 (22:03):
Sure, and if you have something like Blazer server you
can use or server based stuff. You can use a
protected browser storage, which I guess gives you what five
megabytes of encrypted data on the on the browser per
user per r L. Yeah. Yeah.
Speaker 3 (22:21):
The downside of of these storages in the browser is
that it is still the browser application that reaches into that.
And there's been quite a number of things that have
been tried to to do that. I mean storing things
inside of web workers to to keep them, keep them hidden,
you know, encrypted storage, all of that stuff. But ultimately,
(22:44):
if the browser based application can reach it, you know,
you're exposing that information also to potentially malicious actors.
Speaker 1 (22:52):
I remember one thing that Dom I think it was dumb,
it might have been Brock said, these are the one
day guys over and over again, is that you want
your authorization system to be totally separate from your authentication system. Yes,
you know want those two tied together. And in what
(23:12):
is the asp net core identity where you have just
these databases that do that hold both the authentication passwords,
hashes and also you know, claims, roles and that kind
of stuff. You're really kind of tying the two together.
And I didn't really understand what he meant by that,
(23:33):
but but I get it that that having it separate
just it doesn't tie them together.
Speaker 3 (23:42):
Yeah. I think the key thing to keep in mind
here is that what you get from your identity provider,
and maybe you layer a little bit on top of
that inside of your application, and you could do that
in the BFF as well. Should say something about the
user itself. Right, So I am irwin, I have you
(24:02):
know this role in the organization, right, But as soon
as you start to think about other things like I
have created this particular document, or I am a manager
of that particular department, and therefore I that is not
information that you want to store and managing your identity provider.
That's not part of your identity. That's much more part
(24:25):
of your application domain. And therefore those authorization decisions you
do not want to take purely based on information that's
stored in your cookie and sorting your access token, you
actually want to say no no, no, I am. I'm
defining what we call a policy, and that policy says,
am I allowed to do this given who I am?
(24:46):
And then inside of the code that executes that policy,
you can do lookups like are you the right manager
for this particular thing? Do you have access to that thing.
Speaker 1 (24:57):
If you're rolling your own Well, but I've seen many
customers and I do this myself, is that you have
you know, your your aspnet user's table in identity Core
ASPN Core Identity and then basically what we would do
is create a separate user's table that has all the
application specific data about that user, and then it's related
(25:20):
with a foreign key to that aspnet user in case
you know, so that that's how they're tied together, but
they're still in the same database.
Speaker 3 (25:28):
Yeah, and authorization can become really complex.
Speaker 1 (25:33):
Right.
Speaker 3 (25:33):
You can imagine inside of a big enterprise, one system
controls this particular aspect, that other system controls that particular aspect.
Now there are these systems, you know, policy server being
one of them as an example, right, that might actually say, okay,
you replicate some of the information that's part of your
domain into that server and then you know, since that
(25:56):
information is also stored in there. You can create association
is there. You can say, because this particular person has
this role, this relationship with that other thing, that's why
he's allowed to do these particular things, and those things
can inherit from each other. You can basically model your
authorization domain, but that is only if you have an
(26:18):
application landscape that is complex enough to warrant extracting that.
Speaker 1 (26:23):
Multiple applications from the same vendor. For example. Yeah, and
some customers have access to this application and that application,
but not that one.
Speaker 2 (26:32):
But I also look at it from a administrative versus
regular user role within an app or you can even
be more gradiated that HR can see some things that
sales can't see, Like you need to have someplace for
all of those different levels of authorization to live.
Speaker 3 (26:46):
Yeah, and you know, in an enterprise, what you typically
see is that, you know, especially if the enterprise has
built their own custom software for certain types of things,
that it really warrants you to store that that centrally.
Sometimes you literally have islands where each application stores its
own and has its own logic.
Speaker 1 (27:05):
Around right, yeah, right, you want to take a break,
or yeah, it's a good time. Oh well, yeah, okay,
we'll take a break. We'll be right back after these
very important messages. Stay tuned. Do you have a complex
dot net monolith you'd like to refactor to a micro
services architecture? The micro Service Extractor for dot Net tool
visualizes your app and helps progressively extract code into micro services.
(27:30):
Learn more at aws dot Amazon dot com, slash modernize
and we're back. It's dot NetRocks. I'm Carl Franklin. That's
my friend Richard Campbell. Hey, and that's our friend Erwin
van Dervach from Duende. We're talking about interestingly enough policy
(27:50):
server and why it's such a good idea to separate
authorization policies from authentication databases.
Speaker 3 (27:59):
Yeah, and of course you really have to think, you know,
how complex is your application and do you need to
externalize those decisions? And then you know, is it complex
enough that you need a product for that, because.
Speaker 2 (28:12):
There's an awful lot of cases where identity enough and
authorization are essentially identical. You identify with this so you
get all right, so this app. There is no granularization
of the rights within the app.
Speaker 1 (28:23):
Yeah, and if it's complex enough, you'll know, Yeah, absolutely,
you'll fit that point.
Speaker 2 (28:29):
It's one of those things where the moment I want
to granularize the rights within an app, I probably should
have a.
Speaker 1 (28:34):
Place for all that stuff to live.
Speaker 3 (28:35):
Yeah, coming back to the BFF pattern, right, one of
the things I mentioned is c surf protection. You know,
the challenge with issuing cookies is that cookies are sent
automatically when the browser makes a request to a particular domain.
And the challenge there could be is that if a
(28:58):
malicious actor lures you your users to a malicious site
and he then makes a call from that malicious site
to your application, you don't want, you know, authorized requests
to be sent. Now, browsers already have pretty good protection
baked in there, I mean, and also there's a process
for that, what we call cross origin resource sharing. You
(29:21):
can define policies around that course to define well is
this allowed or not. But unfortunately, there are a couple
of holes that are still allowed by the course you know,
that wouldn't trigger a course policy check, and that could
potentially be dangerous.
Speaker 1 (29:38):
Allow all for example, Well.
Speaker 3 (29:40):
That's if you have a course policy in the first place.
But what I'm talking about here is that there are
certain requests that the browser deemed safe and therefore won't
trigger a course check, and because of that, you know
you could be in trouble. Now, to be fair, dot
net already does a pretty good job of protecting you
(30:01):
against those because they those type of requests would be gets.
Now gets shouldn't manipulate states, so you shouldn't be able
to get into trouble with those. And they can be
simple posts, but as soon as you try to do
a post with a specific content type, that's when you
(30:21):
know the course policy would be would be triggered.
Speaker 1 (30:24):
For example.
Speaker 3 (30:25):
Now, some frameworks, you know, some server side frameworks, they
don't do a very good job of checking those content types.
But dot Net, by default, if you say, hey, you know,
I'm expecting a post that's just an adjacent document, you know,
it will not accept it if it's not adjacent post.
Speaker 1 (30:44):
Is it just raise an error?
Speaker 3 (30:45):
Yeah, it would just say hey, this is the wrong
content type, I go away.
Speaker 1 (30:48):
Yeah.
Speaker 3 (30:48):
Right, So fortunately dot net also helps you with that.
But again, right, security is about more layers. So there's
a very simple way of tackling this. Now, Microsoft provides
you with se SERF protection, right, so cross side request
forger reprotection, but it is based on encryption, and you
need to specify the data protection keys and all your servers,
(31:11):
and if you make a mistake there, you know it
doesn't work. But the very simple thing is just to
say in your BFF server to demand that a specific
header is there. And I'm saying specific header. It really
doesn't matter what the header is as long as it's
a custom header. So your front end just always sends
that header, no problem, right, It could be you know
(31:33):
x SE serf equals one, doesn't matter, right, Your front
end just always sends that. If the malicious site wants
to call your service, it doesn't have that header, so
it will that your your BFF will say I'm not
letting you in. If the malicious site then tries to
add that header, now you're adding a custom header to
(31:55):
the request and that triggers the course policies in a browser,
so it stops all the sea surf attacks dead. So
just by demanding in your server you must have a
custom header, and as long as you have an agreement
between your backhand and your front end, hey, send that header.
Speaker 1 (32:13):
You're safe.
Speaker 3 (32:15):
That's kind of cool.
Speaker 1 (32:16):
That's kind of cool.
Speaker 2 (32:17):
And can you read something in that header that's like
a security key or something not easily spoofed.
Speaker 3 (32:23):
You don't have to. That's the thing. I mean, this
confused me in the beginning quite a bit because I thought, well.
Speaker 1 (32:30):
Why headers or headers? They should be able to make
anything I want.
Speaker 3 (32:33):
Yeah, But the point is is that the browser standards
they dictate that if you do a cross origin call
and you do that with a specific header, that first
you must do a course policy check and then that
course policy comes into play. Now, if you screw up
your course policy, if you say course policy allow all, sure,
(32:56):
you're still vulnerable. But here's the point, right, if you
do it correctly, then you're secure. And by default, by
the way, if you don't specify a course policy, the
course policy is deny. So you're pretty secure if you
don't do anything there. There's a couple of other things
that you could look at. I mean, Blazer support is
an interesting one. I Mean, the thing with Blazer is
(33:18):
is that it's a really powerful framework, but because of
all of its rendering modes, you have to pay attention, right,
I mean, if you're doing purely service side rendering, then
you're just building a regular application. But if you start
mixing those interactivity modes, especially in the auto rendering mode.
(33:39):
Then some communication might go over web sockets, some communication
might be with web requests, and yeah, you just have
to you know, look at all, how are you going
to set the you know, as soon as you start
doing web requests, right, so regularates to be requests. Yeah,
(33:59):
you just have to make sure that you're calling it
with the right credentials. Now, inside of the do end,
the BFF framework, the one that I'm responsible for as well,
we try to make sure that that is all unified
so that you just have a single programming model that
you can code in your Blazer back end, in your
front end, and the auto rendering modes just work work seamlessly.
(34:21):
But if you don't use that framework, if you just
want to build your own then of course. And if
you do use Blazer, then that's one thing to watch
out for as well.
Speaker 2 (34:30):
And does the Blazer mode matter, like you have to
be in client mode for this to make sense or
do It'll work the same either way.
Speaker 3 (34:36):
Now, well, so here's the thing. Right with the auto
rendering mode. If you say I want to display a
list on the screen, there's three things that can happen.
One is it get rented on the server, and that's
actually what happens initially, right, it's rented on the server
and then send to the browsers HTML. So then you
need to have on the server. You need to be
(34:57):
able to get to that data. That might either be
just go directly to the database because you're in the
same space, or you're doing a call to an external service,
and therefore you need to make sure that there's an
access token on the ah top client to call that
external service. When you are in interactive mode, right, so
it's running on the in the it switches over to
(35:22):
web assembly mode. Then all of a sudden, it's the
browser that does that request, right, And you can't go
from the browser directly to that API in point because
first of all, it might just be in an internal network, right,
the browser doesn't have access directly to that API in
point right, And second of all, you don't have that
access token. You don't want that access token there, so
then you need to proxy that request using a reverse
(35:44):
proxy through the BFF, and then the BFF does that token,
the cookie exchange for the token, and then goes out
to that external service. So that's how that's supposed to
work together.
Speaker 2 (35:58):
Then as well, trying to figure out how much work
I actually have to do to implement this framework. It
sounds almost like a drop in thing and that should
be good to go.
Speaker 3 (36:05):
Yeah, I mean, if you want to build it yourself,
then of course you need to know what you're doing,
and you know, Microsoft provides a bunch of things, but.
Speaker 1 (36:14):
That's never stopping before or when.
Speaker 3 (36:15):
Come on, yeah, of course, but I mean you know
you need to You can use YARP, that's a really
good reverse proxy. I mean, you can use the Microsoft
libraries for that. We provide an open source library for
access token management, so that there's a bunch of things
that you can do, and if you know what you're doing,
then you can just do that. If you rather use
(36:36):
a product, then of course, you know, we provide a
product that you can also. You know, if you uh,
it is.
Speaker 1 (36:41):
A new GET package, right like this isn't it.
Speaker 3 (36:43):
It's just a new Get packaging. You plug it in
with a couple of lines of code, you have it working,
and you know, we have a community license as well,
so that if you uh, you know, I think it's
if you make less than a couple of million of years,
then you can just use the product for free. Right
if you make over that then you know, you pay
a little bit and then you get a nice product
(37:04):
for that.
Speaker 2 (37:05):
So yeah, no, and you said, drop in a couple
of configuration things. You're working and you've you're using this
whole TLS approach, like your life is better.
Speaker 3 (37:15):
Absolutely. Now there's one thing that we're also working on,
and it kind of bleeds into more operations, right because
if you have a purely browser based application, you can
just host that on a CD and and you know,
run that somewhere and now all of a sudden, you
do need a back end component for that. Now, if
(37:35):
you do that for your first application, you have a
really nice you know, you've got a nice back end
for your front end. It's all good. But typically, you know,
especially enterprises, they have a lot of applications and then
they come to the conclusions like I have a lot
of BFFs here, you know, can't we do anything about that? Right,
So one of the things that we're about to release
is multi front end support as well, So you can
(37:56):
have a single BFF that just you know, from the
perspective of the front end, it is just a single
back end for front end, but physically it's a single
host that can serve many of.
Speaker 2 (38:07):
Them, right, so you don't end up with one for
every app, which can get untenable. You have exactly collective
because they're all using the same right sets and so forth. Like,
this is all very shareable, and I suspet it's like
ninety five percent in common between apps and there's just
a few exceptions.
Speaker 3 (38:22):
Yeah, exactly. Now, now there's a couple of other things
that I mean, I've applied this pattern a lot of
times already in my career, and one of the things
that I'm finding is that it also helps my collaboration
with front end developers. I mean, I am primarily a
back end developer. I know enough about a front end
to being dangerous, but primarily a back end developer. But
(38:43):
when I'm working with front end developers, it's really nice
to have what I typically call then a dev server.
Nowadays you would build that with Aspire. You have something
that front end engineers can just run and it's just
just running there nicely, and they can iterate on building
their front ends. And as a back end engineer, I
mean I just spin up the front end and my
(39:03):
back end is there, and I can iterate on my
back end. And if you have a branch. Where you
have both of them, you can easily work together on
them with the front end. You compare program. Hey, I
build this in the front end, build this in the
back end, work together. It's just a really nice flow
to to collaborate together.
Speaker 2 (39:21):
So and then is the BFF security framework. It's again,
it's just a new GET package. So is it just
a line in Aspire to say include this and just
another part of the equation.
Speaker 3 (39:34):
Right now, it is just a new GET package that
you need to install inside of your web application. In
the near future, yes, it's going to be just a
container that you can just run and aspire and from
that point on you can use that as a development experience.
Speaker 1 (39:49):
Very cool. Yeah, I'd like it. I just like that
in my template.
Speaker 2 (39:51):
I'm thinking, I'm thinking very enterprising here about how do
I get my devs on the path to using these
tools from the outset?
Speaker 3 (39:58):
Yeah, yeah, absolutely, And that's exactly what we see people
do for this, and you know, and there's nice tricks
that you can do there with that, because one of
the things that you know, as a back end engineer,
I don't sometimes even have all the front end tools installed,
and there's like a gazillion of them. So what I
typically do then.
Speaker 1 (40:16):
Is again not an exaggeration, no, and gazillion.
Speaker 3 (40:20):
So when I just start up the back end, it
just loads the most recent front end from my dev
environment in the clouds. It gets it from a CDN
right right. But then if I start up both of them,
I can detect, hey, the front end code is running locally.
Let me just take the front end code locally and
serve that from there instead of them from the CDN server.
(40:42):
So that's a really nice experience. Then. You know, if
I don't care about the front end, I can just
start it up. If I do care about it, especially
when working together, you start them up both and they
just start working together. That's a really nice experience there
as well.
Speaker 2 (40:54):
For sure, What about the telemetry side, is there any
information coming out of this framework that helps me as
an on the administrator side knowing what privileges are being
gained and so forth.
Speaker 1 (41:06):
Is that still be part of the regular system.
Speaker 3 (41:08):
Yeah, that's the actual authentication bit. I mean, we track
how many tokens are being exchanged, and we do metrics
for those type of things. And of course if you
use service side sessions, you know exactly how many people
(41:28):
are online at any point in time, so you can
also do metrics for those, but actually publishing these metrics
as open telemetry is something that we haven't built in yet, right,
And there is a reason for that as well, is
that all of the traffic between your front end and
your APIs flows through the BFF, so it has to
(41:51):
reverse proxy those otherwise the cookie won't flow and therefore
the reverse proxy is very secured, very performance sensitive. I mean,
you don't want delays in there for reasons. So if
you were to add if we were to add code
in there that says every five minutes, look how many
users there are, look how many you know, and publish
(42:12):
those as statistics, right, we might, you know, negatively impact
your performance. So we don't want to do that obviously.
Speaker 2 (42:21):
Sure, I'm just thinking about additional telemetry you'd have access to,
just because you can see these tokens flowing around. But yeah,
and it's always a debate as to how much what
do you want, Like where is that?
Speaker 1 (42:32):
What is that useful for?
Speaker 3 (42:33):
Absolutely?
Speaker 2 (42:34):
Certainly when you're trying to do a call chain, knowing
what token was issued, when it was issued, when it expired,
like that's all part of that chain.
Speaker 3 (42:43):
Oh yeah, well, and access to cam management does alog
quite a lot of information.
Speaker 2 (42:49):
Yeah, that's the thing that's a lot of that's already
handled for you. Absolutely not your problem. You're just calling
into those services.
Speaker 3 (42:55):
Technically, it's my problem because I'm also the product owner
for access to com management.
Speaker 2 (42:59):
Well you're also the COGA provider. But that's not the
security framework's fault. No, exactly, exactly. Now I'll get that
telemetry for identity server. Yeah, but I mean, yeah, I'm
just thin get through all the issues.
Speaker 3 (43:10):
No, absolutely, absolutely so.
Speaker 1 (43:13):
Yeah, So is there anything that we missed, any gotchas
that people might run into, or any other issues around
this BFF pattern that people find tricky.
Speaker 3 (43:26):
Well, I mean there's a couple of ways that you
can host this really in production that might be interesting
to have a look at. So the absolute simplest way
of hosting this is to say, hey, it's just like
you know, you're bundling your back end code with your
front end code and publishing that as a single unit,
(43:47):
deploy that into the cloud or wherever you deploy it,
and then your back end just serves that, right. And
challenge with that is is that every time you want
to make a change to your front end, you have
to redeploy your back end as well, and that's just
very common. So what we typically see is that front
end engineers they bundle their software and they deploy that
to a CDN, and the back end is deployed, you know,
(44:10):
via a different channel, and they might even have different cadences.
It depends on how you structure your organization.
Speaker 2 (44:18):
You would hope like that's kind of a cool thing,
right in my perfect world, As a new version of
the client is coming up, the back end's already been deployed.
It's been running for a while, well just with some
dark features.
Speaker 3 (44:29):
Sure, I mean, but when you make a new version,
right you can You know, if you work, for example,
in a mono RepA where both your front end code
and your back end code is in the same repository,
you could have some logic in your bill pipeline that says,
if only a change happens in the back end code,
I will only deploy the back end if it change
only happens in the front end code.
Speaker 1 (44:50):
Yeah. That scares me.
Speaker 2 (44:51):
I think I want my back end and it container
my front and deployed a CD end.
Speaker 1 (44:54):
Yeah.
Speaker 3 (44:55):
Yeah, but you can still do that. But then you
can have different deployment pipelines for each of them. Now,
so what you then still have a choice, And the
choice is because your code is running in a CD
and your your BFF is running UH and a container
app somewhere, you still have the choice to say the
initial request and the domain name where you're going to
(45:17):
is that owned by the b f F or is
that owned by the front end. Now, the difference is
is that if it's owned by the front end, you're
going to to the CDN directly, so to speak, and
then you're getting the index ahe tmail there, and then
you want to do calls to the BFF that has
to be on the same what we call the same site.
(45:39):
It can be a subdomain, but a site unfortunately is
defined as top level domain minus one, so it also
can include subdomains there. So within subdom you can say,
I've got you know API dot my company dot com,
and I've got you know frontend dot A my company
dot com. And they can share cookies, they can send
(46:01):
cookies to each other if you can figure that correctly.
Speaker 1 (46:04):
If it was easy, we could buy it at seven eleven. Right.
That's why developers.
Speaker 3 (46:09):
The other option and that's the one that I personally prefer,
but you know that's just me. Is that you go
to your BFF. The BFF serves the index document, which
it gets from the CDN by the way, but it
can catch that. And then in the index document you
have all the links to your CDN and that can
be just in an other domain, it doesn't really matter.
(46:30):
That's just static content that gets loaded from your CDN.
And then you have also the option to inject some
script in your in your htmail page if you want to.
You have a little bit more flexibility in you know,
setting up some things and you don't have to you know,
the secured communication is always going onto the same same
(46:51):
domain name, so that's kind of nice. So that's my preference,
but you know, you can you can decide how you
want to deploy these these things.
Speaker 1 (46:57):
I'll stick with your preference. Thank you very much. The
tried and true. Right, what's next for you? What are
you what's coming up in your inbox?
Speaker 3 (47:07):
All right, Well, we're working on two big releases. Access
to com Management fee for is going to come out.
And you know access to com Management has been you know,
originally created by Dom and Brock and it's it's quite
you know, quite an old library. It's been it's been
around for quite a while and it's been of course
updated to the latest specifications. But now we're finding that
(47:29):
we you know, we want to update it a little
bit more to also the most modern coding standards. So
that's the thing that we're that we're working on. And
we're working on b f F FEE for which which
includes that multi funt ten support. So that's going to
come out fairly soon and it's also quite a big release.
Speaker 1 (47:45):
Well when did when did three come out?
Speaker 3 (47:47):
Actually? I think two months ago.
Speaker 1 (47:49):
So okay, so back in like February.
Speaker 3 (47:52):
Yeah, February March timeframe, I think.
Speaker 2 (47:55):
So yeah, okay, you guys are on a fast cadence
then if you're digging before.
Speaker 3 (48:00):
That's the advantage when you know d when they went
commercial obviously, right, I mean before it was just Dominic
and Brock working on this in the spare time that
they had between consultancy engagements. And now there is just
a fully flexed company with an amazing team. You know,
dom and Brock are still there.
Speaker 1 (48:17):
With a development team that can work full time and
they're going to keep.
Speaker 3 (48:20):
Coming alutely absolutely, and you know, we can just provide
better support, faster feature delivery, and you know, we've got
a great team working on it. So it's yeah, going
pretty well.
Speaker 2 (48:30):
And still with a community option if you're small, but
if you're making money off this stuff, contribute, Yeah.
Speaker 3 (48:35):
Yeah, absolutely, it's.
Speaker 1 (48:36):
A good model. Yeah. Or when it's been a delight
talking to you, thank you very.
Speaker 3 (48:40):
Much, Thank you so much. It was great to be
on the show.
Speaker 1 (48:43):
All right, and we'll see you next time.
Speaker 4 (48:45):
I will talk to you next time on dot net frocks.
Speaker 1 (49:08):
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com.
Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
(49:30):
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two thousand
and two. And make sure you check out our sponsors.
They keep us in business. Now go write some code,
see you next time.
Speaker 3 (49:45):
You got jam vanst the Bos
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Law & Order: Criminal Justice System - Season 1 & Season 2
Season Two Out Now! Law & Order: Criminal Justice System tells the real stories behind the landmark cases that have shaped how the most dangerous and influential criminals in America are prosecuted. In its second season, the series tackles the threat of terrorism in the United States. From the rise of extremist political groups in the 60s to domestic lone wolves in the modern day, we explore how organizations like the FBI and Joint Terrorism Take Force have evolved to fight back against a multitude of terrorist threats.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com