Hey, I'm Brian Fields, amateur radio call sign W9CR and I'm kind of excited to speak here at the Ham radio village This is the first time I've been invited to do so. I had quite a few different things. I'm involved in I do a lot with Motorola I do a lot with all-star link But one of the main things I've taken over here and really run with has been spectrum planning and repeater coordination Normally this is done through Kind of very unknown groups and in amateur radio and my hope is exposing what we're doing specifically in Florida, but the hope is it's more general and our methods our Technology can be used Hopefully by other states by other coordination bodies by other people that want to bring their coordination software or methodology out of the you know late 1950s 1940s kind of way that a lot of hams and a lot of coordination bodies have done things So that's why I'm really really thankful that the Ham radio village folks reached out to me and got this Topic and some initial slides got some feedback and hopefully this will be of interest to the general community here So What I have is calling it spectrum management and this is talk based on some of the other talks I've done here in Florida But my background here is Originally from the Midwest and I ran one of the first wireless ISPs in Northwest Indiana around 2000 time frame So that's kind of South Chicago area My background is in microwave and carrier IP network design I've always been doing carrier IP network since the day I got into Computers and networking as a business. I've never worked really in kind of that IT environment around 2005 I had the opportunity to come down here to Tampa and Took a little hiatus from ham radio at that time just to get settled and Got back into it really started trying to run some repeaters around here and we had a lot of stuff happening. So It was a lot of fun to kind of rediscover my hobby. I've really been licensed since 1995 Got licensed. I think when I was nine. So it's a big portion of my life and I can say a lot of stuff happened in my life because of ham radio and So I started what we call our Florida repeater Council Reform Caucus in 2017 2016 timeframe there was There's a lot of stuff going on. I'll touch on that in a little bit, but it's funny how Ham radio can happen like that. So My day job. I'm a senior consulting engineer with a major router vendor So we build a lot of the stuff that your large large ISPs use for routing IP packets and so forth I'm a board member of all Starlink incorporated and I'm one of the founding members of all Starlink Inc Was around right when that started unfortunately kind of the the main person there Jim Dixon he passed away at the end of 2016 and it was kind of instrumental in getting us going as a Incorporated nonprofit entity. I'm a former ampere net technical advisory committee member So anybody that's been involved in any of the 44 net IP space was kind of doing that until Some recent developments and I decided to step back from it. So hmm background into this and We're looking at, you know, what is coordination and then a technical basis for it because we can't just Do things the way we used to and Then some of the process that we actually use So things like How we coordinate repeaters what we were required from people and the idea is is maybe this will give other bodies that are looking at Doing this some idea of you know, we're asking for the minimum stuff What they need to be doing and how they need to be interacting and then some of the initiatives that we've been involved in so Let's do a little background on amateur radio repeaters I know we're probably really familiar with these but this is the the basics here of a ham radio repeater It's a line of sight communications It enables these hidden users to talk back and forth very well Different bands you can do 50 megahertz all the way up to 1.2 gigahertz Obviously the most popular thing for amateur radio is really 2 meters and 440 And The higher bands of course have more pairs available. I think 2 meters has 72 pairs UHF has considerably more than that all the way from 442 to 445 megahertz and That's a basic overview of it so One thing I want to talk about is where do we have FCC rules on this and typically VHF and UHF their local communications. So Where you would have band plans and things like that the FCC really doesn't set too much there Like they do for HF They've carved out a couple areas per 97 205 B of where you absolutely can't have repeaters in the handbands But other than that They're gonna get to this which is amateurs have to self-regulate The FCC does not recognize a frequency coordinate and they let that up to the amateurs in the area And the AWRLs really stayed out of it. They don't even publish the directory anymore The AWRL repeater directory is actually contracted out to a third party now the AWRL used to go to the Repeater consoles and they would give them you know a pretty sizable chunk of money on a really basis of hey Give us what repeaters you have and we'll publish them Now they stopped doing that when they contracted out to this other gentleman And he absolutely will not give any money to the repeater consoles unless they agree to keep What they do secret and not share it with anybody other than him Not publish it now I'm not gonna get into the legality of it, but generally, you know a list of repeaters a List of anything it's kind of like the phone book. It's not something you can really copyright so You can keep it secret, but Why secrecy in my opinion and I think in a lot of people's opinions breeds corruption so What do we need for coordination then and obviously amateurs do self-regulation, you know, we're a regional entity in this case Coordination body must be recognized by the users in its area not just repeater users General spectrum users too because we do set the band plan All we can do as Coordinators is suggest operational parameters that will minimize harmful interference and again, that's minimize and Harmful interference not all interference is harmful hearing somebody out in the distance When your local repeater isn't keyed up and you're running in character squelch is not necessarily harmful Because when your local repeater keys up, you'll hear your local repeater Looking at like the traditional process. It's kind of 1940s technology really around the birth of two-way radio And it doesn't make very good use of the spectrum because it's just based on distance and height And I say it's the ultimate in ham radio gatekeeping. It really is and Fasma is really striving to change that so All our repeaters are modeled and interference is predicted so As soon as you give us the information we have a model built for it and we're giving open access to all that data that we use So we're the successor to what was known as the Florida repeater console at Florida amateurs Spectrum Management Association and God I won't get into everything but the FRC suffered from some serious corruption issues The board wasn't acting in good faith. So, you know in a lot of things the members revolted We had tons of proxies signed. We had a meeting packed One of the directors went around and counted up everybody in the meeting and waited 40 minutes until we got up to talk and then called the police in on us because there was a Fire code issue with too many people in the room Then after that the board members decided well, they didn't like the idea that the actual members were Revolting against them. So they just decided to vote all the members out of the corporation. It's just Very very funny. So We ended up having a getting the old board out and elected an interim board back in July 2017 and the responsibilities of the Florida repeater console Were transferred to FASMA once it was 501c3. So That's one of the big things you want to do in your coordination body is go for that nonprofit status. There's a big benefit to it and We're committed to openness and records availability. Everything we have is online That's a big thing Our email system for example Manages all interactions so we can see a total history of communication. It's basically like a ticketing system if you're familiar with that And this is a big point is we're committed to treating all people with respect and fairness I can't stress that enough you you have to treat everybody in this that comes to you equally Um coordination has got to be done by a number of people We actually have a coordination committee that's impartial from the board And right now we have a couple people myself and someone else doing this And we have three other people that are just general spectrum monitors We have a few other people we call on from time to time, but that's the kind of core of it and what The coordination job is is all users not just repeater users but all users But we're going to focus mainly on fixed repeater stations because that is the majority of You know the issues that we we come into as repeaters can't very easily move around the band And we also maintain the band plan. There's a link to it right there for uh vhf and uhf in florida So when we start looking at this we start saying, okay Hey, the commercial guys have been doing this for years And they're doing it a lot more intelligently than we are so can we apply what they're doing to amateur radio? And I think the answer Is yes with a few caveats So let's look at the background here what they're doing and you know in part 90 radio commercial radio It's very important that licensees have reliable coverage Uh FCC does this they call station codes. So you have fb fb2. These are basic repeaters 32 kilometer radius and you might have co-channel users in there Now what they do is they start designating some things like trunking systems control channels for that fb6 or fb8 these are Central high coverage sites that have a large protected radius from interference Um The other one is mo mobile users This is important. These are assumed to be at two meters uh or six feet 1.83 meters off the ground And that's important remember that because that's the basis a lot of the modeling that we're going to do Um planning is based on normal everyday propagation in this And we don't take into account that you know, you're going to have Skip or you know troppo ducting or anything like that. That's that's enhanced. That's not something we can really model Uh day in day out And in amateur radio coordination, we don't have a business need. We're seeking to have really the most fun And the least amount of interference So in this case ham radio repeater is the same as a fb6 fb8 under part 90 Um one of the nice things though The fcc has is they have the benefit of assuming high quality radios are used meeting part 90 The not all amateur radio equipment is is as good as that so Um coordination really is based on these signal levels and we express these and this is an important thing to understand We express these as a decibel microvolt per meter.  And say they're a dipole you're going to have a difference or an amount of Voltage hitting that antenna that's going to give you Uh one microvolt per meter across that setup So that's an absolute value. It doesn't take into account anything with receive signal You know receive antenna gain or anything like that is at best, you know, the best thing we can put out There's a total absolute value and It's really great for doing coordination because you don't have to worry about your receiver You just know his height and you know that signal level is going to be there with the calibrated antenna You can back that out to what it should be and and so forth, but It really allows you to model it out so Here's kind of the problem though is this is what some hams amateurs uses a repeater We have all the way over here on the left We have the the wonderful two bowfang radios or chinese radios and a Little duplexer. I've seen this sold on ebay Then on the other side, we do have some of the stuff like the yezu fusion repeaters, which They've put out there very very cheaply And I mean they were I think charging $500 at one point for them. I know several clubs that bought multiple of these And same with the bridge com repeater. So these are Kind of what we call the two mobiles in a box. They're they're fine if you're out in the middle of nowhere on a 100-foot tower on a farm if you're putting it at a commercial site with 70 other carriers there and a trunk radio system or maybe up on a mountain in california or out west These just simply aren't going to cut it So What I say we should use and this is important here is You'll see some of this is these uh, whoops antenna setups And these antenna setups here for example aren't always going to be You know the the end all be all I'm just showing what works in in many cases Spend your money on your antenna system. You can always upgrade your repeater later on And especially if you're up on a tower it might cost you $2,000 to have somebody scale the tower and put up an antenna for you So you want to go with the best? antenna system that you can and in this case We have these two here and I have one Is a I think a uhf known as a db420 there on the the left and the right is a That's a tell wave product They make a very good antenna, but both those are commercial grade antennas and especially for florida I know I know this site personally both these have been hit directly by lightning multiple times and they keep working So Some of the repeaters that are out there, you know, this is a Motorola high-powered dmr repeater Tate makes some wonderful stuff And uh, I really like the tape product. It actually speaks s and mp. It's it's pretty cool. Um, these here are the Quantar repeaters. These are starting to come out on the market now. These are These are amazing and we're about a $15,000 base station brand new And now they're they're very affordable on this secondary market And then even these here on the bottom these are the um GE or They're the master three master four master five base stations are the current things that are out there from uh You know if you're on the ge side of it These are great and they're synthesized So Let's define interference. This is this is an important concept. We have to do is define interference for amateur radio and Harmful interference is what degrades in other spectrum users communications Not all interference is harmful and in amateur radio We're kind of used to working in the noise But this isn't really true of repeaters as I alluded to earlier ducting and trap oak and enhanced propagation We can't really avoid that So we have to define a normal service area for the repeater and this is all based on height erp antenna all comes into apply and So how we how do we define this for our quote-unquote fb8s? Uh, the FCC uses concept of service contours and then interference contours and you know professional engineering It costs some money to have somebody certify this for you Research into this been kind of ongoing empirically since the 1950s And we have some stuff up on our library there Good compilation of that EIA tia came out with something called tsp 88 and it kind of takes all this together Compiles it with a whole bunch of science behind it and it's a great reference so In our case here We have service contours and this is what's important is I think we pretty much all hams are familiar with what's called the fm capture effect and In a service contour you have a given signal strength that will override any interfering signal in that area if your planning is done right Using pl tones made this easier in 1970 Still to this day you have hams that think putting pl on a repeater makes it closed That's simply not the case. Every radio I've ever bought in my life has had pl in it. And as I said, I've been a ham since 1995 even before that so We're talking a good amount of time here for amateur radio transceivers to have these functions in them Now wideband fm when I say 16 k 0 f 3 that's what's called the emission designator, but that's wideband fm Meaning it's 16 kilohertz wide You need about six to nine db for this to work But the fcc never really took digital into account for this the tsb 88 standard did And a lot of this is based on tv modeling so as you can see here one of the things we put together was these pl tones And we have pl tones by region in the state, but again, this is just a suggestion There's certainly options people use different pl tones all the time We just try to ensure that they're different between co-channel and adjacent channel repeaters The important thing here is that all repeaters must receive and transmit a tone If you're not transmitting a tone if you're only using receive tone on your repeater your People that are out there mobile will be in carrier squelch and they'll hear everything else coming in When the band opens up or when the repeater is not keyed up so tsb 88 as I said is our major rethinking of this service contour kind of model for commercial radio And What they've done is modeled each mode that's out there so fm Tetra p25 nxdn whatever Model it and taking into account your signal band with the adjacent signals That are out there and then receive filters in the radios, you know, and realistically What the radio is able to discern and its selectivity So they came up with something what's called cpc or a channel performance criteria And this is a Way to define delivered audio quality based on for example in this case sign ad it's very similar to the Telephone system using what's called a mos or mean opinion score if you're familiar with that so This channel performance criteria says we're trying to give a delivered audio quality of 3.4, which is Pretty good quality speech 20 db sign ad You know, it's not 100 perfect, but everybody can hear it and you don't have to repeat so We model all the interferers based on that number which is that We want to have a good quality signal all the time and Adjacent users So this is something that's adjacent to the channel have to be considered as well Because in several cases the wideband user will actually overlap the Other channel just because of the way that we have Some of the 15 kilohertz channel set up in two meters so The first thing we have to do When you're doing tsb 88 planning again, this is the commercial way of doing it You define your service area that you want to cover and Then you go and you pick where you need to put your sites and what sites you can get and What your signal is going to be in that coverage area and you break the whole thing up into tiles you consider each tile and you Then run an analysis on it but Once you have that you identify a frequency and you model interference Per tile and you make certain that you're not going to interfere with somebody and somebody else isn't going to interfere with you So this is a whole heck of a lot more complex than an FCC contour But it does give us a lot more data It's great though. If you're doing, you know police radio system You want to know that that radio is going to work everywhere In the central business district or something like that and everywhere in the city Not just where you know, it's close to the repeater So let's take this and apply it to amateur standards and how we can do that so Amateur radio has this problem of you know, we're doing again repeaters You're going to receive one frequency and simultaneously retransmit on another that's a split It's going to be located up high again for florida. We're looking at a hundred to a thousand feet There's only a handful of repeaters, you know anywhere near that high in florida Obviously you get out west you can you can be up at six thousand feet without a problem on a lot of mountains Repeaters have excellent antennas. They have a high output power And the other problem though is they're not easily to move in frequency because they have to receive and transmit at the same time So you need high isolation between that that necessitates big filters And the other problem some older repeaters are going to have is going to be In crystals some of these need custom cut crystals for oscillators and things like that So it's very hard to change frequency later The need for coordination now We obviously need this because if you're going to have two repeaters in the same area Or a very close channel you are going to have interference And harmful interference at that So being it's hard to change frequency Let's say the coordinators typically only going to look at the output frequency The likelihood of two people being on the same input channel causing interference at the same time Being it's a you're only you know six feet off the ground in average if you're mobile or something like that It's fairly small And the signal is going to take up. What's the space on the channel known as bandwidth And it's not always necessarily the same. That's why I point that out there so We take this and we get into mission designator from it I won't go through all this but here's some of the typical codes What's nice about it is it gives the bandwidth for 99.5 percent of the mission And then you know f3 for example means it's fm. So Typical wideband fm is 16 k zero f3 e And Again channel size one of the things we're doing right now is Moving a lot of the digital stuff that's out there. They need only what's called a narrow band channel They don't need a full wide channel. They can make A half channel and be just happy there in a lot of cases So here's what we're using for standard splits and bandwidths in florida I won't go through everything because this is going to change you get out west and repeaters on uhf for example They're from what we would say with their upside down They transmit high and receive low instead of florida transmits low receives high and We are working to define this a little bit better the previous group didn't really have it worked out And The important thing though to understand is if you're going to use a wideband repeater or wideband mode It's going to occupy two narrow band channels. So you can't have Can't use either one of those if somebody's using wideband there And this is one of my favorite slides. This is uh What I'd say the legacy of bad decisions on two meters here Um Two meters has two main channel sizes below 146 megahertz. It's 20 kilohertz Above is 15 now. This is different in other states. Again. I'm just speaking to what florida does The offsets move back and forth Especially as you get above 146 megahertz Narrow band makes a 10 kilohertz channel from the 20 kilohertz which is usable for most digital modes And then your 15 kilohertz channels make seven and a half which isn't useful for almost anything other than nx dn and and maybe d star so The other problem we have with 15 kilohertz channels is you can see here. This is the Wideband fm being modulated It actually occupies much more space than 15 kilohertz um and The advantage to this is well, we can pack things much closer and because it's wideband fm. It's not always going to be That wide it's going to be uh spaced On average, maybe it's only going to occupy 10 kilohertz, but when somebody's voice peaks or whatever It's going to go into the adjacent channel This is the way it's been done. This is the way it's done even on some of the commercial spectrum So what happens when we put all this together? Well, as you can see here, we have everything Overlapped with three other ones being modulated fully and the channels there are in green So analog is never very rarely at 100 modulation digital though is always at 100 modulation. So We obviously can't do this with a digital signal, but in the analog signal We can do because it's not always going to be that wide So this is what's known as adjacent channel power ratio or acpr and As I said, this is a worst-case scenario. So What we do is we determine our ratio needed here between The peak power of a channel and the amount if it's at peak power. What's that mean for the adjacent channel? And in this case you can see we have here's our peak And then you see in red where our adjacent is and we look at the delta between that in This case it's a 31.7 db off. So If this thing is receiving with a Very strong signal that means in the adjacent channel, it's going to be down You know, what would that be 10,000 times almost 30, you know 30 db The cool thing is tsb 88 actually provides this information to us for every known modulation. Well except for d star So Let's put all this together and this is going to get in a little bit of math Uh, I won't go into everything, but we want to have a service area. So that's 20 db sign ad delivered audio quality of 3.4 So for fm, this means we need to be at least 6 db over the interference And we need say a negative 110 db in input signal on a half wave antenna. We figure all that out to get back to Okay, that's a dbm Into a receiver and that's you know, decibel micro Micro watts. What's that in Microvolts across a meter and this is how we get back to it It's 8.33 dbu in this case So we have 16 db for noise and variance in amateur radio that gets us up to 24 dbu And reliability. This is where we go from 50 to 90 percent. That's 12 db at vhf 14 at uhf So we add all that together that gets us 36.33 dbu The value used by the FCC is 37 for vhf which Aligns really closely with this. I was actually surprised when the math came out that good Excuse me, so This is the other thing then and we have 18 db between our intended signal and any co-channel interference So this means that any co-channel signals are going to be In our service area for our repeater 19 db you are less that gives us 18 db Absolutely worst case scenario most of the time it's going to be a lot less than that Or a lot greater than that The signals are no we're going to be that strong inside that service area Um, we take into adjacent channel power ratio for fm. It's going to be an extra 5 db Meaning at the overlap area the adjacent channel must be 42 dbu But that's going to be on the adjacent frequency so it doesn't overlap Into our area so Our coordination basics here and We're going to find the best pair for a repeater in a given area Sometimes there's no pairs open We use rf signal software to predict a lot of this this gives us our service contour And gives us that interference contour with all the mathematics that I just discussed So The important thing there is we're predicting for what's called a 50 50 or 50 of the time at 50 percent of the locations in an area um, that's That's for the service contour Interference contour is going to be at a lower value of 50 slash 10 Or 50 percent of the time 10 percent of the locations And optionally you're going to have that adjacent channel as well That's really only an issue in two meters for us Again in some areas you don't even have that issue because the band plan makes a lot more sense So we're going to assume that We have a Small amount of interference. We don't want to have harmful interference And we want to make certain that that interference contour from somebody that's Co-channel doesn't overlap our new repeaters service contour and vice versa that way we can prevent A strong signal co-channel in the same area that our repeater is So That's why we're using ctcs dcs. It's a really important thing. That's I can't stress that enough. That's that's so important in modern FM radio and You know digital has less of an issue that because you have color codes and so forth So Let's try to visualize a service contour here. I got two Service contours here. This is in dark red. Say this is a 37 dbu area Our light red and our light green that comes here is our 19 dbu interference contour And what we're going to do is make certain that that Green service contour or light green interference Contour doesn't overlap our service contour of dark red It does a little bit here. Uh, but for amateur radio, this would be acceptable It's it's only going to be on the very very edge there. This would work Um, obviously though probably wouldn't work too well for the green System, but you know that's that's the issue Uh blue here and you can see that's much smaller because it is a stronger signal But again, that's 15 kilohertz away So it's going to be Have to be a stronger signal When it's actually you look at what's on frequency And users in the red area here, you know, if they're in carrier squelch If they're in that that dark red area and they're running carrier squelch They would hear that green repeater out there in the distance possibly however once they're They're repeater that they're on that has that dark red service area keys up It's going to capture Their receiver and they're not going to hear anything out there. So that's why if they are running pld code They won't hear anything. They won't hear that and it's not harmful interference It's interference, but it's not harmful Um, here's our standards we use for Our we call our contour levels across the different frequency bands I won't go into all these they They do get a little stronger as you go up higher in frequency um, so the the service contours get a little bit smaller and What we're actually doing for modeling this we're using free software Um, so anybody can take a look at it. Everything we're doing is based on what's called this, uh, a regular terrain model or, um Longly writes and there's a Wikipedia article on it I won't go into it too much, but You take all this stuff into account and it gives you a percentage or confidence in each area Some of the stuff that's out there is a splat which is free software for unix It's open source too. I mean when I say free software, it's free as in, you know gnu gpl Signal servers the same thing. It's based on splat. It's actually what we use um, however It is multi-threaded. So we're able to model stuff a lot faster Uh, especially when we're doing it on a central server So fast ma has models built automatically for every coordinated repeater And all these are based on this srtm data shuttle ranging terrain mapping program It's a digital elevation model. So it shows you you know, if you have mountains if you have Uh, a ridge in the center of the state lake we do in florida Again florida is pretty flat, but we still take that into account The nice thing is it takes into account the fact that it's basically the top of the trees Um, you have high quality data, but we're actually using the three arc second data, which is about 90 meters Our terrain doesn't change that much Again, if you were doing this in another state and somewhere in the mountains You might have to use the higher quality data the one arc second data that's going to have more resolution Uh, north florida, I have a link in here to that has some issues with gaps in the srtm data Which was kind of fun to figure that out and and work around that So here's a modeling example here and You can see this is a 224 280 and this is as it pops up. So all this gets output It goes right into the you know cams e file. You can load it in google earth Um, and this has our blue 37 dbu service contour in the center And then the 19 dbu interference contour around it and you can see obviously interference contour is a lot larger But that blue area is going to be your your area that you're going to have reliable service in to mobiles and handhelds and things like that So let's look at a couple other coordination examples here what we're doing Um, this is this is one here. This is uh, about 700 watts erp Shows the service contour and red in this case interference contour is in yellow Um, there's no adjacent channel taken to account because it's a it's a 20 kilohertz bandwidth here And we could actually look at this and say hey, you know what a smaller coverage area repeater and maybe paul beach Co-channel would work on this frequency Um, same thing here. Here's a coordination example for two co-channel repeaters one on one coast one on the other And these are actually an operation right now here in florida and kind of what's needed. You can kind of see down the middle of the The state there is what's called the mid florida ridge. It's this I'd say it's a mountain, but it's it's the tallest area in florida. I think we even get up to maybe almost 150 feet above sea level But it does show that You know the rf is stopping there and not propagating around that because it is taking into account The elevation model when it measures this or models this I should say um So in this case, you know say there's very little chance of interference Both these repeaters users there's a good possibility when the band opens they're going to hear each other carrier squelch, but That's not so much an issue because Day to day it works perfectly Um, here's another one we did this is this is an example of showing something that obviously would not work In this case there was a very high level user. They had a almost a thousand foot broadcast tower They were on they wanted to find a two meter frequency And both these sites that we looked at we said hey, let's do it here. Well, this work And obviously the the repeater there in in tampa in blue You can see where it's overlapped multiple times by the the green interference contour from the proposed repeater there over in orlando And obviously didn't work. We had to go find them a different channel, but uh You know, we're able to prevent that because if you just looked at this based on the old way of doing it, which is Distance and height between sites This would qualify this would work But when you look at the actual model you say oh, it's no way this is going to work or We're going to tick all these people off over there in tampa So let's focus on what a coordinator can do and what they can't do Because we're not the FCC Coordinators should be happy to moderate harmful interference between coordinated repeaters So obviously you can do that if you're coordinated It means you're agreeing to that like let's work together and obviously somebody has to give There has to be a little back and forth there We can't really do anything without uncoordinated users And you know if you ask nicely see if they can coordinate Maybe they'll resolve it It's on the trustee to really go to the FCC FCC says an uncoordinated user causing a coordinated user interference It's you know, it's the duty of the uncoordinated user to fix their stuff All we can do is really provide the coordinated trustee proof that they need to go You know to the FCC we we can't really get involved and It's best to never try and play, you know king Solomon here between two people So As I say the bottom line here, we only recommend parameters for station operation Coordination can't function if there's no cooperation between amateurs That's like we all have to get along and I don't know what it is about amateur radio There's a lot of people I've been on that frequency for 50 years or you know Maybe they haven't been coordinated there, but well, they've been there or they're on we had one case Somebody had a repeater in a different state on the same frequency and Put up a repeater here in florida without coordinating it. So well, that's my frequency like across the entire united states. That's Okay And then on the other hand we've had a lot of people that just really want to work with us and you know, that's cool, too I really like that So How do you structure a coordination body for for success? Um and that's one of the things I've thought about because we had a really poor coordination body previously here in florida and How do we prevent the the problems from before from happening again? And that's why I say structure your your body your coordination organization for success and as I say, there's Many options, but you're fundamentally different than an amateur radio club. You're not just a Not just a ham club. You're providing a service To a lot of people with a lot of different goals So One of the things we did is we committed to openness day one We're had an organization that was very secretive previously I said the way to solve that is just put sunlight on it So we have the listings open on the web We have documentation for the organization stuff on the web And you know possibly provisions for membership if that's a thing that you know your group wants to do Structure your board of directors, you know have some written job descriptions have some expectations from board members Having the introduction where you go through your state laws for operating a nonprofit a lot of people aren't familiar with that There's things you can do in a regular, you know for-profit entity or a You know a church organization or something that you obviously can't do in a actual non-for-profit And then also ensure there's something in there to prevent The board when they if you get the wrong people on there and they go nuts because when these things are working Most people don't give them too much thought And sometimes you get a lot of people that are on there that maybe don't have the best Goals of the organization You know in in their mind So think about that. I don't have any Good answers to how to fix that, you know, that's that's a fundamental problem of government anywhere really The important thing though is your coordination standards and technical advisors should really be independent from your board Your board runs the organization, but they can't just go in and tell the coordination team Go coordinate this repeater right now because we're the board and we told you or something like that you want to prevent that So Our coordination committee these are people doing the real heavy lifting So they go back and forth with coordination. So somebody submits something. We take a look at it Is it filled out right so on and so forth? They do everything via email. I try to really limit phone calls here We use a ticketing system called rt You can use anything you want probably want to use something that's open standards Rt is kind of really the best thing out there that's open source right now And Ensured that they're doing email from their non-personal addresses. I get a lot of the coordinators from Other states where we have to do, you know cross border coordination to Alabama or in Georgia, Mississippi area With florida they're emailing us from personal addresses. I that's you know, that's their their business. They can do that But I think that's really bad for an organization to have their people do that so We have people that have different skill sets a lot of people can't do the coordination side or they don't want to get into it It's pretty complicated. We have spectra monitors. So they just get a sign to go verify something make certain It's there. Uh, this is the problem. We I think all coordinators have we call them paper repeaters people It just like to have their name in the book But not actually put anything up and that's a real problem in any place because once somebody's coordinated It can take You know easy Three to six months to decoordinate them Uh, because you just you know, even if there's nothing ever put up You have to go through the process. You can't just you know remove them with how they do process um And you know, some people are better at doing calls. Some people are better at speaking Uh, some people are better at doing outreach. So figure out who's going to work best. Where? And this is the important thing though no one to say thanks for the offer of help but You know, no, thanks. Uh, there are Some people that you know go around I call them the sash collectors They get on the board of everything and they don't really do anything So watch out for that, but that's that's not just applicable to a coordination body That's a lot of things that this this can mean uh and can be applied to So let's look at really our process here in the last 10 minutes or so of this Uh what we go through and what we look for people when they coordinate with fastman the idea being Maybe you can look at this and get some ideas from it if you're going to improve your coordination body Or yeah, maybe you're in florida and want to get a repeater coordinated. That's fine too So Prepare you know have your site have your permission in order We get people all the time they hey, we're going to go put something up here They don't have a lease they don't have any of that stuff together And they want a frequency for something they're never going to be able to get on The day of getting onto a big tower or onto a building now with a handshake and no insurance and no verification that's uh You haven't been able to do that since you know the Probably the the early to mid 1990s. Everybody is very concerned about Insurance liability Um, I know there's a lot of people that are just able to get up there with the handshake Really can't do that anymore. So make certain you have that in order We have an application form. That's a pdf I would like to have an online form But I'm probably not the greatest php coder. I'm certainly not the greatest coder in any means so Something through email is a lot less to go wrong with that than putting something that's going to interface with the database up there Um, we go into our ticketing system via email And then any questions we have we'll go back out answer them and you know when it's approved it online you let us know so Important thing when you're doing a repeater and this is people that are putting a repeater up is you know Make certain you have your funding because None of this stuff is cheap and especially antennas.  It's 20 kilohertz 15 and again, this is going to vary state to state But you want to come correct because the less work that your coordinator has to do for you The more chance you're going to have of getting coordinated Especially if you're looking for only a you know narrow band channel If you're doing digital you don't need a wide band channel So fill out the information there We actually put a very good website together has goes through everything step by step Read the documentation. It's there. It's meant to be read If there's something you don't understand you can always reach out to us This here is a great example of a coordination form that was put together as you can see we have a very simple form as a bare minimum of questions and You know in this case Everything was correct and it was a 900 megahertz repeater So that's almost a pes dispenser when it comes to getting coordinated There's not a lot of 900 activity at least in florida In this case guy went through said hey here. I'm doing a new repeater. The subject was good little introduction attached it And you'll get an email back from us saying it's been received This is this is a standard thing anybody's worked with a ticking system Anybody that has worked with the ticking system is going to know this As you can see it comes back from us. It's got the auto reply Thank you for coordinating it And then we'll process it back and forth now one of the important things in this is Keep the subject line intact or at least keep that coordination number whatever in there So that we can keep that correspondence together and we have the entire history of your ticket that we can go look at Reply I'll typically do that And and you know make it very easy on you So in this case we say hey, please respond to any inquiries promptly. I think The person that was coordinating this Requesting this they went out of town a little bit and we followed up a few times and said hey, what's you know? What's going on haven't heard back from you and Finally, uh got a response back. Okay. You know, here's what we're looking for. We're good to go And you know in this case You see we put it on the website It came out very easily here. Here's a new repeater Please let us know when it's an operation after 60 days or before that, you know, as soon as it's on the air Makes it very very easy to do again 900 is is practically A pes dispenser when it comes to getting coordinated at least here in florida. There's not a lot of activity I think I have a repeater on 900 and there's quite a few in south florida But majority state does not have a lot of 900 activity. There is a lot of noise on 900 too. So that doesn't help things And please let us know when it's online in this case We got this back saying hey We granted the coordination you can see we put a reminder And this is a good thing most ticketing systems will support having a reminder We have that in the system And we just followed up said hey is it online last time we heard from you you were coordinated and Working to get the thing online and we did get a reply back from him and yeah, we're good to go Um, and again, though, this is trusting the trustees and the people involved to to tell the truth That's just like dealing with the FCC or anybody.  It's You know, we're not going to go out there and verify 100 that this is online or that's online So this is the other part of the thing is what happens and and why do people get rejected or So on and so forth and and how do you deal with that? I think this is important that coordination bodies, you know address this because A lot of stuff is going to get maybe rejected if that's the first time they're doing it or You know, not everybody's familiar with this as there's, you know, a lot of complexity to the process So About the only thing we reject right off the bat is just incomplete applications Uh handwritten or scans of the form. I I can't I think we make it pretty easy, but uh, I've had people Fill out the entire form on their computer Take a picture with vertical video of their, you know, vertical picture with their phone And then email that with all the moray effect and everything of their lcd monitor and it's just It's interesting to see how badly people can screw things up when you're like, well, this should be really easy So that's another thing to learn to and and I anybody that's on software development will realize that And that's probably again why I don't have an online form for it because the amount of Filtering I'd have to do on that would be Be considerable Um ones we suspect to be fraudulent. There are fraudulent forms that are out there Again, a lot of people like to get their name in the book get their hey, I have a repeater coordination I don't have any repeaters on it, but I have repeater coordinations um and We'll just kick that out because It's pretty obvious when somebody's trying to do something and and that's kind of discretion the coordinator has Um, and I say even if you're rude, we'll try to help you. Um There's a lot that can be lost going through email Um and things can be taken the wrong way And especially when there is sometimes the language barrier involved At least here in florida. We have a Lot of people across the state that may not have english, you know as their first language So when that happens we kick it back. It's easy. Just correct it and resubmit it And we want to continue to work with people and I think every coordination body should want to work with its You know people that are wanting to coordinate repeaters Uh because the alternative is they just ignore it and then you have bigger problems to deal with So in this case, here's an example of stuff that we'd reject because Everything was filled out and prompt, you know, it was just missing and this particular individual Went and coordinated like four or five different repeaters at the same time I think some of these were re-coordinations and there's no information in there.  And they were all like this. So if it's your first time doing it just submit one and see What is uh The problem, uh, if any with that first form and then you can learn how to do it rather than making four or five The same mistake time and time again Um, oh, yeah, this this is this was pretty bad. Let me Okay, so we can see the entire thing full here This was like somebody hand wrote it on there rather than I mean, it's a fillable out pdf kind of a thing You know, generally most people don't even have to print it out or anything um so I couldn't read any of this. It was horrible writing. I just was like you've got to be kidding me. So Uh, this this will get rejected outright just because there's too much ambiguity to it and it makes us They have to work too hard to scratch our head to what to know what they want to do Uh, in this case, this is one we suspected to be fraudulent. Um, all these came in within the same general time period and they were all exactly within minutes of each other and They were all for different frequencies for different, you know areas and Everything was identical about them. They were using quarter inch super flex 100 feet of that on every single site Different buildings. They were on across the entire county And they were all identical. I'm like that's just that's not the way this stuff works And you know went back to them. They were evasive That's what you can do. So We actually put about three hours of work into this and Figured out that it was kind of BS because I mean when you're asking somebody to do a coordination It's going to take the coordinator You know minimum 30 minutes to an hour Even if everything's in perfect order more than if they have to go back and forth There's another good reason to use a ticketing system for coordinators And as I say, even if you're rude, we'll try to help Uh, I said to this person like this is the fifth time you've submitted this form wrong You know, can we help you out and you know, he got It wasn't my intention to be rude to him in any way. I just said, you know, whatever and he took it the wrong way And I'm like look, I didn't intend it that way. I just wanted to apologize to you. Let's let's work You know and go forward here This stuff happens sometimes when you go through email so One of the other things that a good coordination body should do is have a way for people to do initiatives Uh, or affect policy or change stuff. Maybe they're not on the board Maybe they're not even on the coordination committee, but they have an idea You gotta ask people what their ideas are and not just shoot them down And this is very common in amateur radio is, you know, the the person proposing something Well, that's an idiotic thing. Why do you want to deal with that? So you have to be accepting of that and we have a way so people can come in there and Propose something and and we've had some good stuff come out of this and two of these One of them that's actually policy right now. Another one. We're just studying The first one here is what we call our a tenorant or a backyard repeater policy And as you can see this is a For a lot of people only want to put a hot spot up or a small repeater You know two mobiles back to back at their house on their tower at 50 feet and Walk around the street with their handheld This is great. People want to do this, you know, here's our requirements for it. It's going to be on 70 centimeters low transmit power No crazy high gain antennas No higher than 50 feet. You got to run pld pl whatever Um, and you don't even have to coordinate it. You can let us know and we'll put it in the book That's fine or you know put it in our records But you're not protected from interference anybody else can come along at some time and set something up and You know, you might have to change frequency. The nice thing is we put everything together so that the um Frequencies are all very close to each other. So most typical flat pack duplexes. You're able to do a You know, maybe tune it in the center and you'll get a couple hundred kilohertz on either side And that's enough if you need to change frequencies without having Really any appreciable effect on it. We have some narrow band. We have some wide band channels here This has been just a huge success in florida So next thing we're looking at then I got to say this is a preliminary study So two meters has had this real history of like just stupid repeater issues um It was the first band that repeaters ever came to back in the 1950s 1960s right after we got the band We never had two meters before I think 1946 or something 1947 We used to actually be in the am aircraft band right now down on 114 megahertz was our two and a half meter band so 146 to 148 in florida is 15 kilohertz for wide band channels seven and a half for narrow Narrow is not too useful for anything as I've alluded to and These first repeaters were only allowed 146 to 148. You had to have a tape recorder on it You had an FCC application for the repeater. It was crazy um And originally we were doing spacing based on 60 kilohertz Then we went down to 30 and 15 and that's how we're getting to seven and a half Because we were using wide band real wide band fm 15 kilohertz deviation Um, and it was the frequency standing, you know stability wasn't good You could if you were in part 90 at the time with the FCC you could be plus or minus seven kilohertz and you'd still be compliant with part 90 in the in the 1950s is pretty funny so Hams are limited by the equipment of the day If you had a mobile in your car, you're looking at something, you know In even in the 1970s you had a motor or a mic or that was 1500 dollars And maybe you had a You know three or four different channels you could put in it or you had the expanded eight channel pack All those channels had to be within About 500 kilohertz of each other So you picked either 146 or 147 megahertz picked a couple channels that you wanted to be on and that was it So In 1970 these application requirements was dropped and a lot more spectrum opened up for repeater use And it really took off so the thing we've been studying though is trying to get a couple more repeater pairs out of this perhaps for some itinerant and Portable type repeater stuff to designate a few of those for that using 1.005 megahertz offset um and the reason for this If you look our different simplex frequencies that we have in florida line up very nicely with this um Pretty much every radio that's out there can be programmed for you know odd splits and everything Very very few radios still only have a fixed 600 kilohertz split We'd of course exclude 146.52 And you know not all these would be permitted. They're going to be in certain areas So it's something we're just studying right now We're always looking for comments looking for feedback on it and it's still in that research phase So that's the end of it. I want to thank you for Allowing me to talk to you for the past hour. Hopefully it hasn't been Just useless I know this can get pretty dry It's something that I think is is interesting to see because we're at the The interaction between a lot of amateurs a lot of people getting into it A lot of people wanting to put up a repeater and I want to encourage that and I think all Coordination bodies should really want to encourage that and work for not just their members but for the the community in general And how to structure yourself to be able to do that is so very important So I also want to thank the uh Ham radio village people at defcon for inviting me to talk and allowing me to give this Maybe next year I'll have something else that I'm involved in I can give a Give an update. Um, maybe that'll actually be in person with all this covid stuff that's happening. So Again, uh, thank you very much again, brian fields brian at fastma.org if you have any questions And uh, thank you very much to uh, our defcon and ham radio village, uh, coordinators here


