So maybe just to keep this schedule I'll just start if you allow.
So good morning everybody, my name is Timothy, I was already set and I really appreciate
you being here so early on such a lovely Sunday morning, today I'm going to talk about
I'm done and putting you up my source project and yeah, so thank you for your interest and I also
would like to thank my employer in a queue who was sponsoring my trip here. So if you're wondering
why I use corporate Slackmaster, that's the reason. Maybe you're also interested in a little bit
of background about me since I have the opportunity throughout my entire career. I have
served many different challenges in many different projects I've been involved in and I've got
also specific insights from my colleagues and this is actually also the background of I'm done.
So let's take a look at what are those challenges or what were those challenges which led to the
development of that new service. I would like to start with a couple of concepts because we are here
in the realm of authentication and authorization and there we have to deal with two key concepts,
namely subject in an object. A subject acts in an object so essentially it's an entity which tries
or wants to perform an action on an object. But since we are here in system context, the subject
can do that directly instead those actions are represented by kind of requests. Something like
if you click a link in the browser which results in an API call which may or may result in a specific
presentation delivered to you to your browser back or may or may not result in a specific
modification of an object. You know this is depicted by the error here. Now this may or may not
means there must be some kind of an access control enforcement taking place before that action can be
executed and to be able to do that we need to take some kind.
But to do to be able to do that enforcement we need to perform some kind of a decision,
yeah access control decision. This is where we talk about roles, attributes, relationships,
all depending on how we implement that stuff and there are many many great products which support
us with that. But you know what very often to be able to perform that decision be rely on information
or date which is not part of our request. So we need to collect it somewhere to call other
system and such systems etc and this is what I personally name contextualization. But there's
one additional thing. Without moving who is our subject, without moving its identity we cannot
do much. So that means we will have to take specific protocols and maybe factors to prove this
identity of this subject and this is where authentication comes into the game. So pretty complex
stuff and all of that is something you need to do, right? But you know what all of that has been
already described actually by standard. The Miss Special Public Publication 1862 it gives those
rectangles specific name, describes their meaning and how they interact if you like. So let's
take a look. This is this next slide. Most of this stuff presented on the previous stuff is already
known to you. So we have the same subject, we have the same object. Our access control enforcement
part is official named policy enforcement point. It's kind of intercepts our requests and the
talks to the policy decision point which is the logic responsible for the decision taken
purpose. It makes use of some kind of a policy, so some think where we have implemented that
logic in and this is the policy repository where those policies reside in. And those policies
can be managed, why or I'm usually managed, why a policy administration point. The last thing which
is not yet covered is the policy information point and this is basically nothing else as the
consent contextualization part I show on the previous slide. So let's label the names I use previously
so we have everything on one place. So back to our other slide, this is that. So obviously
authentication I hope you can see somehow is not covered by the standard and we will come to that later.
But since we are talking about our systems and I promise you to talk about complexity
I faced almost all the time, my question to you would be how would you implement all of that?
Okay, you don't have to answer it, we'll be longer sessioner I assume. So I'll show you what I usually see
and what I usually see is that everything is written your code. So we call the rules in the code
and how does it look then? And since it's our code, our policy repository is just our
git because our git resides, so our code resides in our git. So how does it look usually?
Here's a small abstract example. So imagine we have a fancy function update food whatever that is
and at the end of that function we have the actual business logic and before we have all that decision
taking place and such, there are multiple issues with that approach. In addition to that we
described logic in our own code which is which will become unlandable with it with the time,
we have things like we code against the rules which might change over the time and usually it
does. What I see in all my projects or in all projects I'm going to evolve into is that the
requirements related to authorization logic they become more and more and the code becomes unmanentable
and there are many issues in addition. Like for example what you can see also here we don't have
any logging or similar capabilities implemented so that means we don't know who was able to update
that fancy food or who was trying to do so but failed or that is not there and actually because of
all of that it's an empty pattern. There are much more things going on going here but I have to stay
in time and that pattern is actually also described by the over microservice cheat sheet. Unfortunately
without going into the data wise it's worth that just written there so maybe there's it's time to
change it a bit. So let's come back then to our previous slide and see what doesn't mean where
do our bubbles we cite so all in our code. Can we do it better? Can we reduce that complexity? Can we
make sure we don't fall into this any patterns? Yes obviously you can imagine we can we can try to
outsource the policy decision point part and make use of great products like open policy agent
like open FGA like SpassDB. I think today there is going to be a session about open of
J and we last year there were also sessions about SpassDB and also open policy agents so take a look
and then we can at least reduce our complexity by making use of special purposes purpose solutions
which allow us describing that logic but in special purpose DSLs so we can test them independently
of our code and we can test our code independently from that logic and not code again draws
but code again they actual people subject object and action so that would reduce our complexity
and the PDP could then talk to the policy information point to get the required information
but you know what that last part doesn't always work so pretty often we have to talk to
those additional systems by ourselves especially if we use systems which do not allow that
communication here so that's first part so still there's complexity but nevertheless
it is reduced so if you go back to our off-use life and by the way this is also a pattern which
depicted by all of us Microsoft has achieved and this is what they recommend so they go to
all of the slide we see the PDP part is great out so we have reduced the complexity but there's
still much more things to do and there are a lot of challenges we have to face with
we could try to adjust that but before we can do so let's take a closer look at the authentication
as I promised before so what does authentication mean for us in context of our systems so
basically like I said before the subject can't do any action on an object directly it does
so why kind of a touch point yeah my example was you were using a browser so let's give it a name
yeah so the subject use talks to our system over a touch point web what does it mean
in sense of the implementation that which protocol should be supported for the sake of
simplicity let's assume we are using of maybe connect here because everybody seems to use right
now or today and this is a protocol but we need some specific logic on our server side
responsible for the object differently we have to deal with two things here if you talk about
the web touch point we have we need some kind of an opening to connect driver so the entity
responsible for driving the authorization code on flow if there's no token in the initial request
and if there's a token in the request we have to verify right so we have to deal with that
but usually we don't have just one object in our system we have many objects or basically many
object types and all of them might have different requirements on authentication right so that does
that means that part here the day part here doesn't always work unfortunately especially if you
want to have public start if you have specific requirements we'll have to duplicate that and
adjust that to the needs yeah this is pretty challenging and since we have multiple objects
who said that we have just one option for our touch points in the today world world we
may be use our smartphones so some check may use something like that we have our IT devices
yeah and last but not least we might have or we may open our APIs to third parties which provide
added value services to our customers based on what we offering can let's assume we can use the same
protocol for all of them just for simplicity it doesn't always work yeah you see where I'm going
to where I'm going what doesn't mean for that right side part can we we use the same implementation
I would say no because in case of a mobile phone the token driver or the open the
reconnect driver is implemented part of that client yeah so the only thing which remains is the
token verifier maybe we can do the same for the IT device but can we do the same for our
third party I would say no please don't do that because those tokens they contain privacy data for
example subject ID and they just use the same representation of our subject for different third parties
we run in the link ability issues and violate GDPR requirements yeah you shouldn't do that
this is the context of authentication and the challenges we have facing there as well so let's go back
to our previous slide and just add the bubble out then in front of our TEP now we know what could
do to address that challenge here and the challenges with the police information point and also
their authentication is still part of our code yeah can we do it better can we use it and you've seen
the complexities over there in principle yes we could try to outsource that to manipulate it
this is what always named H level access control but the issue might be obvious to you yeah so the
issue is the code response before the object is a latent and developed by us developers and the
API gateway is maintained by ops so there's a social technical issue here and it relates to the
requirement that the ops need to adjust or configure the API gateway based on the requirements
or on the code site right each API has its own requirement this doesn't scale and this is also
something which has been criticized by the over microsoft chief microsoft's chief sheet can we do it
better can we somehow resolve that social technical issue I would say yes we can allow our
devs to control that part responsible so the part of the API gateway to allow them to configure
those requirements they need yeah and this is where handle kicks in so this is what handle does so
your question will be now okay should I do I have to replace all my infrastructure
processes that you know with handle no obviously not obviously based on that diagram here
and principle you can integrate handle with whatever you have right now so it works with any
proxy or by gateway supporting things like forward out middle bears or external authentication
with involve or be something else and then it can I use my mouse here it can integrate with any
protocol driver yeah it can talk to your IDP or multiple IDP directly it can talk to any
process this system to collect the information you need to do they actual authorization and
can talk to whatever PDP you have in place yeah so it's basically kind of an orchestrator
to what you have and all of that can be controlled via rules so this is how it works
and so with that in place and there are couple of examples also on the Netflix blog post etc
with up in place we can reduce all the complexities out of our code and the only remaining thing
as a small piece of also also a authorization you have to do you've seen there's a job which has been
issued by handle itself this is the only part which remains and at the end you have a combination
of two patterns you have a combination of protocol diagnostic identity propagation plus H level also
authorization but since we are using cryptographic options there there's no way to bypass
that part and it goes much beyond the possibilities described by the OS chipsheet
I would like to show a small demo here which I started all of you with my mouse
so most of you may be aware of a service named medium.com yeah so you can there are a lot of
blockposts maybe which you can read etc to gain information about whatever you want and this is
kind of mimics that and when I just opened this page here handle is already in place and already
actually already because the different representations of this page results based of the decision
or actually the flows controlled by handle so for example this login button is rendered because
not login I'm an anonymous user so what does it do actually what is this part is around like I said
it's mimics or medium.com and you have different articles here and the requirement is that if you are
not locked in you can just list articles but you cannot see the contents and if you are locked in
or if you have an account they are different pricing cards like if you're just a basic of
a startup tire you can just read two articles per day and such around such rent if you have a
premium tire you can do whatever you want write your own articles and such right how does it work
behind the scenes let me show you my IDE hopefully you can see something
the important part is actually here you see it's Docker compose setup and there are many
many many different services so based on my previous slide it would mean I would have to create many
many rules for each of the service but this is one of these things handles aims to address reduce
complexity right not only on the protocol and system level but also on what you have to do and for
that reason handle has a concept of the so-called as my mouse mouse
of a so-called default rule you can see it here the default rule describes
an authorization and authentication pipeline which is executed always when there's no rule at all
in addition it defines kind of a template so it means all other rules if the default rule is present
inherent the behavior of it and only those things which are different can be replaced so in that case
the default rule says every request which pass through should be should go through the authentication
or through should be shielded by those indication mechanisms here I have as an IDP I have
cratos from ORI great for that guys if you see that and at the end I create just a job and if something
goes wrong there's an error pipeline that kicks in and you can provide your conditionals when it should
be executed when should you do and you see just a reference on to something so what are those
references so we have steps here and this steps usually if you don't have specific configuration requirements
they just reference what I name mechanisms and this what you have you can see here is a mechanism
catalog and you can describe authentication mechanisms you can describe alsoization mechanisms
so you see for example here have a configuration to talk to open policy agent you can
describe your own contextualization mechanisms or the systems we should communicate to and
and so on and the end the rule can be as simple as that and given that think here I'm able to
reduce the amount of rule to the bare minimum so only those services which have specific requirements
which go beyond the default configuration they need to define their rules and this is what
you can see here so there are a couple of very simple rules like let's me show another one
a more sorry so for example that one so you see I just override the authentication
plan I said I allow our newest requests as well as authenticated requests to be able to provide
different representation I said previously that there's also an option to combine different
authentication protocols and this is what you were able to see shortly here I think no it was here
where I have protocol agnostic identity protocol activation so the endpoint which is matched
by that part here says okay I allow requests being done from the web touch point this is just a
cookie stuff and in addition I allow requests none via a sort party which where jot is active and that's
all and in your code the only thing you have to do is to care about the jot issued here and by the
way the contents of the jot this is what is written here the default configuration it's something
you provide yourself so you control all of that and that means you have a pretty much control
about everything and if you test things you can mock a lot of stuff and in sense of the
security it's there's no way then to bypass it this is what time though that and maybe one last thing
if even I were a stalk or I'm post talking about open adi connect and etc I'm though that's not
implement the driver for the authorization code flow the idea was to reuse what is already there and
we have a young here for example from our two proxy so it's a great project and we can just
plug in that for that particular part and that way we can say that endpoint is for public that
endpoint is for example for the request open adi connect that endpoint requires cookie and
etc etc without we need to manage all of that in our code that's that's all yeah and if you are
interested to see more or as my presentation I did the presentation for CNCF
half a year ago when I applied for CNCF sandbox so you can see the recording in YouTube here
and yeah thank you very much last button at least this is very important for my side the project
is very young so please support it join the community go to get have take a look try it around
there are many demos all over there for Docker for for Kubernetes yeah and the documentation is
very extensive because it's a complex team topic so it's supporting all the part there thank you very
much
so we have like five minutes for questions
so thank you
that's it work yeah so what are their plans for the future because I've been using for
merium for I've been using for merium for a while and they also have a look to or a
hot keeper and what I see from those projects is that they lock more and more features into
the premium slash enterprise side of the tool so are you thinking of making up commercial
product up to this you can think about what sort of and are you thinking of making a commercial
I'm not thinking right now about making a commercial product out of it and to be honest
I don't want to make that functionality somehow private so it should be an open source
completely and that you'll remain that sooner or later of course I would like to earn money with that
but that will be mainly related to support yeah if you like or consulting built around that
so that's the kind idea but the core of how I'm doing what it does should always be open source
and community dream so right now the community is pretty small so I mainly the only one maintainer
and that's also the reason why it's here and say I've said okay cool project we like it but
to let's two few stars to let's two few maintainers work on that come back to that later that's where
I'm also here any other questions sorry there are many demonstrations but not that one
shown here they are demo set ups which are much smaller but that demo which has yeah just give
you all the the complete demo is available online on the SNCF Tech Network YouTube channel
okay no more questions good thank you very much