Keeping your application secure by evolving allows two-point-over and open-minded connect.
Welcome to this talk here. First time having to be here, I'm one of the kick-lock maintainers.
There are about ten kick-lock maintainers at the moment.
Yeah, let's give it a start. So it's all about this epic quest of single sign-on.
I'm a little bit more than single sign-off, of course.
You want to share your identity and delegate resource access to select services.
So that's the high level goal we want to do.
We want to do that, of course.
Security. We want to keep our credentials secure, so we don't.
We share them eventually our credentials within identity provider, but not with the applications.
And we want to let applications operate on our data when they're permitted.
So all the internet is about APIs and we want to then have applications,
interact on APIs on all behalf when and if we want that.
So that's very high level of direction, and where do we come from?
So we come from, well, a sum of two-point-over, that's XML, that's 2005.
And it worked very well for single sign-on, so you can authenticate to an application,
and they know it's you and we have assertions on all that.
But then we looked for great alternatives that were not XML to do like posting funny pictures
on social media.
So they came up with OS 2.0, our OS 1.0 was then considered two complex two post pictures on social media.
And then OS 2.0 was just the right complexity, just the right security to post those funny memes and reply on things.
And open-mindy connect came eventually because we also want to do like a little bit of identity to it,
and that's like more than 10 years ago.
That's the past.
We made some decisions, and then we found out, well, something that's good to post a picture on Twitter is not good enough to do actually banking with it.
So people set down, and then in 2021 they came up with FarPie 1.0, that's like the basis of open banking.
So in a lot of countries you can know you've open banking, your banks still have your account,
and do the proper money stuff with it, but thinnups can connect your accounts, and to have better account management,
analyze your transactions, all these things.
And by the way, all these lights are already uploaded, so they are linked from the first time talk page in the PDF,
and you can also click the links in whatever you're on there.
So that was 2021, and it was so popular that they now evolved it.
And in the last year they had the best current practice of all of 2.0 as an RFC published.
So I think that's a very, very humble title, best current practice.
And also FarPie 2.0 was published last year, and so FarPie 1.0 was posted on the great marketing success I have to say,
when it comes to the name FarPie, and then they still call it FarPie 2.0, the F4 financial originally,
but then the F also for the F in e-health and the F in public e-government services.
And of course, it's going to be better, even better this year, like the very latest old house 2.1,
about to be published this year, that's already a draft, and but it will not be so much different from FarPie 2.0.
I would say, and the current best practice. So what I'm doing today is mostly focusing on FarPie 2.0,
but the concepts will apply to over 2.1 as well.
And what the FarPie people really did well, at least well, especially in the 2.0 world here, they wrote down their security assumption.
Like, what are we assuming, then, is secure, what does not secure, and how do attackers work in that space of almighty connectivity,
all the infrastructure that powers our application today?
And they came up with some attacker personas, and then what is assumed to be secure, and what can be compromised?
And they assume, well, TLS is safe, except when there's maybe a house leader something,
but they assume it's secure, and we will have more details when you are safe to assume it's here as a secure.
All this sharing of public keys is also assumed to be secure.
I mean, do it in the right way, just trade WPS for almighty connect, and browse in the end points are assumed to be reasonably secure.
And finally, identities and certain management, at least in the scope of FarPie 2.0 are also considered secure.
So, what that means, for example, FarPie doesn't care about stolen passwords.
It doesn't care about stolen cookies, so much when it comes to maybe a session cookie for an IDP.
That's a different topic, it's more considered out of scope, and hopefully handled it well by your respective IDP,
and that the identities may be used wrong authentication, that's also not part of FarPie.
But that leaves a lot of things to do to do really secure almighty connect.
So, the attacker models they have in FarPie 2.0, they also listed a number, let's have a show look at that.
So, we have web attackers, the web attackers can call basically any year I, or they make the users tick on links,
but they can't break encryption, they can't break TLS, so that's this attacker type number one.
A attacker type number two, they will spy on the network, but they can't break TLS encryption,
so that's very good TLS encryption comes into play as well.
Some people might be maybe browser plugins or so, might even spy on what's happening in the browser URL,
so they could look at this authorization request in the browser, and so they are not.
Some attackers might have access to those, so you might want to protect against this kind of attacks.
And one of those, whatever was thinking like what the heck, but well, there might be a attacker to read the proxy lock,
so the resource owner, request blocks, but they can't read the sponsors.
So, imagine that attacker is on a network, reading your incoming HTTP request,
but not being able to read the outgoing HTTP request.
So, it's strange, but that's actually a web application firewall, like it might receive all the traffic analysed,
and you might then design your protocols to be secure enough to be intercepted by a web application firewall.
And yeah, with these attackers and these other things to be assumed secure, you can then dive into securing a transport player.
That's the basis of, I'd say, everything on the internet, and what Farbie then really rides down,
and if you're securing your infrastructure at home, if you're securing the infrastructure at your companies,
well, they ride down, you should use TLS 1.2, or better, right?
That's, I think, common sense, hopefully.
Also, to a certificate stack, you should do an stack.
So, people don't get directed to the wrong DNS in some places.
You should use only security LSI for this, meaning the bottom line might be everything that supports perfect for the privacy.
So, whenever a good client or browser comes to a server for the first time, the server will tell the browser,
I'm using TLS, I'm using TLS all the time, and when you come back, please ensure that they're using TLS as well,
even if somebody's trying to redirect it to an HTTP only page.
So, that's the basic stuff, it's common sense, but,
and then the company environment is always good to have it on paper somewhere, to put this common sense to a checklist and to have people actually implemented.
So, that part of Farbie 2.0, and the next thing is, then, how to really, for example, secure this allowed to authorization code flow.
That's been around for more than 10 years, I've seen in a very first slide,
and, like a very, very short refresher on that, where things might go wrong in this way.
So, we are redirecting people to the IDP to also authorization endpoint,
and then you have, like, URL parameters.
The redirect to the line, the login prompt might not be so sensitive,
but you might put in the scope that you're asking for to the authorization level.
So, people should not be able to read that so much, so you want to protect that one.
When you then get back to the code from the IDP, you want to protect it as well,
because, again, in a URL, it's been redirected, and people should not read that and, and visit.
When you then post the code to the code, to the IDP, the IDP really wants to make sure that this code that's being posted is really belonging to this user,
and to the client, and not to anybody else.
And when you refreshing token, it's almost the same.
You're sending refresh token and getting back new tokens, new access token,
and you want to make sure that this token that's being received is only being used by the client,
and the user, nobody else.
And when you call API endpoint, you send usually a viewer token, and this viewer token,
can be, if you use it in this way, being exchanged with any other request,
can be probably used with other APIs as well, and you don't want that.
So with all these things that you don't want, so let's see what Farpy can do about that,
or the standards that were incorporated into Farpy.
And the best practices around that, as well, use TLS for all endpoints.
If you're not using TLS for all your endpoints, you like to redirect, then you're probably in the bad place.
This resource on the password grant, it's been deprecated and not recommended.
It's not part of Farpy 2.0, and if you go to the OS 2.1, it's actually forbidden to use it anymore.
So no resource on the password grant has been around for a time, but for the secure stuff, you don't really want to use it.
You'd want to have no wildcars near redirect, you don't want to have, you always want to have a private key,
you don't want to create a JWT, you don't want to have public lines.
You don't want to have this, I'd say, using a password kind of secrets for your clients,
it's just a string that you send.
So Farpy makes really, really sure that you're doing the good stuff of all of us 2.1.
Some things I would go into more details like, it's now first authorization request,
fixed C and send a constraint tokens.
So this is kind of the, but the other stuff is probably all your clients can hopefully do that,
but these things might be a bit more advanced, and I will have a short example on those.
So first authorization request for the idea of not putting everything in this redirected your eye,
that you're putting in your browser and redirect to your IDP.
So the idea is that you add one more extra request.
I must have one, anybody got in the client, send to the IDP request with all the things that they will
usually put in the redirected to the browser and then to the IDP.
But as this is then see, let's encrypt it, it's using the public and private key of the clients.
It's really secure, the IDP controls that it comes from a trusted source.
It will not be visible in a browser, so that's just secure way to send things.
And it will receive an ID, actually it's an your eye in the end, but that's more or less a play token.
And then it in the second step sends, instead of all these requests parameters,
takes this token and put it through the URL and nobody can really make any use of that.
And once that arrives at the IDP, the IDP will know about this information has been passed on instead.
And like this way, the redirected URL that the browser sees is opaque.
It doesn't contain any sensitive information.
It can't be manipulated and it's making it secure.
Then the authorization code, the authorization code, it should not be replayed.
It should not be finished, it should not be used by somebody else and how you can prevent against that.
The client will send a code to challenge at the start of the authorization flow to the browser.
The browser will send that to the IDP and the code flows back to the client.
And in the last step, where we exchange the code with the tokens, we will send a code verifier from the client to the IDP.
And this makes, and then the IDP will check that this code that has been generated will only be turned into tokens to that one client that has the proper verifier
and only the client that has the proper verifier is then the right client to receive the token.
So that's fixing.
The other thing is then send a constraint tokens, for example with D-pop.
So the idea is that whenever you present an access code as a client, you make sure that you are the client that actually was granted this access token.
And you do that within the femoral key pair, that's the client venerates.
So when you do a public client, both public clients and authority, but it works also with public clients.
I showed that there are last years for them.
This authorization code flow can use work by the wastixi or T-pop.
And then in the very, all this communication is done between the client and the IDP using already this property elasticity.
But once the client calls any of the APIs, it will use this.
An authorization had a wast-pop and some additional information that binds that access code to another thing that.
That's all that the signature that the client is posting together with the access token to the API.
Let's see that as an example.
So the thing is whenever an API received something, the HTTP method, the URI, the D-pop proof, the access token, and non-s.
They only to the line, otherwise something is wrong.
So you calling this API with an authorization D-pop, and access token plus the D-pop proof,
which basically encapsulate an e-credigratic way, this method, and the URI is being called.
Whenever somebody tries to use it on a different API, if somebody tries to use it on a different API, if somebody tries to use it on a different UI,
or method, then it will just fail because this proof will not fit any more.
Then it sends it to the server.
The server might say, I accept it immediately or it sends back a non-s.
It runs like a one-time use token, and then the client should try again, with a new D-pop proof here,
with that non-s, and then finally the API responds with OK.
A lot of overhead, but then hopefully to make it secure when work with application files,
and then like a stone token can no longer be used to do anything else, but this exact API call because it's bound.
So, well, I'm a kick-up maintainer, so all of that has not been able to kick-up so far,
but then kick-up is more than the 10 years old, but it's been evolving to include all these standards,
and there are at the moment opt-in, so we can use them, but or not use them.
We have now, it's open source, 100% open source.
It has, well, these 3,000 kit-up stores, which is very nice.
And we support a lot of standards, but including this Fabi 2.0 security profile,
and also the ORS 2.1 authorization framework draft.
And how does kick-up help you with that?
I'm sure you demo how you can enforce the Fabi 2.0 security profile with kick-up,
so that you can level up within your organizations.
So, these are the screenshots, it takes the demo goes wrong.
So, what you can do, there are something called client policies.
In kick-lough, so there are different profiles, a lot of Fabi and others,
or two woodborne, but I can have a policy here.
Fabi 1 baseline, CBA, Fabi 2 security profile, so I can select from different policies,
and what I then did. I set up a policy called all secure Fabi 2.0 clients,
so I want to apply this policy to all the applications that are now certified to be secure
and capable enough to do Fabi 2.0 properly.
I assign this client profile to it here, and I assign it,
like all the clients that have a specific client role secure,
should then be enforcing this Fabi 2.0,
and what I can then do, or maybe also look into what Fabi and entails,
one thing that I wanted to show, but I forgot.
Now I'm in policy stereo.
For example, when I used to go in this Fabi security profile,
I see a lot of rules that I can actually switch off,
and I can build my own profiles,
maybe I want to gradually introduce different of these checks into my organization,
so they're like, is it 15 different rules?
I can select from I can actually configure them,
and then level up my organization step by step.
And these rules are applied both when you configure new clients in KeyClock,
and they're applied when actually an authorization happens,
and what I will show you now is then just the configuration part,
and please, well, believe me, that is also working with,
like in the runtime part.
So for example, all the URLs need to be HPPS URLs,
otherwise it will not work.
So if then somebody tries to reconfigure the client,
and it minerals the important S from the HTTP,
it will just bail out and say, you can't do that anymore,
because this is consecutive secure client using Fabi 2.0 properly.
Also, if then somebody tries to do some other credentials,
so this is using a giant JWT,
but if I wanted to put it to client ID and secret and say,
but it would then warn me, yes, you want to do it,
but I'll actually it can't be safe,
because that's not proper Fabi 2.0.
So this gives you a great way to enforce these policies
in your organization to make them secure.
So back to this slide, so, so this is what we've seen.
Some of these settings can also be configured on a client level.
For example, you can require TXC on a client,
by just configuring that single client,
but client policies really give you a way
to ensure something across all clients,
or a group of clients,
and there are also more fine grains
and looking into the different,
but also in the configuration part,
but that's a runtime part.
So, all's 2.0.
That's a draft at the moment,
well, it's done probably the,
it's very similar to Fabi 2.0,
but at least no wild card redirects,
also no URL fragments are allowed,
no local house and loopback addresses.
You must take C, no implicit grants,
no resources on a password grant,
so it sounds very similar,
maybe some dell in the detail,
but again, you can use our security profiles
to pick those 2.1 draft as well.
I assume it's going to be arriving sometime this year.
So the question is then,
how to evolve your overall setup in your company,
so it can be like you can pick a security feature
and roll it out to your developers,
you can try to educate your developers
and say, please implement it,
put it on your roadmap
and repeat it for the next thing,
and you always think security is a journey,
but not so happy one,
if you actually want to reinforce it
and it's going to be a bit boring for you.
The other way to do it is,
have you ever heard of brownouts
to speed up to process?
So Wikipedia defines it as a deliberate,
introduction of temporary altitudes to the system,
API of feature that is being faced out.
Sounds like a gimmick.
So what do you do?
If you go to the developers,
explain that the butter best practices are,
then let your IDP enforce it on Monday,
between 9 and 10.
And then set it that then to enforce it permanently.
So people will get a bit upset,
will call the developers and say,
why is my app not working?
And then they will find the figure out why it's not.
So writing emails is only so,
it gets you only so much along the way.
So it's security with a whip,
I would call it,
and you might get some angry developers
but when you have some backing from your security people,
then it's probably a good thing.
Alright, so I'd say,
keeping your application secure is about leveling up,
leveling up your clients,
your IDPs and APIs,
and forcing security policies
and keep your organization aligned with them.
And your IDP,
if you're using Kickstarter,
gives you some great tools to do that.
And if you're successful with that,
and they'll share your successes
and also lessons to learn with the community
because all the yours should get better at all this.
These are the links, including the slides.
We also have some case studies on,
not only about this,
but general case studies on the web page.
Here's the talk from last year,
I'm sorry,
I put the wrong date in here,
but the one where Takashi,
from Hitachi,
and me representing D-pop,
and the security dev room,
Takashi is also the one who put a lot of work
in this far-peas specification
together with the open-mediconic working group,
said it was doing a great job there.
So thank you very much.
That's it.
So we have three minutes,
maybe two questions,
and then let's see how this goes.
One.
Yep, this is a quick remark.
Thank you very much.
Regarding the error messages you have.
Yeah.
Give a good context,
point to the RFC,
point to the documentation
why this is invalid.
Yes.
This is complicated stuff.
Yeah.
So the hint from the audience,
the error messages that we're giving are correct,
but not helpful.
And yes,
we're working on that.
I'm talking to some of those.
Actually, it's an open-source project,
and if somebody is wanting to help with that,
I'm happy to approve and review that pull request on that.
Actually,
I'm a maintainer.
Well, I do a pull request.
I have to look for somebody else to do the review.
If you do the pull request,
I can do the review and merge it.
So that's a lot more helpful for me.
Thank you.
But good question.
It's too far, very quick.
Can you see any cases where?
Because obviously,
I have to remember this.
You put the,
you know,
the,
the error messages to test.
Hey,
do you see any scenario where that would be required?
And so like,
you know,
how do you,
how do you take that out?
Just another one.
Yes.
Questions?
Is the one point to recommendation on enforcement?
Um,
So about the usurice.
Well,
some people like to have usurice when you do
staving between tenants,
and,
well,
but I do want to use usurice quite in the year olds.
One,
you do tenants.
If you only do one estate in between environments.
Yeah,
but that's proven that it's error prone,
and people who have been finding new posts,
because people when they're not using this while can't
correctly.
So that's why they're insecure.
That's why you need to not use them,
and then you need to reconfigure your roles
to each staging environment in a proper way.
So that's, to say.
And the second question I forgot.
The second question I forgot.
The second question is,
is it enforced to recommend?
Uh,
Well,
the,
TLS point 1.2 or better.
Is that enforced or recommended?
Um,
the,
and maybe you want to do some TLS scanning.
And uh,
uh,
you're environment as well,
so ensure that.
Uh,
maybe we can have some more enforcers on that.
So we're doing about maybe we can talk about that.
How we can enforce it on the kick or clearable.
That you can also like,
or the connection that kick look.
Well,
you can enforce it on kick look.
That we don't accept anything that's worse.
Um,
And we might not enforce it when we call out to others services,
I'm going to be outside for my whole session.