Okay, today we'll take a deep dive into the complexity surrounding identity propagation and API security in microservices environment. We'll explore our current workarounds and their issues. Then we'll see how a novel relatively unknown and under implemented extension of OS2 might help us to solve our problems. At the end, we'll also demo the solution. So my name is Armit. And I'm Yara. And we're both from Tyre, an open source API gateway management platform. I've been here for coming on seven years now, starting as a consulting engineer for our prospects and customers, and then moved into product leadership. And now my focus is on R&D, where my team and I are looking a little further ahead strategically to help shape the future of our product offering. I was a C++ developer most of my career, but I needed a change and decided to cross the lines and work with the users directly. I joined Tyre three weeks before Armit. And also as a consulting engineer. Later on, I moved into product leadership as well. As a head of developer experience, we're focusing on creating SDK, CLIs, and other dev tools to enhance our users' experience. Okay, let's get started. When I visit an online store and wish to place an order, as far as I'm concerned, I'm just placing an order via some web app. I'm completely oblivious to the different chains of offends and communication between services or different providers that are involved in order to fulfill my transaction. If we zoom in a little bit, this slide shows what the world looks like from the perspective of a service, which is responsible for processing an order. A service, such as a micro-service, can use and consume many other services. Some internal ones, like inventory, pricing, and user account. And other third-party APIs, such as fraud checker, shipping, CRM, and payments. Some services, sorry, but there are other services that might benefit, sorry, I'm a bit nervous. Some services, such as shipping services, are happy to just accept a simple API key in order to integrate with that service. They don't need to know anything about the user, apart from perhaps the delivery postcode. But other services might benefit from knowing who the user is. Perhaps this would include a CRM or a fraud checker. Some services, such as shipping, need the user's address to book a delivery or make a payment, while others, third parties, like a fraud checker, that are on less trusted domain would need to be downgraded to read only access rights. We can see that the micro-service environment is complicated and convoluted with diverse security and user's needs. Let's dig in a little deeper into this. So identity propagation refers to the process of maintaining consistent user identity across various systems, services, or components within a software application or a networked environment. In distributed systems or micro-service architectures where different, sorry, consistent user identities across various systems, services, or components within a software application or a networked environment. In distributed systems or micro- service architectures where different services might be responsible for handling different various parts of a user's interaction. It's crucial to ensure that the user's identity is accurately propagated throughout the system, and this allows each service to properly authenticate and authorize the user without repeatedly prompting for credentials. Identity propagation typically involves mechanisms such as auth tokens, where users are authenticated by some central authority, which issues tokens like a JSON web token or an OAuth token representing their identity, and then these tokens are typically passed between different services to prove that user's identity. We also have single sign-on systems, which enable users to log in once and access multiple related systems without having to re-authenticate. The user's identity is propagated seamlessly across the various services indicated with that single sign-on solution. Then finally, sessions are established upon user authentication, and a session identifier is used to maintain that user's identity as they interact with the different parts of the system. So session management ensures that the user's identity remains consistent within that same session. Now, middleware components like API gateways and service mesh data planes, they intercepts, requests, and add identity-related information before forwarding them to upstream services, and this ensures that each service has access to the user's identity without explicitly passing it in every request. So, along with identity, there's conceptual information related to the user's session or request, like roles, permissions, preferences, etc. They may also need to be propagated across the system to ensure consistent behavior and proper authorization decisions. Identity propagation is essential for maintaining security, providing a seamless user experience and enabling effective authorization and access control mechanisms in distributed systems. So, how do we go about propagating identity across our systems? We've gone back. Yeah, next. Oh. Back. Okay. Okay. Now, in this slide, we'll discuss and title workarounds and hacks. Many of these approaches could actually be okay, depending on the situation and use case, but there are a few approaches which we have seen out in the wild. First one is user ID token as access token. Amit, what's wrong with that? So, we've all seen many tutorials and implementations on the Internet which have recommended this approach. This approach is probably one of the simplest to implement, because once the user has authenticated and a client has obtained an ID token, then they're able to use that token in order to access the protected resource. But there are several reasons why it's not best practice to use an ID token in this way. Like, the first one is the purpose. ID tokens and access tokens serve different purposes in the OpenID Connect and OAuth 2 protocols. ID tokens are intended to provide information about the authenticated user, while access tokens are used to protect, are used to access protected resources on behalf of the user. So, mixing their purposes can lead to confusion and potential security vulnerabilities. Access tokens also, they typically have a shorter lifespan than ID tokens, and they may have different security requirements. For example, access tokens, they might need to be refreshed. They might need to be revoked in the case of the user logging out, or maybe a security incident, or have specific scopes and permissions associated with them. Access tokens are used to authorize access to specific resources or APIs based on the scopes granted during the authentication process. And ID tokens don't provide the same level of authorization information that are primarily focused on authentication. Using ID tokens as access tokens could result in improper authorization decisions. Okay, so now I'm convinced we will use access tokens in order to, in order to, for client to access protected resources. But why can't we just embed all the, all the, all the required identity claims into an access token and share that, and share that same access token between all the microservices? So the JWT specification specifies AZP and AUD claims, which enable us to control and understand who the authorized party is and who the intended recipients are. Sharing access tokens is like sharing your password with everybody you talk to and then trusting that the recipients will be good citizens. From the recipient's perspective, the access token is private to that intended recipient or audience. And as a recipient, you should be checking that the token was in fact intended for you. Because if it's not, then that token shouldn't be authorized to access the protected resources that you're serving. So by sharing access tokens, even between trusted services, you could be granting overly permissive rights. In our e-commerce store, should a random service like, I don't know, let's say a product inventory service be able to access or even perhaps modify user resource, should it be pay, capable of initiating payments? Okay, so we won't share the same access token with other microservices like a hot potato. Fine. So if every microservice has the ability to authorize itself, then what's wrong with propagating identity and other contextual information as request headers? Well, this is better. And it's not necessarily bad per se, but then how do you go about verifying that a client didn't self-declare their administrative permissions? How do you verify that headers haven't been manipulated? Or there's a lot of manual checks and balances like header request signing. And these are complex and they're non-standard approaches, which might just about work, but they're difficult to scale. A small change could open up a completely new attack vector. These approaches might have worked when we cared about the perimeter security when we took monolithic approach. But when we, with the introduction of microservices and consumption of SaaS services, the perimeter can no longer be well-defined. We have to aim to achieve zero trust architecture in a consistent and scalable way. So we think that the token exchange can solve this for us. And this specification extends the OAuth 2 protocol to enable clients to exchange one access token with another, via an authorization server. And why would we want to do that? And what does token exchange enable for us? So we have a few use cases. First one, enabling user impersonation. A client can impersonate as a user. This is useful when an administrator needs to rerun a task as if they were a user. Next one is internal to internal token exchange. A client can exchange an existing token created for a specific client for a new token targeted for a different client. This could be useful in case you want less permissive access rights when the service is calling another service. Internal to external token exchange. A client can exchange an existing token for an external token such as a linked Google account. And the last one, external token to internal token exchange. A client can exchange an externally minted token for internally minted token. This is very useful when you're a resource server, does not understand the issue of your access token or when you need to convert a SAML to a JWT and even enrich the access token with new user claims. Okay. So now let's go through the sequence diagram to see how the token exchange works. Okay. So before the exchange, an old client has already received an initial token that represent the user authorization. This may have been via client credential flow or an authorization code or another mechanism. This is written in green. Then the client request token exchange from the authorization server. This request includes that initial token and may specify desire scopes and intended audience or other properties for the new token. Then the authorization server validates the token exchange, the token exchange request. This involves authenticating the user if required and then authorizing the token exchange based on the initial token and the requested parameters. If the request is valid and authorized, the authorization server will issue a new token for the client. This new token might have different scopes, different audience and other properties based on the exchange parameters. If the request is invalid or unauthorized, the authorization server will respond with an error. At the end, the client now can use the new exchange token to access the protected resource from the resource server. So now, if the demo gods are willing, Ahmed will show us how to manually perform the token exchange. Okay. So I'm going to show, can you guys see my mouse? That might be easier. Yeah. So I'm going to show you an example, a token exchange request. The request gets sent to the token endpoint of the authorization server. In this case, because we're at Kubecom, we're using KeyClub. The request contains the client ID and the client secret of the client performing the exchange. You'll see that we have a new grant type. I'm just going to call it token exchange for short, but it's grant type URN, IETF, PRAMS, AWARF grant type token exchange. And finally, we've included the subject token, which is the access token that we initially received in order to access this service. Now, let's go ahead and see this working in action. We're going to do it manually. Hopefully, the demo gods are on my side. Can you tell me if this is large enough for you? Make it larger. Right. Let's hope I can, is that better? Okay. And is this okay? Or is that too big? Or is that, that's fine. Perfect. Okay. So before we do the token exchange, we have to authenticate the, you know, the very first request needs to be authenticated and authorized. So we have to, I've already set up key cloak here with my own users. It's logged back in. Then where I've got super insecure credentials, but I'm on local hosts. So I've already got a user set up here. And so I've configured a client inside key cloak and it's just called web app. And this is the, I suppose the browser application and we're going to be using, or postman in this use case. And this is an authorization code. We're going to be doing the authorization code flow. And the client, which is going to be performing the token exchange, is what we call tight gateway. And the way that I set it up like this is because of the following demos after. So, yeah, so that's basically it. If we head over, we're going to just log in via the web app. So this is just the authorization code flow. And I'm going to make that a little bit bigger so we can see what's going on here. And under auth, we can see that I'm configuring, I can, if I scroll up, you can see it's just a regular authorization code flow with postman as the callback URL. And then we have the regular authorization URL and the token URL there. And it's the client ID, so it's the web app that's that's authenticating. So this is just a regular authorization code flow. I go ahead and get a new access token and then I master sign in. So let's go ahead and do that. And go ahead and log in. Woohoo, it works. And proceed. And I now have an access token. So let's go ahead and have a look at what this access token looks like inside. And copy that. And we can paste that into jwt.io. And we can see in this access token, does that need zooming in as well? Is that okay? One more. One more. Cool. And what we can see is that when we generated this access token, this is because of the way that we've configured key cloak already, that the authorized party is the web app. We've got my identity in here in this access token. And the intended audience for this token is tight gateway. So that means that tight gateway is allowed to accept this client, is allowed to accept this access token. And now what we want to do is perform a token exchange. And we're going to do that manually. So let's go ahead and copy this token. And we're going to do an exchange of this access token with the body. Bear with me for a moment. I might have to just zoom out a little bit because I don't have much real estate here. And I'm going to replace that sub the token in here with the new access token that we received. And we're using in here the credentials of the different credentials of the client. And we can go ahead and send that request. And you'll see that now the client has performed the token exchange and obtained a completely new access token. So if we copy this access token, let's hope it copied or not. I'll copy it again. No, I'm suffering here. Copy that. And we paste that in there. And you can see that now the authorized party is the tight gateway. So this is a completely different client that's authorized. So but we've managed to propagate the identity of my user when I authenticated. So that's the most basic use case of the token exchange. Do you want to jump ahead now? And we can now build on this a little bit more. Okay. So we've seen how the mechanism works. For this talk, Ahmed and I also created a native middleware for tight gateway, which can perform for us this token exchange automatically. Rather than passing around the web apps access token, the gateway as the API gate, the gateway as the API gateway performs token exchange using its own credentials. And because of the way in which it has been set up in Kiklog, we're able to automatically secure and propagate the user identity into the gateway's access token. Using this impersonation semantics, it is almost as if the user who originally gave permission to the web app has actually given permissions to the gateway. So this JSON document represents a configuration for tight API gateway, which tells tight to validate an inbound access token, and then exchange that for a new token. You can see here as part of the API definition, the token exchange object, and we can see minimal setting required for performing token exchange against Kiklog, the authorization server. The target URL in this example is HTTP bin service. This service is an echo server which helps us with this demo, as it allows us to see the content of the request when it is received from the gateway. Okay. And okay. Perfect. So we're going to go ahead and show us how this is working now. So let's open up my next collection, which is login and request, and I'm going to close that collection to give us a bit more space, and make that a little bit smaller. Authorization. This is really difficult now. Okay. So let's go ahead and do that. I'll get new access token to authenticate. Oh, hold on a minute. I've done it wrong already. Bear with me for a minute. Let's log out my user. Do I need to log out for this example? No, I don't. Do I? Sorry. And we can go ahead and use that token in our request. And what that's done is pasted the token here, and we're going to access the HTTP bin service via the gateway. So now, when we send the request, and the gateway has now received the request, it's validated our initial access token that was issued by Kiklog, exchanged that token for a new token, and then proxied that request on to HTTP bin, and we can now see that we've got a different access token here, and this access token that was received by HTTP bin, if we paste that into jw2.io. So we can see that the gateway, in fact, was the authorized party. So using this, it's really, really seamless, and we recommend, or we would like to see more gateways and more service mesh services implementing these kinds of capabilities. Okay. So in our previous example, we used the gateway to protect the perimeter and exchange an inbound access token for a new token which could be used internally. It's also possible to exchange a Kiklog token for an external token minted by an externally identity provider. Consider a situation where our web app application possess an access token issued by a default identity provider, or Kiklog, which is in a trusted domain, but now our application needs to access Google Calendar APIs, which as we all know is residing in Google's domain and secured by Google. Our application must obtain a secure token from Google to access the Google API. This is another great use case for token exchange grant type. Just that this one involves two identity providers, which requires existence of a trust relationship between the two of them. So let's quickly go through this flow. First, the user authenticate with Kiklog. Then Kiklog issues an access token to the web app. And you can see the issuer is Kiklog. Then the web app is using the Kiklog and making an API call to the API that sits behind TIE gateway using the access token it got from Kiklog. Then in number four, the gateway is doing a token exchange against Kiklog, which is its own its identity provider. And it's using that original Kiklog token. Kiklog in its turn exchange does a token exchange again against Google. And Google returns the Google token and then propagates it to Kiklog and Kiklog to the gateway. With that, the gateway can reverse proxy to the service that is now using the Google token and can access the Google calendar. And now we can see this in action. So here, we have an API definition. It looks almost like the previous one, but with the exception of the target of the URL pointing to Google. No, it doesn't work here. Okay. And then you will see from the screenshot here that we have a configured Google as an external identity provider inside Kiklog. And here on the right bottom, we set up Kiklog as an oath client in Google. Also note that we have introduced a new parameter for this to in order for this to work. We're basically telling Kiklog that during the token exchange it needs to use an external identity provider Google as the external issuer. Okay. So this is the one where I have to actually make sure I'm logged out. Bear with me for a moment.  Okay. So there's no users for this session. But what you will see is for this to work, you have to ensure that under identity provider links, you've got Google as the, that Google has been associated with the user here. Now in this example, we're going to open up the collection, the collections, and this is demo three. And I'm going to close that to give a bit more room. I think I'm showing the end before I should. So what we're going to do is obtain a new access token, just like before. And now I'm going to be signing in with Google, signing into Kiklog with Google. See if it works. And I'm going to choose my Google account. And now Google needs, now Google wants to know that it's allowed to access my calendar. So I'm going to allow that and proceed. And now we have a new access token here. So despite the, you will have seen that Google has authorized, so I've allowed my app to have access, sorry, Google, I've granted permission for my app to have access to my calendar. And now I've got an access token. So let's have a look at what this access token looks like. Okay. You'll see, just like before, it's a regular Kiklog access token. There's nothing, nothing different about it. So because my services within my infrastructure doesn't understand Google tokens, they only understand Kiklog tokens. And now I can go ahead and use that token. And because the gateway has been configured to talk to Google's APIs, I can now browse the body of the request. And maybe I want to have access to my calendar, for example. So I can now send a request. Let's see if that works. Fingers crossed. And now I'm able to see, using the free busy endpoint of the Google API via the gateway, I'm able to have access to my calendar. Okay. So token exchange within Kiklog is in technology preview. Kiklog's token exchange implementation is loosely based on the OAuth token exchange specification at the IETF. And whilst it extends some aspects, it also ignores and loosely interprets other parts of the specification. And we do have some observations for the implementers. So developer experience, we're not Kiklog experts but neither are we complete new business. Configuring Kiklog for token exchange is far from a simple task. Creating policies, client scopes and mappers and enabling token exchange for a client is very time-consuming, error-prone and could greatly benefit from a simpler workflow. From building out our demo for this talk today, we found out that for internal to internal tokens, we've not yet been able to control the desired audience of the exchange token. We've gone through the documentation. We've tried to run through examples and there's not much, there aren't any tutorials online that are comprehensive. And even the documentation, it does have warnings but I think there's something that we're doing quite, you know, a little bit wrong. It's really difficult to configure it. Properly, you know, we're not able to control that audience and we'd love to be able to do that. We just failed. We just failed miserably. In addition, scope support is on the roadmap but not yet implemented. Scope support is important because it enables us to define fine grant permissions to an access token. And last one. Yeah, lastly from what we see with the Kiklog implementation, tight gateway by exchanging the token has been able to impersonate the user but it would also be useful if the web app would be able to delegate rights to the gateway. In other words, tight gateway would like to be able to act on behalf of the web app and we'd like to be able to see this as part of maybe a composite, as part of maybe a composite token support as part as per the specifications. This is because the user delegated rights to the web app and has no knowledge of the tight gateway. Okay, so first of all, thank you very much for listening to our talk. You're welcome to come and see us in L14 booth and say hi, but first of all, if you have some questions, you can go to the mics on the aisles and ask us something. We still have time. Does anyone have any questions? Yeah, to the mic. Yeah, just in the middle. Yeah. Don't fight. Hi. Okay, so hopefully this is not too difficult of a question but I was thinking to myself, as you were talking about all these mechanisms to refresh tokens and exchange tokens, what if my system is simple enough that I only really have one service? Does all of this still apply or is there like a simpler setup that makes sense? So I think I can answer that. If you've only got one service then you're not needing to propagate the identity anywhere, but that one service, does it need to talk to third-party SaaS services or anything like that? Or if it has an API gateway in front of it? Yeah, should that gateway have the be able to pass that access token around? How does the gateway know what's going to happen to it after it's left, after it's proxied the request elsewhere? And I'm struggling to believe that there's only one service because you are using other third parties like Ahmed said for sure and you're checking other stuff, even if it's just an API call, it's it's in a different trusted domain, so potentially you will improve your service, you'll add just something, you know, like just another thing and you will find yourself passing on user information. Thank you. Hi, nice talk, that was super super good. So my question regarding kind of performance and latency increases and things, so with the current authentication authorization flows that we might already have, if you've got multiple chains, like be on the gateway and a single service and then that service calls the other services and it goes back, you probably want to do these sort of token exchanges on each call between each services to make sure that maybe like service C in the chain then needs to call service D and it doesn't want to pass on and do privilege sort of passing the privilege of the token. What sort of measurable, have you looked into performance issues of like doing all of these calls plus your own maybe authorization calls to your own authorization system? So we haven't measured the latency or anything like that but from for our for our proof of concept and this this middle web that we created we implemented caching so we're caching the signature of the initial access token and we're looking up that we're using it as the cache key so that way you're not having to re-perform the exchange when you receive the same initial access token over and over again so then it's much much faster. Okay yeah thanks okay from that side Hi thanks for the presentations and for the demos I was wondering if you have any news about you know token exchange being still in preview it's a preview feature in Keycloak since long time do you have any news when this could become a supported feature? We're not in the Keycloak team so but they are here so well hope to hear you just behind you but I was wondering if you know anything about it like yeah we're not sure we're not sure yet so we're keen to see it move on and you know I'd love to help the Keycloak team to to make it you know to make it GA and raise more awareness about the about the protocol as well so yeah no thanks yeah Hi my name is Thomas thank you very much for your talk I'm one of the Keycloak maintainers and we are currently working on re-wising the token exchange support and getting it out of preview and solving a lot of the issues that you mentioned there so I'd love to talk to you I'm going to come and see you I'd love to help so I've got a question about your middleware how closely does it follow the RFC because obviously Keycloak is very handy but what if you want to write your own token exchange server sorry did you say how how closely does Keycloak follow the RFC no how closely how closely does your middleware follow the RFC okay we literally just built the middleware for the purpose of this talk right okay so it does follow and it works with Keycloak so we haven't tried it with any other identity providers or anything like that it works well with Keycloak it's a poor request in draft mode so it's not it's not bulletproof yet but we're you know we want to move it forward and get the community playing with it using it and seeing if it works for them so come and see us BoothL14 and we can kind of talk about that and maybe give you a demo as well about it you know and discuss your use case as well I have I have a question do you happen to have any scale scalability data on this how well it works at what scale have you seen it work so well it's well I think we were asked that before we built that as a POC we do have caching I hope I understood your question correctly but we have caching for for that token exchange and for example if you implement if you think about for example service mesh where you have a gateway front in an API so every API call will will go through the gateway and the gateway is implementing the caching so it is an extra hop but then it depends on fine tuning the caching right I was looking for like how many services have you tried with this like in the number of services microservices you mean in a chain of chain of calls yeah yes it will add up it depends on the connection to the authorization server however there is value for that in terms of security so it really depends on what you're doing and you know if you need to to make an API call to a less trusted domain then it might be worth it right okay thank you and it will be faster than calling out to Google so because obviously key cloak will be in your own infrastructure so that will be you know local network latency as opposed to going you know out over the internet into the cloud somewhere thank you for the great talk and it was very useful because it also directly relates to what we are facing right now and figuring out that this option exists was an amazing thing thank you but I have a question regarding long lasting operations or whenever your gateway would need to schedule something happening in a long time away from the point that the request was made scheduled in it it might exchange the token right away and get a access token and a refresh token but it will still need to push it somewhere for the duration and the refresh token or the access token duration might expire during that time how would you advise handling a situation like this okay we just we just got the message that we have to finish but it's a really good question I don't think if I remember correctly it's not part of the RFC so whatever you'll do depends on you know specific implementation it is really good idea to think about that I agree and yeah maybe we can think about it together I'll drop by the booth yeah yeah cool so in the demo that you gave you signed in as Google in order to exchange for a Google token is it possible to have the identity provider that you sign in and the third-party service that you're exchanging for be different or they have to be the same identity I think that's dependent on the identity providers or that's dependent on key cloak and I think it's worth speaking to the guys that are here to understand how that the mechanics of that works exactly because we have to ensure that the Google accounts are linked in order to be able to access the to access that calendar right so this is specific to key cloak and not according you know it's not a standard and different providers will implement it in a different way yeah and that part isn't and the way that it's been implemented within key cloak isn't actually part of that token exchange spec it's just how they've leveraged those capabilities to enable this this kind of feature right okay thank you so thanks very much slides are on the QR code if you're interested


