このプレゼンテーションは、2パーツの一部のウェヴォースサポート40グロークタカシノリマツ、最後の一部は、ウェヴォースサポート10000センチです。そしてプレゼンテーションです。今日は、一部のウェヴォースサポート10000センチを見ることができます。この一部の一部の一部の一部を紹介します。まず、一部の一部の一部のプレゼンテーションは、ウェヴォースサポート40グロークです。では、私の一部を紹介します。私はタカシノリマツ、オーエッセスソデューションセンター、Hitachi Limited Japanです。IBA、Nijiniのサポートサービスをお伝えします。そして、私たちのフューチェースをお伝えします。そして、私たちのBuff Fixesをお伝えします。今、ウェヴォースサポート10000センチをお伝えします。今日のテーマは、私たちのファイナンシャルグレイドAPIセンチプロファート40グロークをお伝えします。次に、キーグロークは、アクセスマネジメントオープンソースソフトウェアです。そして、このコミュニティーは、レッドハウトで行われます。今日は、ファースハフトをお伝えします。まず、私たちは、私たちは、私たちは、私将のコミュニティーをお伝えします。続いて、私たちは、ウェヴォースサポート10000センチのオープンソースソフトウェアです。つまり、私たちは、このテーマは最初のテーブルシーンのコミュニティーのセンチです。そして、それが、私たちのファースハフトをお伝えします。それを、私たちのファースソフトウェアからお伝えします。今、ウェヴォースサポート10号のウェブアースンはセンメトリッククリプトグラフィーを使うウェベースオーセンスケーションサンダードル。このウェブアースンはファイルアライアンスフォーマリーで、このウェブアースンはファスワードレス・マルティファクターオーセンスケーションを使うウェブアースンを使うファスワードレス・マルティファクターオーセンスケーションを使うウェブアースンはファスワードレス・マルティファクターオーセンスケーションを使うこのウェブアースンはセンメトリッククリプトグラフィーで、つまり、オーセンスティーティーを使用するために、例えば、スマートデバイスのUVT、セキュリティー、ウェブ・オーセンスティーティーを使用するために、IDP、T-CLOCK、ウェブ・オーセン、レライン・パーティーを使用するために、このウェブ・オーセンスティーティーは2つのオペレーションを使用するために、レジスレーションとオーセンスティーションを使用するために、まず、このレジスレーションオペレーションを使用するために、ウェブ・オーセン・レライン・パーティー、T-CLOCK、パブリック・T、ウェブ・オーセンスティーティーを使用するために、このパブリック・Tを使用するために、ウェブ・オーセンスティーティーのオペレーションを使用するために、ウェブ・オーセンスティーティーのオペレーションを使用するために、このパブリック・Tを使用するために、オーセンスティーティーのオペレーションを使用するために、このレジスレーションオペレーションを使用するために、ウェブ・オーセンスティーティーのオペレーションを使用するために、その後、その後、メーバーのオーセンステータをオーセンステータで同じオーセンステータをオーセンスしています。そして、キーペアのオーセンステータで使用することを行います。そして、このメッセージが使用されているメッセージは、アクテステータのリスポンスを使用することです。それを最初に確認して、オーセンステータのview 対応のドライブ、ピンクと同様にフレーのは和装に行きます。このメーバーのオーセンステータです。同様のブログのドアをオーセンスしています。そしてシンプル取り所やピンクをオーセン節ストランチサーです。このオーゼンスケータを使用する場合は、このオーゼンスケータのプライベートキーを使用して、ティカログを取り出して、そこで、このアテステーションのリスポンスができます。WebOSN RPA-like key-cloak can verify this response by using these authentic status, the vendor certificate and public key and can confirm that this attestation response has been generated by legitimate WebOSN authenticator, not tampered authenticator and not cloned authenticator.WebOSN RPA-like key-cloak can confirm that this response has not been modified and tampered, therefore WebOSN RPA-like key-cloak can trust the contents of this attestation response, namely, for example, the generated user's public key.WebOSN RPA-like key-cloak bind this user's public key and close in this attestation response with the user's ID.Then it is the registration operation.Then the other operation, the authentication operation is that WebOSN RPA-like key-cloak verifies the assertion stating that the user was authenticated by WebOSN authenticator, like your smart device,by using the user's public key that has already been registered on the registration operation I described just earlier.Then WebOSN Authenticator authenticates this user and generates the message, assertion response in order to convey the authenticated user's information.So for example, the user's ID and so user's public key ID and so on onto this assertion response and append the signature by using this authenticated user's private key and send it to WebOSN RPA-like key-cloak.Therefore, WebOSN RPA-like key-cloak can verify this assertion response by using the user's public key and can confirm that this response has not been modified and turned on so that WebOSN RPA can trust the contents of this assertion response.And can confirm that it was authenticated by this WebOSN authenticator, namely the user bound with this public key.This slide shows the multi-factor authentication by WebOSN.At first, WebOSN RPA-like key-cloak that authenticates the user by first factor, like password.Then after that, WebOSN Authenticator also authenticates the same user, but however by using the second factor, like biotrics.This slide shows the passwordless authentication.Then WebOSN RPA-like key-cloak asks the user for the username to find the user's ID.That's all.And after that, WebOSN Authenticator authenticates the user by using the first factor.So, for example, the biotrics, but not using password-based authentication.To the extrude case, the ID and passwordless authentication.Then WebOSN RPA-cloak asks the user nothing.Then WebOSN Authenticator actually authenticates this user by using the first factor, like biometrics.Then not using the password-based authentication.So, why this ID and passwordless authentication can be realized by WebOSN is that.So, kind of WebOSN Authenticator has the capability of managing and retaining that you authenticate users' credentials and information.For example, the user's privacy, user's publicity, user's ID and so on.By itself, securely, this capability is called resident key capability.So, WebOSN Authenticator without this capability cannot realize this ID and passwordless authentication.But, however, can realize both passwordless authentication and multi-factor authentication.I've just explained earlier.So, I've explained what WebOSN and two basic cooperation, registration and authentication.Then, here, I'd like to talk a little about my contribution to keycloak, but WebOSN support.Someday, I've thought that I wanted to use the keycloak feature, WebOSN feature by using the keycloak, but yet not implemented.Therefore, I've done along with such kind of plan.The final goal is to get the certificate, sorry, to pass the performance test provided by the FIEDOR liars.In order to publish and confirm that the keycloak actually operates in compliance with the WebOSN specification.Today, I'd like to pick up one of the pages along with this my plan, writing the design document.In keycloak community, before implementing the major feature like WebOSN support, we need to write the design document and discuss it with the keycloak community.So, when I wrote this design document about WebOSN support, there were a lot of things need to be considered.But today, I'd like to pick up one of them.In my opinion, the most important point of supporting the WebOSN is to verify attestation statement and authentication assertion correctly.This attestation statement is a message returned from WebOSN Authenticator on registration operation, while authentication assertion is the response returned from WebOSN Authenticator on authentication operation.So, of course, the WebOSN specification describes in detail this verification procedure.However, it is long and complicated, so time consuming and dangerous for me to implement all of them by myself securely from scratch.Therefore, fortunately, there is WebOSN specialist in Japan.He has been developing his own Java library, WebOS4j, to conduct this complicated verification procedure.He has been also developing his own server using this WebOS4j library and also has already passed kind of the conformance test provided by the file alliance.Therefore, I've decided to use this WebOS4j library to conduct this verification procedure. Currently, I've also joined this WebOS4j community and done some kind of the contribution that might be also beneficial for the WebOSN support key clock.Here is the current status about WebOSN support on key clock.The basic WebOSN support has been merged and released from the key clock 8.It covers the basic two operations I've just mentioned here, the registration and authentication.As for the registration, the key clock covers all kinds of settings to the Web APIs and the authentication statement verification.As for the authentication, the key clock covers two types of authentication, 2FA and password association.This is the items that I wanted to use in the future.3 items.At first, the account recovery.So, for example, considering that the user loses their own WebOSN authenticator, namely the smart devices, this user never login.Therefore, today around this situation, we need some kind of the account recovery mechanism for the WebOSN authenticator.The file alliance has already discussed this matter and published the short white paper there.But, however, as far as I know, there is no kind of the specification, official specification about account recovery for WebOSN authenticator.The next is on registration operation, the acceptance control based on various kind of criteria.So, for example, I think that the key clock administrator might want to accept only the WebOSN authenticator that has the capability of fingerprint authentication.They might want to refuse the authenticator that don't have such kind of capability.So, in this case, whether the authenticator is accepted or not is determined based on this authenticator's capability.The other example is that the key clock administrator might want to accept only the WebOSN authenticatorto which no vulnerability is reported.In this case, whether this authenticator is accepted or not is based on authenticator's soundness.So, in order to realize this registration acceptance control based on such kind of criteria,we might use the metadata statement from file alliance metadata services called MDS.By using this MDS service, the key clock administrator can retrieve detailed information about WebOSN authenticator as a form of metadata statement.By using this WebOSN authenticator's AAGUID as a search key, this AAGUID is like the ID that is unique over this WebOSN authenticator's vendors model, not authentic itself.Then, the final item is that when authentication operation, the acceptance control based on the various kind of criteria.So, for example, the key clock administrator might want to accept only the result of the authentication by biometrics factor.So, they might want to refuse the result of the authentication by password-based authentication.In order to realize such kind of the acceptance control based on this criteria, we might use WebOSN extension user verification method extension called UVM.By using this UVM, the key clock administrator can find out which kind of the authentication method was used by WebOSN authenticator.However, it's very useful, but however, this is the extension so that not all the WebOSN authenticators support this UVM feature.Finally, I'd like to pick up another use case about key clock supporting the WebOSN that might be plausible, I think.So, to say shortly, I think it might be appropriate to use the key clock for securing the financial interest to this Web system, providing the financial services to the customer via APIs.Therefore, it requires a high security level.So, to secure such kind of API, there is the standard called financial-grade API security profile called FAPI security profile.This security profile is based on the OS2 and standardized by the OpenID Foundation.That is, the standardization body of the OpenID Connect and is related to the standard about DSHR identity.So, in the real world, in the United Kingdom, the UK OpenPantern security profile is based on this FAPI security profile.This is the flow of the first such kind of the API access, and the FAPI security profile requires the user authentication and the consent. Moreover, it requires the multi-factor authentication in order to prevent the user impersonation.Then, the key clock has already supported the basic WebOSN support and can realize the multi-factor authentication.Moreover, the current key clock has already supported almost all FAPI security profiles.Therefore, I think the key clock is appropriate to use key clock for securing APIs, providing financial services that requires high-level security.So, today, I've explained this WebOSN.It is a promising technology for passwordless and multi-factor authentication.Then, the current key clock has already supported the basic WebOSN.But there are still a lot we can do in the future, I think.Then, finally, I've picked up one-order use case about key clock using authority support in the WebOSN in the real world.Namely, the security in the API, providing financial services, therefore, it requires high-level security.That's all for my talk. Thank you very much for your listening.Thank you very much.Next, WebOSN.I hope I'm ready.Just before I begin, let me thank Takashi Norimatsu and Hitachi Corporation for contributing this to key clock.It was a very nice community effort to put this together.It was not only his work, but we also imported another part of the work from different communities, guys from Switzerland, led by Elisa Dossold,who actually contributed a lot to authentication workflows.That's the part we will see shortly in this demo.I will be mainly sitting down, so I hope you hear me if not shout.So, I will try to show from the clear database of key clock.Only thing I created was the admin user at the beginning.And I will try to walk you through actually how you can start playing with WebOSN.And different stuff, so hopefully you will enjoy it.So, here is my login screen to key clock.And my admin user will kick in.And you see that it's only username and password login.And right now we are in the key clock administration console.By the way, how many of you played a little bit with administration of key clock?Quite a few.Thanks.So, if you want to enable that authentication, first of all, it will be very useful to create user registration capability.So, with this thing in the realm settings.I'm doing all the presentation against master realms.So, I don't have any side application installed or whatever.So, I will always show it on the access to account console.For the purpose of this presentation, it should be fairly enough.So, we have to have a user registration set.Then, on the authentication side menu.And the required action.We should actually add required action, which is the action which will be added to every user from now on.And that thing is WebOSN register.And I will send it like a default for all the users.So, right now, if anybody tries to login, it will actually pop up.And if that credential is not part of the users credentials.It will prompt him to the registration procedure, which Takashi showed on the diagrams.And it will let you register your authenticator.This is part of the thing which I will be doing.Actually, I'll start it.So, let's create the flow.This is the browser flow, which is a default flow for KeyClub.And we can start with creating the copy of browser or I created kind of a template flow for me.So, let's do the copy of the flow, rename it.So, now we have our flow started.And then see that we have a cookie as an alternative.We have a flow of alternative execution.Those actually flow can contain executions or subflows.What this means is like it can give you like for the administrator ability to a little bit tweak the login process.And even extend it if necessary, but not sure if this is like widely supported.So, we have those alternatives at the beginning.So, once you have a cookie, it can be used.You are logging in.Kerberos is currently disabled for obvious reasons, but it could be Kerberos as well.Then we have identity provider redirector, which will redirect us when necessary.Then we have a flow, which is called basic templates flow for now, because I created a template.But after that subflow, we can inside a subflow at execution.And let's take without authenticator execution.That will be one thing, obviously required.But before that, I should add another execution, which will be username and password form.That's the basic thing, which will ask you for username and password.I can put it a little bit up there.So, we have what is needed here.Although the user interface is actually automatically saving all the stuff and it's changed.So, next thing to actually enable this flow is to go to bindings and see if we have a browser flow.Those are different flows for different clients, but for the browser flow,I will change the browser for the both basic, save it, and then we can give it a try.What happens?Let's open the console in incognito window and see we have admin to login.And right now we are in a part that our subflow kicked in.And we see that we can register our authenticator.So, I have my UbiKey.I can touch it.And right now information came to keycloak server.And it asks me to name it.So, it will be UbiKey black and we are logged in.So, how it looks like when we approach this situation again.And try to log in.So, we have set admin as before.And now the credential is already in place in the database.So, we can use the web of authenticator.So, let's do the red and blue one.See, this one is not working.Let's do the proper thing.And we are logged in.This was just pretty straightforward.And I can show you how the user admin looks like right now in terms of credentials.So, see that we have two credentials.One is password.The other is web of credentials, which is like with the user label.UbiKey black.And we can even check the data what is in there.I know that there is still a lot of work on the polishing of all the stuff.But this is a very fresh thing.And actually, it was grabbed directly from the master.So, I compiled our master branch.And this is what is actually latest development.Okay.So, let's call this one.And we can proceed to another thing.I would like to show you a little bit more complicated flow, which will also include OTP.Because it might be useful for admins to have more credentials for users.If something is not working with one out indicator, there is always another one.And it's still fine to have a second factor with anything else.So, let's select my template again.Do another copy.We have what we have from the template.And we can start with adding another part.This one will start with the execution called username password, which is also required.And after that, we can create new flow here.And let's call it conditional to FA.It has to be flow because only flows can be conditional.And conditional means that it actually signalizes to the whole container of the authentication.That behind that will be some kind of executor, which is written through or false, depending on what we would like to have it.And then the whole subflow got executed or not.That was kind of tricky.We adopted it because we were a little bit considering to write small script or something,but then we decided to go completely user interface way.And maybe we will change it later.I don't know.So, let's add the execution,which actually checked if the user has any authenticators configured.And then we can add another execution, which will be both authenticator.This one will be alternative.And then another one, which will be OTP form.OTP form means basically it will get your OTP code and evaluated afterwards.And also alternative.So, our flow is ready.We can go to bindings, make it a reality to FA.Save.And let's see what happens.So, we have our admin, which could log in.And now see that it shows us only the Ubiqui Black because there was no second factor.Second factor is set.So, let's log in.And we are here in the account console.We can modify a little bit what we have here.I will set up my OTP using just Google Authenticator.So, I add account.Enverify code.152.237.And we are in.So, let's see one more.What happens right now?We have two authenticators.So, it should somehow see that Kiklo showed us authenticator in this kind of not very user-friendly way.And we know that this is not going to stay like this and already working on it.Here is a small link, which is try another way.So, if we are not in a position of our Web Authenticator, we can use the other way, what's in there.And right now we can choose from both of them.So, let's say use OTP.It switches to OTP.If user is not really satisfied or made a mistake or something, there is a still thing like restart the form.So, it will go through the beginning of the flow and the user can start again.Oh, I will try to work with OTP, which is 0169.Done.And we are here.So, this was a little bit of a thing, which shows the alternatives.And currently, the alternatives are working on that.We will show all the alternatives from the beginning.And you can choose right away what you would like to have.So, this is kind of a prototype.Let's close this one.And I only have one more thing to show.It's a passwordless, but I don't have a really proper device for passwordless.So, it will be not exactly passwordless, how it should be.So, go another time for a template.I will create a copy.This time it's passwordless.And we can go.So, first time we can add the execution, but this first execution will be in the execution, which will ask us just for username, which is called username form.Require, that's okay.And then, we can create another subflow, which will be called authentication form, for example.Require, as well.And after that, we cannot execute, which will be Web Authenticator.And this should be basically it.Because there might be also, at the end, another flow with, for example, password plus OTP, which will be kind of backup.But I found that there is a little problem, which is not like preventing it from usage.But it doesn't obey the order of the executions.And that will be not very nice for this.So, let's try our passwordless stuff.So, right now, our flow has been, we have a username or email.Because in our login, we said that we can use either username or email address, which is, if that is already registered.So, we go with our admin.Yeah, I see where the problem is.Thank you, Michal.So, another try.Admin.And now, we have our UB key.So, we can use it.As I said, this is not exactly what passwordless means.But we didn't get the password.The passwordless really depends on the Authenticator you have.And all the other settings.I'm not going to tie, but just to show a little bit of the Authentication menu.The thing which Takashi was talking about is the WebAlp policy.And the WebAlp policy is actually here.So, if you guys want to play a little bit, you'll be really glad if you get some reports in our JIRA.What's going on wrong.And I think this is it from our side.And if there are any questions, we will be happy to answer.