Hello everybody, we are very happy to talk today about how to set your SPA in our studio.
We hope to have sure our talk, let me introduce ourselves briefly.
My name is Takashi Nounimatsu from Japan.
The key work maintainer and also working at Hitachi Limited to Japan.
My name is Alexander Schwarz and I am also a key clerk maintainer working for Red Hat.
So today's main topic is about how to set your single page application in our studio.
So in the beginning of this talk, I would like to describe what SPA in our studio is.
So in the youths, like you, this is not the basis and it runs the SPA as all students cry and own browser.
So the first we need to use the existing browser to receive some services.
After that, SPA sends authorization request to authorize and show us by following us to a protocol in the receives authorization code.
After that, SPA sends the token request to authorize your subbar with this authorization code.
And finally, this SPA sends API access request to the SPA and receive its response.
The actual example of SPA in our studio is key crooks account console or unadmin console.
The both uses the key crooks.js. It works as fast party or security and application.
Next, I'd like to introduce two measures that we can list where we encounter if we use SPA in our studio.
The first set we do is misuse over storing authorization code.
So the SPA after SPA receive the authorization code from the authorization server.
If an attacker steal this authorization code, then this attacker can get a valid access token from this authorization server.
However, in return for this stolen authorization code.
So one counter measure to mitigate this risk is client authentication.
When authorizes a subbar receive token request from the SPA from the client application,
then authorizes a subbar to do client authentication against the author's client.
However, the SPA is usually treated as a public client.
In return it means that it's not able to do client authentication because it's not able to, it's not capable of making the confidentiality of credentials.
For example, use for client authentication access authorization server.
So therefore, considering that point, the client authentication as a counter measure agency is not to be effective.
The second security list is misuse of storing access token.
Then after SPA receives an access token from authorizes a subbar.
If the attacker can steal this access token, then this attacker can access the API subbar by using this stolen access token.
Because according to the SPA's application defined by RFC6750, it states that access token is treated as Bella token,
which means that every client who holds this client can use this token.
So, actual example in a real world is train ticket.
Why? There is another type of token called senda consturaning token.
In this case, only specific client application can use this type of desktop token.
So, actual example in a real world is passport.
But there are several ways to realize this senda consturaning token.
There, one of those such ways is to ausmTLS defined by RFC8705.
However, it requires client application to manage seturary x5.9 certificate and its corresponding private key seturary.
But, however, we consider in the point that SPA is treated as public client.
Similarly, the SPA is difficult to seturary for its difficult for SPA to manage seturary.
The x5.9 certificate and its corresponding private key.
So, therefore, the countermeasure therefore, this certificate is as senda consturant token.
It seems not to be effective for SPA in those two.
Then, so next, I would like to introduce the countermeasure for both two major seturaries that may arise in SPA in those two.
It is called DeepOp.
Demonsturating also demonstrate thing proof of possession called DeepOp.
It defined by RFC9449 and it allows us to demonstrate and verify a senda of the message on HTTP is a holder of an asymmetric cryptographic key.
So, therefore, by using this SPA application, we can rewrite the senda consturant token by binding this key with a token in a cryptographic way.
Next, so I would like to describe how to mitigate the risk of misuse of stolen authorization code by applying the DeepOp's optional future DeepOp.
In this case, before SPA sent authorization request to also as a subscriber, SPA need to generate the temporal DeepOp key pair, public key and private key.
And then, SPA needed to calculate hash value of this public key.
It is called the Pope JKT.
And after that, SPA sent authorization request
to the author's server with this deep object key.
Then, where, author's server received this request,
author's server generated an authorization code
and bind this authorization code with the Pope JKT.
So, after that, the SPA, after SPA received this authorization code,
then, before the SPA sent token request to author's server,
the SPA needed to generate the data code deep of proof.
It includes the public key itself.
And SPA needed to generate a signature against this deep of proof
by using this private key and attach this signature to this pop proof.
And finally, this SPA sent token request with authorization code and this deep of proof.
So, therefore, if attacker can steal this authorization code,
this attacker cannot create valid deep of proof,
because it does not hold the SPA's temporal private key.
The next, I would like to describe how to mitigate the risk of misuse
of storing access token by applying the deep of future.
When author's authorization server received token request,
we also associated your code and deep of proof from SPA,
then, the author's server create an authorization access token,
and bind the public key included in to this deep of proof,
with this access token.
Then, after that, SPA after SPA received this access token,
the SPA 22 sent API access request to API server,
but in this case, SPA need to create deep of proof again.
And it also includes the same public key itself,
and SPA need to regenerate the signature against this deep of proof,
and put this signature onto this pop proof.
And SPA finally sent this API access request with access token and deep of proof.
So, when API server received this API access request,
API server can verify the weather a holder of public key
included in this deep of proof is equal to the sender of the API access
request number six, namely the SPA.
Then, after that, the API server can also verify whether the sender of the API request number six
is equal to sender of the token request number four.
Therefore, if an attacker can steal this access token,
then, this attacker cannot create a valid deep of proof.
Then, because the attacker does not hold the private key of the SPA
simpler deep of key pair.
So, next, we would like to do some demonstration to show how it works.
I broke it.
Almost, that's not pointing upwards, but maybe you're used to looking.
So, I want to show you what we've shown on this slide,
all that it works in practice, with already available tools.
So, what I'm bringing here today is JavaScript.
A single page application with view and upon by open my decline,
that's a positive pop. Then, I bring you to a key cloak, which is also a positive pop,
and I bring you to a quarters application with the nimbos,
allows to SDK, which is also a positive pop, and they all talk together,
and I will show that in a demo.
So, let's start with key cloak. I have key cloak here,
I'm planning to refresh the page to make sure that I can really log in.
So, I have a test realm here, I'm not supposed to secure a password anyway,
but then, anyway, I have a client here for the OpenModConnect view,
and I have an advanced tab, and somehow in the advanced tab,
I can search for D-pop and D-pop is enabled.
So, this is something you need to do. You need to set up a client with D-pop enabled.
You also need to start key cloak with the feature preview feature D-pop enabled,
and then you have a working key cloak server that can do P-pop.
I also have the view application that I opened up here,
so it now asks me to log in, I log in with test,
and the very secret password.
And I log in here, and what it does, it's this PANBA OpenModD clients,
talking to the key cloak server, I'm logging in,
setting in an authentication request, I authenticate here,
and you will then see that, okay, so you're probably wanted to,
yeah, I get something back here, so I redirect to key cloak,
come back from key cloak, I get here all the different headers with OpenModD Connect,
and I was with D-pop, I changed the token here,
I send all these D-pop headers that you will see here, for example,
the D-pop header that Takaashi talked about earlier,
it's all sent to key to exchange the token,
I get all the information here set up,
and I'm also already talking to Quarkus here,
so the first request fails, because I'm doing something else here,
that's also doing a non-s, so can make sure that any request
at the single page app sends is executed only once,
it then the first request fails, it sends the server sends back
a non-s to the client, the client resens the request automatically,
that's all part of the Takaashi Quick Library, which is nice, so,
yes, with that all set up, I'm shown that it works,
I have a second demo that also shows that this works with,
with Apache 2, with most outs of my D-Connect,
I'm seeing I'm running a bit out of time here,
thing is, when you do something like this, you can have a browser,
redirecting to Apache 2, and Apache 2 will redirect to KeyCloud,
does all the D-pop magic, and eventually sends the request
after it's been authenticated to the original application,
and in my demo, there's a stand, a PHP application,
so when I log in here, I'm already logged in because it's single-son on it,
will not show me the login page again, but you then see here,
all the open-mighty connect stuff sent back from Apache, as HPP had
to my application running as PHP inside of Apache.
So, you see there already a lot of tools out there that work well together with D-pop,
so that was KeyCloud, that was the numerous SDK, that was the Pandra client,
that was the Apache module there, and it's great that we can finally bind the payload,
and we're sending two to the actual headers and authentication that we're doing there.
Right, when you do an application like this, you will see that more headers are sent back
and files, and you might want to configure your cores in the way that it works,
so that it really does all the additional headers, for example,
something, some pitfall nights here that you really need to make sure that this new header
D-pop and D-pop non-s are really exposed in a right way to make this course work properly.
All right, so yeah, handing them over back to security configurations,
if you're too careful, and we might have soon take the questions.
Yeah, no, okay, minutes or so.
Okay, I see. So, finally, I would like to briefly describe the CTT conservation.
We use the SPNNS2, and we need to apply both counter-measure for the CTT
squandering to misuse of slow-ontortization code and the misuse store-down system.
The E, the counter-measure for risk-one locks, and attacker can receive the
access token by using attacker's own D-pop key pairs. So, therefore, both counter-measure needs it.
And also, we recommend that you apply several counter-measure for the misuse of a slow-ontortization code.
As you may know, the proof T4 code exchange code PICC defined by ROC 7636.
That also can prevent this type, can't mitigate this type of risk.
So, therefore, considering this point, we recommend the following options for counter-measure combination,
upper-end D-pop, JKT, D-pop, or PICC, D-pop, or PICC, D-pop, or PICC, D-pop, JKT, D-pop,
or applied. Then, today's, in our talk, we introduced the briefly SPN announced to
and describe the two major CTT risks, and introduced the counter-measure for such a CTT risk in SPN
announced to call the D-pop. And so, the finally, we described briefly the
CTT concentration, where we used this D-pop in SPN in O2. So, this topic is a little bit complicated.
So, therefore, it took a lot of time to describe here. So, to say what precisely, this slide
will include a lot of information. So, therefore, if you are interested in this topic, please
download this slide and look at this slide afterwards. Okay, thank you very much.
Thank you.
There is time for some brushstrokes. Yes, so, part of the D-pop you do is store the D-pop in Stolen.
Stolen authorizes a store in access to the D-pop.
Why did you translate that in my guess is that the most common way that the D-pop
gets stolen from a broken SPN application is through OSI-15 attacks. And when you have
the OSI-15 attack, the attack is still the priority without any problem. So, is it even possible
to secure SPN's using the world? Okay, so, can you please, the D-PT risk question?
Okay, we should repeat it for the microphone, okay. So, the question is, if the
attacker steals the key material out of the browser, it can do everything and it's not about
stealing it only in transit. Well, stealing in transit, there are sometimes proxies that do
decryption encryption. Yeah, but then stealing in a browser. The examples are shown today,
they use the extensions web crypto. So, this D-pop key pair is generated in the browser
inside the browser, but JavaScript can never extract it. So, we can do the JavaScript application
can do cryptographic operations with the key in the browser, but never catching the key. So, that's
web crypto API. If you find it in access, explore the SPN application, you will not be able to
extract the pen. Yes, that's right. Yeah, I can't extract the key material.
I can, I can maybe, like, I could create tokens, but they would be only valid for that time. I
could, I can't generate them in the future, but only at that very moment. So, that's possible,
but I can't extract the key material and all the data technique to happen in that one browser.
I can't extract the material and do it in another browser or later, or after the user looked out.
So, that's it. That's the advantage that we can do here.
There's a question back there.
Also, one point I would like to mention, this type of keypills, this type of keypills lifetime,
is very short. So, therefore, the attack cards, the time window is very narrow. So, therefore,
it can immediately, this type of risk, I think so.
So, the question was, do we need to state on the authorization server?
Yes. So, yes, in the way, if you're using launches, your resource provider needs to know that
this launch has not yet been sent or generated maybe with a time term in what not.
You will always, as a user, have a session with the authorization server with keyclock into
this example. So, yes, there are sessions involved and state to be held on each of the
parties involved here. So, if the application is renewing that tokens with keyclock,
keyclock will need to check the signatures on the token on the refresh token, it's sending and
the cryptographic things that it's done stuff on. If you receive a token from, if you're the
authorization resource server and receive something from the application, it depends,
maybe the token is just a drop token. So, you can do a cryptographic operations on the access token
or you receive on the D-pop key material or you receive and you can do it 100% locally,
if it's all JSON web token based. If it's opaque token that you can't verify yourself,
you will send your access token to the authorization server for token into spectrum and you will get back
the identity of the D-pop key it has been generated for and then you can use that identity,
this ID of the key that has also been sent by the user to figure out okay, this access token was
valid as such and is it still, is it connected to the proof that this single-paid application
has sent to me and then I'm sure okay, this is fine. But okay, we out of time, so I'm happy to continue
the discussion outside. We are also having some more talks tomorrow about keyclock and the identity
key in access management bedroom and we also be at the CNCF stand here at Boston. See you there.