So going back about 2,000 years, we know that there was a small messianic movement that developed in the land of Israel among Jewish people who believed that Jesus was the Messiah. And even though he was executed, crucified by the Romans, which was something that shocked and disappointed them, they continued to have faith that he would return. And so this small group of people centered themselves in Jerusalem, and they were awaiting the return of Jesus, many of them expected that he would return within that first century, within a generation. And we know that that didn't take place. Jesus crucified around the year 30, and 40 years later, he's still not back. And at that time, this community, this small group of followers that Jesus has, they are devastated with the Roman destruction of Jerusalem, and the movement from that point on scatters, many of them go to Jordan that is theorized, others scatter to other parts of Israel. But what happens basically is that over the next 230 years, this movement slowly disappears. And by approximately the year 300, you really would not be able to find a Jewish person who says they believe that Jesus was the Messiah. And this is one of the great ironies of history because originally, in the first century, if you met anyone who told you that they thought Jesus was the Messiah, one thing you would know about them is that they were Jewish. And by the fourth century, if anyone told you that they thought Jesus was the Messiah, you would know one thing about them, that they were Gentile. And what is quite startling is that not only did the population of Christianity dramatically switch, because we know the movement was originally strictly a movement among Jews. Jesus told his followers that he only came for the Jewish people, and he only sent his followers to preach to other Jewish people. He told them specifically not to go to the cities of the Gentiles or the Samaritans. And so the entire movement switches dramatically from a Jewish movement to a Gentile movement. And then we know, surprisingly, that this non-Jewish movement of followers of Jesus grows to become the largest religion in the world as of today. So how does this happen? So although the movement of Jews who had faith that Jesus was the Messiah and that he would return, although this movement died out, we know there was a parallel movement, because during the first century there was a fellow named Paul of Tarsus. Paul of Tarsus never met Jesus, never met him in person, but claimed to have had visions where Jesus appears to him in visions. And Paul doesn't operate within the land of Israel among Jews. Paul basically takes his message, spreading his beliefs about who Jesus was to the Greco-Roman world in Asia Minor. And Paul becomes very successful in spreading his message. Paul attracts many thousands of converts to his message. And by around the year 300, this movement that basically is a product of Paul, not so much of Jesus, spreads to become a movement approximately the same size as the Jewish world. You have approximately 10% of the world at that time of the Roman Empire are Jews, and by the year 300 approximately 10% are Christians. It is a small group, and it's actually not a very popular group because Christians are more or less despised by the Roman pagan world. What changes changes dramatically in the beginning of the 4th century. You have the conversion of Constantine, who was the Roman Emperor to Christianity, following the conversion of his mother Helena. Now historians debate whether or not Constantine's conversion was an actual sincere religious conversion, or it was done for more pragmatic reasons, but nonetheless Constantine becomes, at least on paper, a Christian. And he eases a lot of the pressures and restrictions and prejudices that had been operating in the Roman Empire against Christianity. And in the year 325, he convenes the Council of Nicea, which is the first major gathering of all Christian leaders to consolidate Christianity. He saw Christianity as a very convenient way of harmonizing all the various different cultures within his realm. The problem of the Roman Empire was that it composed many different peoples with many different beliefs and philosophies, and it was a recipe for disaster because people would not be getting along. And so Constantine saw Christianity as a way of unifying his entire empire and having a cohesive world. In order to do that, he realized that various factions and beliefs and points of view within Christianity had to themselves come together, and that was the point of the Council of Nicea. This beginning of the process of Christianizing the Roman Empire was finalized around the year 380, by Emperor Theodosius, with his Edict of Thessalonica. And Christianity at that point becomes the official state religion of the Roman Empire, which if you're looking for an incredible head start to becoming the world's largest religion, there you have it. An empire that was at one point totally pagan becomes essentially 100% Christian. And with this religion, with Christianity entrenched as the official state religion of what we call now Europe, we know that in the 1400s the European societies began to colonialize the rest of the world. And so with colonialization Christianity is spread to the Americas, to Africa, to Asia, not so much by convincing the peoples, the first nations in these places that Christianity is the true faith, but basically Christianity is imposed upon the native populations in these countries. So with all these developments Christianity quickly becomes, or not so quickly, over the course of hundreds of years the world's largest religion. Now part of what happens is that Christianity is able to spread to many parts of the world because it appeals to people on many levels. For example, the pagan world prior to Christianity was a world where there were no ethics or morals. Christianity basically begins spreading ethical ideas and moral teachings that were rooted in the Jewish Bible. So for example, the idea of a creator versus the paganism of having many, many gods. The institution of things like charity and caring for the poor and the widow and the orphan. These are ideas that were rooted in the Tanakh the Jewish Bible and become spread through the missionary efforts of Christianity. And finally what's attractive to many people is the idea of a coherent history of the world that is rooted in ancient texts. Throughout the world people respect ancient texts. It has a clout of authority and stability in reality. So these are some of the reasons why Christianity, aside from the fact that missionaries generally imposed it on the populations they were colonializing, it was able to spread as well because many of the features of Christianity were basically presenting basic Jewish ideas to the rest of the world. Maimonides shares a daring idea. Maimonides in a section of his missionatoria, which was actually censored and taken out by Christian censors, but we discovered them not too long ago. So Maimonides shares an idea that perhaps he suggests one of the reasons that Christianity spread throughout the world, and he actually includes in this Islam. So he deals with the question of why is it that Islam and Christianity, which you can see as daughter religions of Judaism, why were they so successful in spreading the entire world? And Maimonides suggests that possibly this all plays into God's plan to bring about the ultimate harmonization and realization of the spreading of truth to the entire world because he doesn't say this, but I'm going to be reading into what he says. He says that if the Jewish Messiah came to a pagan world, the world would not notice. It wouldn't register because the idea of a Jewish Messiah in a pagan world doesn't engage them. It's irrelevant. And so what happens is in Maimonides' presentation is that world history basically is a history where the two dominant religions, Christianity and Islam, are basically religions that have an adversarial relationship with Judaism. And what happens is our relationship produces a kind of tension. There's a tension that's being built up, that we have this huge religious debate going on because the claims of Christianity, the claims of Islam are mutually exclusive with the claims of Judaism. And yet they revolve around very common ideas, teachings about a Bible, teachings about one God, teachings about a Messiah. And so what Maimonides suggests is that by having the spread of Christianity and Islam through the entire world, the entire world now is learning about these primary basic concepts that are relevant to Judaism. And that it's preparing the world for the ultimate revelation of when Messiah finally comes, when Messiah finally comes, the world is going to be able to have an aha moment. They're going to be able to say, oh, now we understand. Now we see what the Jewish people were always talking about. And so Maimonides suggests a possible reason for, again, why the idea of the spreading of Christianity might fit into God's ultimate plans for the completion and the coming to the fruition of all the promises for the messianic utopia in the future.