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 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? Now that's just about that time.
There's a lot of you know, for me, I'm organizing a dozen podcasters so right, and a bunch of different teams.
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.
We got a bunch of YouTubers well coming out this time, Tim Corey, who has been on the show not.
In a long time anyway.
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.
Yeah. Do you have any idea physically where we're going to be.
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.
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, Patrick Hines and Dwayne Laflatte. And if you don't know who these guys are, Patrick Hines was actually our first guests.
Well he's now our lucky charm, right, he's the first guest on all shows we make it seems that's right.
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 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 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 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 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 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.
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.
Awesome.
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, 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.
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 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.
Oh that that would be one.
There was that, yeah, yeah, okay.
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 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.
So did you say it was the diners Club.
That's what became Diner's Club, but at the time it was called Diner's Card.
The Diner's Card.
Interesting, and it was again focused on restaurants initially, although rapidly branched into retail.
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.
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.
Wow. That's cool. Silly but yeah, no, that was silly but cool.
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
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 about pretty much anything and everything tech, science, history, and all things metal, listening, playing guitar, and fighting with historically accurate long's words.
Well there's a hobby for you.
Yeah.
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 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.
I'm super excited to be on the show. A long time listener, so.
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?
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 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 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.
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.
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, 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. 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.
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.
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 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, 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.
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.
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 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.
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.
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.
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.
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.
I wish you were exaggerating that it was a million node files, because you're right, so it's so many.
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 put layers in there. Security is all about adding more layers and reducing the blast radius if something goes wrong.
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 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.
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.
It was a vulnerability in the micro code of Intel processors.
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
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, 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, 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 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 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, 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 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.
Got to keep the cookie monster away.
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, 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.
So you need some federated kind of multiple server communication going on.
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, there's more that you can add to that.
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.
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 token with the subject identifier in it and all kinds of claims in there as well.
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.
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, maybe all kinds of other claims that then the might also use to make coarse grained authorization decisions.
Sure, sure, okay, So.
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. 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 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.
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.
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, if the browser based application can reach it, you know, you're exposing that information also to potentially malicious actors.
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 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, but but I get it that that having it separate just it doesn't tie them together.
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 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
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? 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.
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 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.
Yeah, and authorization can become really complex.
Right.
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 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 application landscape that is complex enough to warrant extracting that.
Multiple applications from the same vendor. For example. Yeah, and some customers have access to this application and that application, but not that one.
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.
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.
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. 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 server and why it's such a good idea to separate authorization policies from authentication databases.
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.
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.
Yeah, and if it's complex enough, you'll know, Yeah, absolutely, you'll fit that point.
It's one of those things where the moment I want to granularize the rights within an app, I probably should have a.
Place for all that stuff to live.
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 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 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.
Allow all for example, Well.
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 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 know the course policy would be would be triggered.
For example.
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.
Is it just raise an error?
Yeah, it would just say hey, this is the wrong content type, I go away.
Yeah.
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, 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 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 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.
You're safe.
That's kind of cool.
That's kind of cool.
And can you read something in that header that's like a security key or something not easily spoofed.
You don't have to. That's the thing. I mean, this confused me in the beginning quite a bit because I thought, well.
Why headers or headers? They should be able to make anything I want.
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, 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 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. 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, 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. 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.
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.
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
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
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 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.
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.
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.
That's never stopping before or when.
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 a product, then of course, you know, we provide a product that you can also. You know, if you uh, it is.
A new GET package, right like this isn't it.
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 for that.
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.
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 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 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.
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.
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 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 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.
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.
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.
Very cool. Yeah, I'd like it. I just like that in my template.
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?
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.
Is again not an exaggeration, no, and gazillion.
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. 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.
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.
Is that still be part of the regular system.
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 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 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 those as statistics, right, we might, you know, negatively impact your performance. So we don't want to do that obviously.
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?
What is that useful for?
Absolutely?
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.
Oh yeah, well, and access to cam management does alog quite a lot of information.
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.
Technically, it's my problem because I'm also the product owner for access to com management.
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.
No, absolutely, absolutely so.
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.
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, 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, via a different channel, and they might even have different cadences. It depends on how you structure your organization.
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.
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.
Yeah. That scares me.
I think I want my back end and it container my front and deployed a CD end.
Yeah.
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 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. 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 cookies to each other if you can figure that correctly.
If it was easy, we could buy it at seven eleven. Right. That's why developers.
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. 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 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.
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?
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 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.
Well when did when did three come out?
Actually? I think two months ago.
So okay, so back in like February.
Yeah, February March timeframe, I think.
So yeah, okay, you guys are on a fast cadence then if you're digging before.
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.
With a development team that can work full time and they're going to keep.
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.
And still with a community option if you're small, but if you're making money off this stuff, contribute, Yeah.
Yeah, absolutely, it's.
A good model. Yeah. Or when it's been a delight talking to you, thank you very.
Much, Thank you so much. It was great to be on the show.
All right, and we'll see you next time.
I will talk to you next time on dot net frocks.
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, 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.
You got jam vanst the Bos