 Yeah. Hello everybody. Welcome to the next session of the Compendency 2. The next tool is Securing Command Line Application with KeyClone. And it will be presented by Ramakrishna. I would like to just let you know if you have any questions during the talk, you can use the Q&A section in Hopin, here in Hopin. So let me begin. Hi everyone. Thanks a lot for attending the session. And I hope you're all doing well. I'm Ramakrishna Patnaik and I work as a software engineer for Red Hat Bangalore with the Middleware team. And currently I'm tuning in from Bhubaneshwar. Today in this session I'm going to talk on the topic Securing CLI Applications with KeyClone. Command line interfaces aren't talked as much as the web user interfaces. However, the CLIs remain popular among the developer community due to their flexibility and their granular control. We'll discuss about how KeyClone is, how it works, and how we can secure a command line interface using KeyClone. Before we start, I would like to draw your attention towards the where some questions will be we're going to have in the polls. So please remember to cast your vote. We'll go through the results toward the end of the talk. So let's begin. The GitHub page of KeyClone defines it as an open source identity and access management solution. An identity and access management solution defines and manages user identities and access permissions. Other features that sit with identity access management are SSO, which stands for single sign-on and MFA, multi-factor authentication. So single sign-on is what allows users to securely log in to multiple applications that they're authorized to access. And multi-factor authentication sets an additional method of user verification other than the passwords. So this MFA could be anything from a facial ID or even a one-time password that we receive as phone message. So KeyClone can also be referred to as an identity provider. An identity provider or IDP is a service that can authenticate a user. It provides identity management as a service. Some popular identity providers that we encounter on our day-to-day life include Google, GitHub, Facebook, Microsoft, Twitter, etc. The example in this slide is from the login page of Stack Overflow. So to use Stack Overflow, either we can create an account there or we can use it via the different identity providers, which here are Google, GitHub, and Facebook. Now let's discuss about the workflow of an identity provider. The workflow of an identity provider happens in three steps. The first step being the request step. Here the user enters credentials from another login like Google, Twitter, etc. Then comes the verification step. Here the service determines if user has access and to exactly which resources and after verification comes the final step unlocking where user gains access to specified resources. This takes mere seconds and most users don't notice all the hard work that's happening behind the screen. Now let's discuss what are the various advantages of using an identity provider. The first one is improved security. An identity provider is a tried and tested third-party tool to handle the security. There's no doubt about that. Then comes improved user experience as users will only need to sign in once for multiple service providers and won't need to remember different passwords. It is also easier to maintain the service providers as we don't have to maintain account information across the multiple services. Also the auditing and reporting becomes easier for the IT team as they can keep a track of where the credentials are being used and where it got compromised. Now let's discuss what is KeyClok. According to the GitHub page of KeyClok, KeyClok is an open source identity and access management solution for modern applications and services. Users can authenticate with KeyClok rather than individual applications. The applications don't have to deal with login forms, authentic user and storing users. KeyClok is also the upstream project for the Red Hat SSO. Now let's discuss why should one consider using KeyClok. So first of all, KeyClok is a free and open source software. It has a big community support which guarantees that there are a lot of examples of how to do something. And it comes with a web-based graphical user interface which makes configuring easier and it supports social identity providers like Google or Facebook out of the box. So now let's discuss some important terminologies of KeyClok. So first let's start with RL. So RL serves as a management space where one can create users and give them permissions to use applications. RL manages a set of users, credentials, roles and groups. RLms are isolated from one another and can only manage and authenticate the users that they control. A user belongs to and logs into a particular RL. So by default, KeyClok has the master RL. Users will create new RL as masters should be used for the sole purpose of creating and maintaining other realms in the system. Now let's discuss what is a client in KeyClok. So a KeyClok client represents an application or a web service that uses KeyClok to authenticate and authorize the users or they can just request access tokens so that they can securely invoke other services on the network secured by KeyClok. So here is a screenshot of the configuration of a KeyClok client. And yep, I have included a demo of how authentication works with this client configuration. We'll go through these one by one. So this is not the entire configuration of a KeyClok client. It's just a small part of it and probably one of the most important sections. So yeah, to see more of the configurations, you can just use the web GUI of KeyClok. So the first three fields, client ID, name and description, they are pretty much self-explanatory. Then comes the root URL. So the root URL is the index page of the application. And then comes valid redirect URIs. So yeah, they store the patterns for URIs of valid redirection. So suppose we are using a redirect URL in the application, it should match the patterns that we have specified here. And after that, we have the base URL. So base URL is supposed to be used if the authentication server needs to link back to the client. And admin URL is the URL to the admin interface of the client. And you don't really need to worry about all these jargon terms. I know this could be getting a bit overwhelming. Even I don't know most of the stuff here. You can just use the web GUI and hover over the help icon just right next to the field names. And it will give you an explanation of what they are. And this one more field that I would like to talk about is the access type. So unfortunately, it hasn't been captured in the screenshot. And access type defines the type of the OpenID Connect client. And it is of three types, public, confidential and bearer only. So public access type is for client-side clients that need to perform a browser login. And confidential access type is for server-side clients that need to perform a browser login and require a client secret. And finally, we have the bearer only access type, which means that the application only allows a bearer token request and forgoes any kind of browser login. So an example is like we send the access tokens with the request while interacting with the server. Yep, that's where the bearer only type comes in. And for clients such as CLI and websites, the access type should be public. Yeah, so as discussed earlier, Keycloak allows us to use multiple social identity providers. They're configured at the realm level using the admin panel. Each provider needs to be configured with a client ID, client secret, redirect URI and other relevant information. So you can see the drop down in the slide. This is the list of all the social identity providers that come with Keycloak. And suppose you want to add GitHub as an identity provider, you will need to create a new OAuth app from GitHub's developer settings. And from there, you will get the client ID and client secret. So in today's demo, I have used the GitHub identity provider only. So let's discuss how authentication will be handled for the client we have discussed till now. So first, the user will see the Keycloak login page asking for credentials or to sign in via social providers. So it is the first screenshot here. And once the user selects sign in with GitHub, user is redirected to the GitHub login page, which is the second screenshot here. And it says sign into GitHub to continue to Keycloak demo. Keycloak demo is the name of the application I have given in the GitHub settings. So yeah, and user can just sign into the existing GitHub account or create a new one just like we normally do. And after successfully logging into the GitHub account, user is redirected to the authorized application. And the redirect URI will have code as a URL parameter. We'll discuss about it later. And client will use this code to generate tokens against the OpenIDConnect token endpoint. This is the GIF here showing how Keycloak works with websites. So yep, this is a recording of console.redhead.com. While it doesn't exactly use Keycloak, it uses Red Hat SSO. It's downstream, but the flow is pretty much similar. So when we try to navigate to console.redhead.com, we are redirected to the SSO login page. Upon successfully logging in, we are redirected back to console.redhead.com. And if you observe the URL closely, it has some URL parameters for very few moments right after the redirection. So things can get tricky when a command line interface app involves a browser login. The easiest way to us might seem to simply copy paste the authentication token and pass it as an argument with the CLI. This approach can get problematic as credentials will get stored in the terminal's history. In the slide, you can see that it is a screenshot of the Docker command line app. And Docker login command has the ability to receive username and password as flags. So which is not something we should encourage. And an improvement here is the password, STDIN flag, which allows to take password from the standard input. However, the user should authenticate only using the authorizing servers web page. Now let's discuss the correct approach. So first of all, the CLI should build the URL for authorization and open it using the browser. And then an embedded mini HTTP server needs to be run concurrently that will handle the redirection part. And the redirection URI should be registered in the client configuration. And the embedded server should get the code as URL parameter from the from the redirection and use it to make another request to get the authorization codes, close server and transfer the control back to the script. Once we extract the codes, they need to be stored in a configuration file. A preferred location is the is the path xdgconfig home, which for Linux is usually the dot config in home home directory. So I'll be switching the screen to show a short demo of the approach discussed. Let me increase the font size. Yeah, so this is a small command line app that I have built using the Cobra library of Golang. So it is a popular library to build CLIs. Some popular CLIs that have been built on top of Cobra include kubectl, which is the CLI for Kubernetes and also opens if console management. And even the CLI of Istio has been built using Golang's Cobra. So this is a small lightweight CLI app. And I have the key cloak server running in the standalone mode in the terminal. I can show it to you here. Yeah, so there we have it. There are also other distributions of key cloak, like a container image and also an operator. You can check them out. So let's go through some of the important code snippets here. Yeah, the first part is like CLI should build the URL to the authorization server. So here it is. It just involves some transformations of the key cloak client configuration. So once we have that ready, we need to open it using the browser. So this is the method that I'm using to handle it, the open browser method. So these are just different implementations for the different operating system. And once we have the browser open, an embedded server needs to be run concurrently. So we have defined it here. We have achieved concurrency using go routine. So yeah, it just starts when the browser opens. And this is the redirect URL that I have used for this demo. And yep, if you go through the if you go through this handler function, what happens is like first we need to extract the code from the URL. And once we have that, we use the method build token exchange request to make another request to the endpoint of open ID connect token, which gives us the authentication code and I mean, authentication token and refresh token. Sorry, I mean the access token and refresh token. And once we have it, we need to store them somewhere, which as I discussed is a good recommended path is the exchange config home. So let me show you how the exchange config home looks like. Yeah, forgive me for the mass history. Yeah, so activity config home for Linux is this the home, the dot config in the home path. So as you can see, there are some familiar familiar names here like JetPrint, Cypress, Electron. So this is the place where we should store user specific data. Yeah, you can see there are some CLIs as well like Katzpy. For this demo here, I have just named it CKP, which is basically the acronym for Cobra Kiklok POC. So yeah, we have, so in that directory, we have saved the, we will be saving the config.json file. And since I've already run this before, it should be populated already. Let's see how it looks like. Yeah, so the config.json file stores our access token and refresh token. So that's pretty much all there to it. Let's just run the demo once. I'm using the login command to handle the authentication part. Yeah, so it opens up a browser. Yep. I'm selecting GitHub. Yeah, and it has been successful. So I didn't need to manually type in my credentials because I had already logged into GitHub using this browser. And this is the redirection URL that you can see. You can see this is the code. We are, we receive it as an URL parameter and we use this value to get the refresh token and access token. So yeah, that's pretty much all there for this demo. Let me switch back to the slides again. Yeah, so that's pretty much the correct approach of securing the CLIs. I mean, there could be other approaches, but this is the best one that I have been using till now. And to learn more, you can go through this following links. I personally found them very useful while preparing for this talk. And for this demo, I have, for this demo, I have uploaded the code to my GitHub. You can have a look at it to know more. Yeah, so that's pretty much the end of the talk. Now let's go through the poll results. Can you see the poll results or not? Yeah, I can. Okay, okay, let's make that. Okay. Yeah, so the first question was, have you worked with KeyClub before? And we see 57% is no, 28% is yes. And I would like to explore this 14%. So yeah, I was actually expecting a more on the yes side. So yeah, I think KeyClub is an awesome thing, awesome library and tool. And everyone should just have a look at it if they want to secure their applications. And the next question was, if you build a service, what would you prefer as an end user interface? So command line interface got 19% of the votes, website 9.5. And both 68.2. So yeah, I actually didn't expect so much popularity of command line interface over websites. Because CLIs are basically, I mean, the users who are more familiar with CLI are day to day Linux users, they're not very popular in general. So yeah, I think the poll results are a bit surprising, I'll say. So yep. Now let's, I think we can jump to the Q&A section now. Yes, sure. So we have a bunch of questions, I'm not sure whether we can handle all of them. Do you want to pick any of them? Or shall I pick one for you? You can just start with the. Okay, there are two questions with some likes. So I will start with the first one. And the first one is high. What kinds of security analysis did the key clock passed? What, what were the results? What did it failed in? Yeah, so I'm not actually really expert in key clock. I don't, I mean, I don't work on key clock size of stuffs. But yep, I think that it has a pretty good reputation when it comes to security and everything. Yeah, I will have a look. I'm not sure about the exact answer. Okay, thank you. So the next question is, there is no way to bypass the browser then all together. What if you are in the CLI on the machine with the other window manager, or any browser installed? Yeah, I will agree that it's impossible to bypass the browser I mean, it's not impossible. Sorry. Yeah, I mean, it's, I mean, we can't get rid of the practices where we just pass the token as a flag, because obviously there are some environments that don't have a browser. And there I think the only way out is like passing the token as a argument or flag. Yep. Thank you for the answer. The next question is is there any open source CLI app that uses key clock? Yeah, I, yeah, there is one actually, it's the one I work in. It's the CLI for Red Hat OpenSafe application services. I can just give you a link to that CLI. I'm pasting the link in the chat. Okay, thank you. So the next question is, are there any ways to debug what information will client receive from the CLO in case of OpenID and SAML? I want to find out the data and its structure the client will receive so I can configure client. Yeah, I think there is a way to debug, but I've not really explored much in that direction. I need to explore that. Okay, the time ran out. So thank you very much for your presentation. If you want to discuss further discussions, you can move on to the work adventure. It's a great platform, virtual platform where you can have all the fun. So I feel free to go there. Alternatively, you can use also Discord. So thank you very much for your presentation.