WEBVTT 00:00.000 --> 00:12.480 So maybe just to keep this schedule I'll just start if you allow. 00:12.480 --> 00:17.280 So good morning everybody, my name is Timothy, I was already set and I really appreciate 00:17.280 --> 00:25.280 you being here so early on such a lovely Sunday morning, today I'm going to talk about 00:26.240 --> 00:32.240 I'm done and putting you up my source project and yeah, so thank you for your interest and I also 00:32.240 --> 00:38.400 would like to thank my employer in a queue who was sponsoring my trip here. So if you're wondering 00:38.400 --> 00:44.640 why I use corporate Slackmaster, that's the reason. Maybe you're also interested in a little bit 00:44.640 --> 00:51.600 of background about me since I have the opportunity throughout my entire career. I have 00:51.600 --> 00:57.680 served many different challenges in many different projects I've been involved in and I've got 00:57.680 --> 01:02.880 also specific insights from my colleagues and this is actually also the background of I'm done. 01:03.920 --> 01:08.800 So let's take a look at what are those challenges or what were those challenges which led to the 01:08.800 --> 01:16.000 development of that new service. I would like to start with a couple of concepts because we are here 01:16.000 --> 01:21.200 in the realm of authentication and authorization and there we have to deal with two key concepts, 01:21.200 --> 01:27.440 namely subject in an object. A subject acts in an object so essentially it's an entity which tries 01:27.440 --> 01:33.120 or wants to perform an action on an object. But since we are here in system context, the subject 01:33.120 --> 01:39.840 can do that directly instead those actions are represented by kind of requests. Something like 01:39.840 --> 01:45.280 if you click a link in the browser which results in an API call which may or may result in a specific 01:45.360 --> 01:51.440 presentation delivered to you to your browser back or may or may not result in a specific 01:52.480 --> 01:58.720 modification of an object. You know this is depicted by the error here. Now this may or may not 01:58.720 --> 02:04.080 means there must be some kind of an access control enforcement taking place before that action can be 02:04.080 --> 02:09.280 executed and to be able to do that we need to take some kind. 02:15.280 --> 02:22.160 But to do to be able to do that enforcement we need to perform some kind of a decision, 02:22.160 --> 02:27.920 yeah access control decision. This is where we talk about roles, attributes, relationships, 02:27.920 --> 02:33.360 all depending on how we implement that stuff and there are many many great products which support 02:33.360 --> 02:41.680 us with that. But you know what very often to be able to perform that decision be rely on information 02:41.760 --> 02:47.360 or date which is not part of our request. So we need to collect it somewhere to call other 02:47.360 --> 02:53.760 system and such systems etc and this is what I personally name contextualization. But there's 02:53.760 --> 02:58.720 one additional thing. Without moving who is our subject, without moving its identity we cannot 02:58.720 --> 03:08.080 do much. So that means we will have to take specific protocols and maybe factors to prove this 03:08.160 --> 03:14.160 identity of this subject and this is where authentication comes into the game. So pretty complex 03:14.160 --> 03:22.880 stuff and all of that is something you need to do, right? But you know what all of that has been 03:22.880 --> 03:30.960 already described actually by standard. The Miss Special Public Publication 1862 it gives those 03:31.040 --> 03:39.520 rectangles specific name, describes their meaning and how they interact if you like. So let's 03:39.520 --> 03:45.760 take a look. This is this next slide. Most of this stuff presented on the previous stuff is already 03:45.760 --> 03:52.720 known to you. So we have the same subject, we have the same object. Our access control enforcement 03:52.720 --> 03:58.720 part is official named policy enforcement point. It's kind of intercepts our requests and the 03:58.720 --> 04:03.280 talks to the policy decision point which is the logic responsible for the decision taken 04:03.280 --> 04:11.280 purpose. It makes use of some kind of a policy, so some think where we have implemented that 04:11.280 --> 04:18.160 logic in and this is the policy repository where those policies reside in. And those policies 04:18.160 --> 04:24.800 can be managed, why or I'm usually managed, why a policy administration point. The last thing which 04:24.880 --> 04:29.120 is not yet covered is the policy information point and this is basically nothing else as the 04:29.120 --> 04:37.920 consent contextualization part I show on the previous slide. So let's label the names I use previously 04:37.920 --> 04:44.160 so we have everything on one place. So back to our other slide, this is that. So obviously 04:44.160 --> 04:49.840 authentication I hope you can see somehow is not covered by the standard and we will come to that later. 04:50.560 --> 04:55.840 But since we are talking about our systems and I promise you to talk about complexity 04:55.840 --> 05:01.920 I faced almost all the time, my question to you would be how would you implement all of that? 05:01.920 --> 05:08.320 Okay, you don't have to answer it, we'll be longer sessioner I assume. So I'll show you what I usually see 05:08.320 --> 05:14.480 and what I usually see is that everything is written your code. So we call the rules in the code 05:14.640 --> 05:21.280 and how does it look then? And since it's our code, our policy repository is just our 05:21.280 --> 05:27.120 git because our git resides, so our code resides in our git. So how does it look usually? 05:27.920 --> 05:34.240 Here's a small abstract example. So imagine we have a fancy function update food whatever that is 05:34.240 --> 05:40.000 and at the end of that function we have the actual business logic and before we have all that decision 05:40.080 --> 05:46.960 taking place and such, there are multiple issues with that approach. In addition to that we 05:48.640 --> 05:54.560 described logic in our own code which is which will become unlandable with it with the time, 05:55.280 --> 06:02.080 we have things like we code against the rules which might change over the time and usually it 06:02.080 --> 06:08.480 does. What I see in all my projects or in all projects I'm going to evolve into is that the 06:08.800 --> 06:16.640 requirements related to authorization logic they become more and more and the code becomes unmanentable 06:16.640 --> 06:21.680 and there are many issues in addition. Like for example what you can see also here we don't have 06:21.680 --> 06:28.000 any logging or similar capabilities implemented so that means we don't know who was able to update 06:28.000 --> 06:34.960 that fancy food or who was trying to do so but failed or that is not there and actually because of 06:35.040 --> 06:41.120 all of that it's an empty pattern. There are much more things going on going here but I have to stay 06:41.120 --> 06:49.920 in time and that pattern is actually also described by the over microservice cheat sheet. Unfortunately 06:49.920 --> 06:57.440 without going into the data wise it's worth that just written there so maybe there's it's time to 06:57.440 --> 07:05.120 change it a bit. So let's come back then to our previous slide and see what doesn't mean where 07:05.120 --> 07:12.000 do our bubbles we cite so all in our code. Can we do it better? Can we reduce that complexity? Can we 07:12.000 --> 07:19.600 make sure we don't fall into this any patterns? Yes obviously you can imagine we can we can try to 07:19.600 --> 07:26.960 outsource the policy decision point part and make use of great products like open policy agent 07:26.960 --> 07:33.520 like open FGA like SpassDB. I think today there is going to be a session about open of 07:33.520 --> 07:40.080 J and we last year there were also sessions about SpassDB and also open policy agents so take a look 07:40.720 --> 07:48.960 and then we can at least reduce our complexity by making use of special purposes purpose solutions 07:48.960 --> 07:55.280 which allow us describing that logic but in special purpose DSLs so we can test them independently 07:55.280 --> 08:01.280 of our code and we can test our code independently from that logic and not code again draws 08:01.280 --> 08:08.960 but code again they actual people subject object and action so that would reduce our complexity 08:08.960 --> 08:14.880 and the PDP could then talk to the policy information point to get the required information 08:14.880 --> 08:20.640 but you know what that last part doesn't always work so pretty often we have to talk to 08:20.640 --> 08:27.120 those additional systems by ourselves especially if we use systems which do not allow that 08:27.120 --> 08:32.800 communication here so that's first part so still there's complexity but nevertheless 08:33.680 --> 08:39.840 it is reduced so if you go back to our off-use life and by the way this is also a pattern which 08:39.920 --> 08:47.440 depicted by all of us Microsoft has achieved and this is what they recommend so they go to 08:48.080 --> 08:54.400 all of the slide we see the PDP part is great out so we have reduced the complexity but there's 08:54.400 --> 09:00.000 still much more things to do and there are a lot of challenges we have to face with 09:02.800 --> 09:08.080 we could try to adjust that but before we can do so let's take a closer look at the authentication 09:08.080 --> 09:14.560 as I promised before so what does authentication mean for us in context of our systems so 09:14.560 --> 09:20.560 basically like I said before the subject can't do any action on an object directly it does 09:20.560 --> 09:26.560 so why kind of a touch point yeah my example was you were using a browser so let's give it a name 09:26.560 --> 09:33.600 yeah so the subject use talks to our system over a touch point web what does it mean 09:34.400 --> 09:39.440 in sense of the implementation that which protocol should be supported for the sake of 09:40.480 --> 09:46.560 simplicity let's assume we are using of maybe connect here because everybody seems to use right 09:46.560 --> 09:54.560 now or today and this is a protocol but we need some specific logic on our server side 09:54.560 --> 09:59.920 responsible for the object differently we have to deal with two things here if you talk about 09:59.920 --> 10:05.440 the web touch point we have we need some kind of an opening to connect driver so the entity 10:05.440 --> 10:11.440 responsible for driving the authorization code on flow if there's no token in the initial request 10:11.440 --> 10:16.560 and if there's a token in the request we have to verify right so we have to deal with that 10:17.680 --> 10:23.440 but usually we don't have just one object in our system we have many objects or basically many 10:23.440 --> 10:29.680 object types and all of them might have different requirements on authentication right so that does 10:30.080 --> 10:37.120 that means that part here the day part here doesn't always work unfortunately especially if you 10:37.120 --> 10:44.400 want to have public start if you have specific requirements we'll have to duplicate that and 10:44.400 --> 10:50.320 adjust that to the needs yeah this is pretty challenging and since we have multiple objects 10:50.400 --> 10:58.720 who said that we have just one option for our touch points in the today world world we 10:58.720 --> 11:05.600 may be use our smartphones so some check may use something like that we have our IT devices 11:05.600 --> 11:12.320 yeah and last but not least we might have or we may open our APIs to third parties which provide 11:12.320 --> 11:19.840 added value services to our customers based on what we offering can let's assume we can use the same 11:19.840 --> 11:24.960 protocol for all of them just for simplicity it doesn't always work yeah you see where I'm going 11:24.960 --> 11:33.120 to where I'm going what doesn't mean for that right side part can we we use the same implementation 11:33.120 --> 11:38.800 I would say no because in case of a mobile phone the token driver or the open the 11:38.800 --> 11:43.840 reconnect driver is implemented part of that client yeah so the only thing which remains is the 11:44.240 --> 11:54.080 token verifier maybe we can do the same for the IT device but can we do the same for our 11:54.080 --> 12:00.080 third party I would say no please don't do that because those tokens they contain privacy data for 12:00.080 --> 12:07.520 example subject ID and they just use the same representation of our subject for different third parties 12:07.520 --> 12:14.160 we run in the link ability issues and violate GDPR requirements yeah you shouldn't do that 12:16.000 --> 12:22.160 this is the context of authentication and the challenges we have facing there as well so let's go back 12:22.160 --> 12:29.520 to our previous slide and just add the bubble out then in front of our TEP now we know what could 12:30.320 --> 12:37.120 do to address that challenge here and the challenges with the police information point and also 12:37.120 --> 12:43.040 their authentication is still part of our code yeah can we do it better can we use it and you've seen 12:43.040 --> 12:52.320 the complexities over there in principle yes we could try to outsource that to manipulate it 12:52.480 --> 13:00.240 this is what always named H level access control but the issue might be obvious to you yeah so the 13:00.240 --> 13:08.560 issue is the code response before the object is a latent and developed by us developers and the 13:08.560 --> 13:17.440 API gateway is maintained by ops so there's a social technical issue here and it relates to the 13:17.440 --> 13:24.160 requirement that the ops need to adjust or configure the API gateway based on the requirements 13:24.160 --> 13:31.280 or on the code site right each API has its own requirement this doesn't scale and this is also 13:31.280 --> 13:38.320 something which has been criticized by the over microsoft chief microsoft's chief sheet can we do it 13:38.320 --> 13:46.000 better can we somehow resolve that social technical issue I would say yes we can allow our 13:46.000 --> 13:54.240 devs to control that part responsible so the part of the API gateway to allow them to configure 13:54.240 --> 14:00.960 those requirements they need yeah and this is where handle kicks in so this is what handle does so 14:00.960 --> 14:06.640 your question will be now okay should I do I have to replace all my infrastructure 14:06.640 --> 14:14.080 processes that you know with handle no obviously not obviously based on that diagram here 14:14.160 --> 14:19.120 and principle you can integrate handle with whatever you have right now so it works with any 14:19.120 --> 14:24.560 proxy or by gateway supporting things like forward out middle bears or external authentication 14:25.600 --> 14:37.040 with involve or be something else and then it can I use my mouse here it can integrate with any 14:37.040 --> 14:43.440 protocol driver yeah it can talk to your IDP or multiple IDP directly it can talk to any 14:43.520 --> 14:49.360 process this system to collect the information you need to do they actual authorization and 14:49.360 --> 14:54.800 can talk to whatever PDP you have in place yeah so it's basically kind of an orchestrator 14:55.760 --> 15:01.120 to what you have and all of that can be controlled via rules so this is how it works 15:02.880 --> 15:12.240 and so with that in place and there are couple of examples also on the Netflix blog post etc 15:12.400 --> 15:17.520 with up in place we can reduce all the complexities out of our code and the only remaining thing 15:17.520 --> 15:23.680 as a small piece of also also a authorization you have to do you've seen there's a job which has been 15:23.680 --> 15:29.120 issued by handle itself this is the only part which remains and at the end you have a combination 15:29.120 --> 15:35.920 of two patterns you have a combination of protocol diagnostic identity propagation plus H level also 15:36.000 --> 15:44.320 authorization but since we are using cryptographic options there there's no way to bypass 15:44.320 --> 15:49.760 that part and it goes much beyond the possibilities described by the OS chipsheet 15:50.720 --> 15:57.360 I would like to show a small demo here which I started all of you with my mouse 16:05.920 --> 16:34.400 so most of you may be aware of a service named medium.com yeah so you can there are a lot of 16:34.400 --> 16:41.360 blockposts maybe which you can read etc to gain information about whatever you want and this is 16:41.360 --> 16:48.400 kind of mimics that and when I just opened this page here handle is already in place and already 16:48.400 --> 16:54.560 actually already because the different representations of this page results based of the decision 16:54.560 --> 17:01.040 or actually the flows controlled by handle so for example this login button is rendered because 17:01.680 --> 17:10.080 not login I'm an anonymous user so what does it do actually what is this part is around like I said 17:10.080 --> 17:18.400 it's mimics or medium.com and you have different articles here and the requirement is that if you are 17:18.400 --> 17:25.760 not locked in you can just list articles but you cannot see the contents and if you are locked in 17:25.760 --> 17:30.480 or if you have an account they are different pricing cards like if you're just a basic of 17:31.200 --> 17:35.840 a startup tire you can just read two articles per day and such around such rent if you have a 17:35.840 --> 17:42.880 premium tire you can do whatever you want write your own articles and such right how does it work 17:42.880 --> 17:49.680 behind the scenes let me show you my IDE hopefully you can see something 17:56.720 --> 18:01.840 the important part is actually here you see it's Docker compose setup and there are many 18:01.840 --> 18:06.880 many many different services so based on my previous slide it would mean I would have to create many 18:06.880 --> 18:13.520 many rules for each of the service but this is one of these things handles aims to address reduce 18:13.520 --> 18:19.520 complexity right not only on the protocol and system level but also on what you have to do and for 18:19.600 --> 18:28.560 that reason handle has a concept of the so-called as my mouse mouse 18:34.240 --> 18:42.400 of a so-called default rule you can see it here the default rule describes 18:43.280 --> 18:50.000 an authorization and authentication pipeline which is executed always when there's no rule at all 18:50.000 --> 18:55.920 in addition it defines kind of a template so it means all other rules if the default rule is present 18:57.520 --> 19:05.440 inherent the behavior of it and only those things which are different can be replaced so in that case 19:05.520 --> 19:12.400 the default rule says every request which pass through should be should go through the authentication 19:12.400 --> 19:20.320 or through should be shielded by those indication mechanisms here I have as an IDP I have 19:20.320 --> 19:26.480 cratos from ORI great for that guys if you see that and at the end I create just a job and if something 19:26.480 --> 19:32.240 goes wrong there's an error pipeline that kicks in and you can provide your conditionals when it should 19:32.320 --> 19:37.680 be executed when should you do and you see just a reference on to something so what are those 19:37.680 --> 19:45.520 references so we have steps here and this steps usually if you don't have specific configuration requirements 19:45.520 --> 19:52.560 they just reference what I name mechanisms and this what you have you can see here is a mechanism 19:52.560 --> 20:00.400 catalog and you can describe authentication mechanisms you can describe alsoization mechanisms 20:00.480 --> 20:05.920 so you see for example here have a configuration to talk to open policy agent you can 20:05.920 --> 20:11.760 describe your own contextualization mechanisms or the systems we should communicate to and 20:11.760 --> 20:19.040 and so on and the end the rule can be as simple as that and given that think here I'm able to 20:19.040 --> 20:24.400 reduce the amount of rule to the bare minimum so only those services which have specific requirements 20:24.400 --> 20:31.200 which go beyond the default configuration they need to define their rules and this is what 20:31.200 --> 20:38.000 you can see here so there are a couple of very simple rules like let's me show another one 20:38.000 --> 20:46.880 a more sorry so for example that one so you see I just override the authentication 20:46.880 --> 20:55.840 plan I said I allow our newest requests as well as authenticated requests to be able to provide 20:55.840 --> 21:02.080 different representation I said previously that there's also an option to combine different 21:03.040 --> 21:10.080 authentication protocols and this is what you were able to see shortly here I think no it was here 21:10.800 --> 21:17.520 where I have protocol agnostic identity protocol activation so the endpoint which is matched 21:17.520 --> 21:26.800 by that part here says okay I allow requests being done from the web touch point this is just a 21:26.800 --> 21:35.760 cookie stuff and in addition I allow requests none via a sort party which where jot is active and that's 21:35.840 --> 21:44.880 all and in your code the only thing you have to do is to care about the jot issued here and by the 21:44.880 --> 21:51.760 way the contents of the jot this is what is written here the default configuration it's something 21:51.760 --> 21:57.440 you provide yourself so you control all of that and that means you have a pretty much control 21:57.520 --> 22:02.960 about everything and if you test things you can mock a lot of stuff and in sense of the 22:04.800 --> 22:13.200 security it's there's no way then to bypass it this is what time though that and maybe one last thing 22:14.640 --> 22:20.880 if even I were a stalk or I'm post talking about open adi connect and etc I'm though that's not 22:20.960 --> 22:31.360 implement the driver for the authorization code flow the idea was to reuse what is already there and 22:31.360 --> 22:37.440 we have a young here for example from our two proxy so it's a great project and we can just 22:37.440 --> 22:45.360 plug in that for that particular part and that way we can say that endpoint is for public that 22:45.360 --> 22:51.840 endpoint is for example for the request open adi connect that endpoint requires cookie and 22:51.840 --> 23:02.160 etc etc without we need to manage all of that in our code that's that's all yeah and if you are 23:02.160 --> 23:22.960 interested to see more or as my presentation I did the presentation for CNCF 23:24.000 --> 23:29.360 half a year ago when I applied for CNCF sandbox so you can see the recording in YouTube here 23:29.840 --> 23:36.560 and yeah thank you very much last button at least this is very important for my side the project 23:36.560 --> 23:42.400 is very young so please support it join the community go to get have take a look try it around 23:42.400 --> 23:49.840 there are many demos all over there for Docker for for Kubernetes yeah and the documentation is 23:49.840 --> 23:57.200 very extensive because it's a complex team topic so it's supporting all the part there thank you very 23:57.440 --> 23:59.440 much 24:04.960 --> 24:08.960 so we have like five minutes for questions 24:15.760 --> 24:17.360 so thank you 24:19.360 --> 24:24.400 that's it work yeah so what are their plans for the future because I've been using for 24:24.400 --> 24:30.480 merium for I've been using for merium for a while and they also have a look to or a 24:31.360 --> 24:36.640 hot keeper and what I see from those projects is that they lock more and more features into 24:36.640 --> 24:46.400 the premium slash enterprise side of the tool so are you thinking of making up commercial 24:46.400 --> 24:51.840 product up to this you can think about what sort of and are you thinking of making a commercial 24:52.640 --> 24:59.600 I'm not thinking right now about making a commercial product out of it and to be honest 24:59.600 --> 25:06.000 I don't want to make that functionality somehow private so it should be an open source 25:06.000 --> 25:12.000 completely and that you'll remain that sooner or later of course I would like to earn money with that 25:12.000 --> 25:18.880 but that will be mainly related to support yeah if you like or consulting built around that 25:18.880 --> 25:23.680 so that's the kind idea but the core of how I'm doing what it does should always be open source 25:24.480 --> 25:29.920 and community dream so right now the community is pretty small so I mainly the only one maintainer 25:29.920 --> 25:34.880 and that's also the reason why it's here and say I've said okay cool project we like it but 25:34.880 --> 25:41.520 to let's two few stars to let's two few maintainers work on that come back to that later that's where 25:41.520 --> 25:55.760 I'm also here any other questions sorry there are many demonstrations but not that one 25:55.760 --> 26:02.880 shown here they are demo set ups which are much smaller but that demo which has yeah just give 26:02.880 --> 26:09.280 you all the the complete demo is available online on the SNCF Tech Network YouTube channel 26:11.520 --> 26:19.040 okay no more questions good thank you very much