 All right, I think it's all set. So hello everyone. This is the next session of the managed two ones and I'll be covering smart card authentication. So smart card authentication is shipping in GitLab 11.6 and I can give a short demo. So with 11.6, if you enable the smart card, the authentication, this is how the login screen will look like. There will be a new tab for smart card, saying that login with smart card. And when you hit that button, then it will actually log into GitLab. So now it looks like that we just added a button that lets people login without authentication, but that is actually not the case. So I will elaborate with that presentation. So what is a smart card? Why it's smart? So basically smart cards are everywhere. They are in your phone as the SIM card and also your credit cards are also smart cards. So they have a built-in processor. And secure storage. And secure storage is obviously needed if you are going to store certificates on them. And because I mentioned they had a microprocessor, they are programmable. They have an embedded operating system. The most common ones are dotnet based and but there are also other ones that are Java based operating systems and custom ones. And so as they are programmable, they provide a way for certificates storage and to access those certificates and the additional features. So some smart cards, you can have automatic creation which really helps. But that's what we are most interested in. So if you want to test the smart card login, and you are thinking about acquiring a smart card, so as you might already guessed, it's mostly a business to business market. So I actually had a hard time finding where I can order a smart card which I find it was able but then the second problem is that so most of these smart card solutions, you need to download a proprietary driver which might not be available on the manufacturer. So I think we lost you and I'm hearing Martin. Can you hear me or is there something with my sound? Yeah, we can hear you now. We lost you there for a minute. We thought about the client that you need for server credentials. Great, okay, thanks. So and also if you go and find a search for the internet how to use a smart card, then many website field, for example, I think how to download, for example, certificates for DoD which might already be outdated and you will not be able to download it. So what worked for me is a UB key because it also supports and has a smart card capabilities and it was pretty easy for me to set it up and start using. So I use for the whole time a UB key to develop and test this feature. So the workflow, so the question is how we get the client certificate from the smart card to GitLab and we can split that workflow into two. So we can have the smart card reader to the browser that's one half of it and the second half is from the browser to GitLab. And we make this distinction because the first part, it doesn't require anything from our side, from GitLab side. It's purely the responsibility for the user or the system administrator, it's system administrator of the user to set up the operating system correctly. So set up the driver and the middle over for the smart card reader and also configure the browser. But the second part from the browser to GitLab, we want to configure the web server and we want to verify the client certificate. So as I mentioned, the first part, getting the certificate from the reader to the browser. So this is how a smart card reader looks. It connects to your laptop or computer via USB and you can put the smart card in and it will read the certificate. And you also need the middle over which needs to be installed on your machine. One middle over, I use this OpenSC and as you can guess from the name, it's an open source solution and it supports multiple smart cards. It's basically, it provides an API for a bunch of smart cards, not all of them because most of them are proprietary, but the most one might be supported by OpenSC as for example, the UB key. There are multiple APIs, but the one we are interested in is actually in OpenSC for UB key and you need to configure the browser to work with the middle over. So here's how I configure the Firefox. There's actually in the privacy and security settings, there's the security part and I highlighted the security devices. Actually both buttons are important for us, view certificates and the security devices. So if you click on the security devices, you will need to add the OpenSC as a security device. So here I just grew installed OpenSC and provided the path to the pkcs11.so file which is the API we need. And you can see on my computer that my UB key is working via the OpenSC middle over. So you might not be, if you don't have a UB key, you might still be able to use the smart card authentication in the browser. I haven't tested it, but if you import the certificate in Firefox, it might be available to select it when the client-side certificate pops up. So here it's actually not an imported certificate, it's the one my Firefox can see on the UB key. Oh, by the way, if you have any question, just ask in the group chat or just stop me and ask the question. So that was the first part, how we need to make sure our operating system and our browser works with our smart card readers. And the second part is getting the certificate from the browser to GitLab. So first we need to configure the web server since only bus is using Nginx. I will be mostly talking about it. So this is how you require the client-side certificate in the Nginx config. You basically just set the root certificate and there's SSL Verify client, which has three options, on, off, or optional. We don't, we always have the client-side certificate. If you have, if you set it to optional, the little window still pops up for the user to select the certificate or unlock the certificate. But if they want to use a different authentication method, it might be really annoying to like always having that screen. Here I just put the configuration, how you need to set up the server certificate when you want to use HTTPS versus the client certificate. So the top one is how you set up HTTPS for example.com. And the bottom one is how you use the clients, how you request the client certificate from the browser. And since I mentioned that Nginx needs to require the client-side certificate, it needs to run on a different board. So with, for example, with Apache HTTPS, we can, so it can renegotiate SSL for the server and we can define different clients' side certificate rule for different directories. But Nginx unfortunately doesn't support SSL renegotiation. So what we've done in Omnibus is running the same server, pretty much the same server on a different board, but this server requires the client-side certificate. And when I hit that button in GitLab to login with Smart Guard, it actually forwarded me to this second port required the client-side certificate and forwarded it back to the original GitLab port. And you also need to set the header to be forwarded to the GitLab application. And this is how you've done it. The first is the name and SSL client escape search is the name of the Nginx variable. Actually, we had a regression related to this recently because we figured that Omnibus only has Nginx version, I think 1.12. But SSL client escape search was introduced in 1.13 or something like that. And previously only SSL client certificate existed, which is now deprecated, but it returns the client certificate in a little bit different format. So we need to make sure that both are supported in GitLab Rails. So this is just putting the pieces together in the Nginx config. This is still just a short example. I deleted most of the actual configuration. We have the server running on a different port. We require the client certificate and we verify against this root certificate and forwarded it forward the client certificate as X SSL client certificate to the Rails application. And finally in GitLab Rails, this is how we do the verification. So in the GitLab configuration, you can have the smart card CA file, which will be loaded to an open SSL certificate store. And basically we just verify against that store the certificate header we are receiving from Nginx. So this is how the pieces fit together. And when you visit gitlabexample.com on the port, which actually requires the client site certificate, this is the pop-up. This unlocks the smart card and lets you then select which certificate you want to use on this site. So I actually have only one certificate on my Ubiqui. So actually the pop-up is only populated with one item. So previously when I showed the example, you didn't see these two windows because I already used and selected this certificate. And I hit the remember this decision. So when I previously used the demonstrated house login with the smart card, these windows didn't show up. So a few words about the certificates itself. So this is an example from Wikipedia. There's a few important details we are interested in in the certificate. So for example, it has a serial number. This is usually if you generate it with open SSL, it will be auto-generated. You can set it manually, but it's much easier because it needs to be unique. There's the issuer, which signs your certificate. There's a few information on the issuer. And the subject is actually details about the holder of the certificate. And as you can see, there's a few field. For example, C is for country. O is the organization, which you can see for both the issuer and the subject as well. And there are other supported fields. Here's a list of them. There's the country, the state organization, organization unit and so on. We are mostly interested in the command name because we are actually deriving the user name in Github from the command name. And there's also another one, the email address which we also use for Github because we occasionally send out emails and we need that in the subject field. So there are different formats, how you can have the certificates. I will now show you an example, which uses the standard. But for example, if you are to import your certificate in Firefox, you might need to convert it to PKCS 11 format, which is a bit different than the standard. And by the way, PKCS stands for public key cryptography standard. So it's a standard which defines how the format should look like for the certificate. And now I will just discuss shortly how you can create a certificate with the UBK. Of course, these steps are also applicable for other devices. If you wanna play with the smart card and also useful because you can see what are the components which are required to create the certificate. So first I will just, this common just creates a private key, the private key will be 248 bit long. And using that private key, this one will generate and self sign a certificate. So here we use the minus key option providing the key which we created in the previous step. And the output of this command is going to be the CA.Pentfile. And you can see that the command is now asked for the different fields I previously mentioned so you can enter the country in the state, the common email address and so on for the certificate. And you can also check the CA file which we have, this is pretty much in the same format but you can now see that the issuer is random corporation. And because it's self sign certificate, the subject is also the random corporation. So this is the one we are going to use to create and sign the certificate for the UBK. And so if you search the internet how to create a keeper for the UBK, you might find the different guides because UBK, the company behind UBK is in the process of refactoring their tooling and most of the documentation still mentions the previous tool. I think it was called UBPIV tool or something like that. But it no longer supports all the features of the newer UBKs. For example, I have a UBK for and I found some incompatibilities which didn't work out with the previous tool but they still haven't migrated all the codes to this new tool and the documentation is still not updated. So you might need to check it twice if you are using the right tool but this is the new tool and YKman and this will create a key and 9A is actually the name of the slot because the UBK have different slots which can hold the keeper and 9A is one of them and we create the private key as a UBK.Pen and then we create the certificate signing request, the CSR also with the YKman command. We set the subject. Here you can see the common name and the email address. We set it there and the output of this will be the UBK.CPSR file which we are going to sign with the root CA we created in the first few steps. So here you can see we provide the minus CA, and the CA key with the CA.key file. We are using OpenSSR to generate the serial for this certificate and that would put via the UBK certificate file. Okay, now we are back. Right, and then pretty much the last step is to import the certificate to your UBK. We are importing it to the same slot, 9A and then you can check the status. Here you can see all the details of the, here's the subject and the issuer, distinguish name and all the details we provided the CN for the subject is heat lab user 01 and the email address is already set and you can see I can, I still, the pin tries left is still three. So for the next steps, so currently the, in GitLab, the smart card integration isn't using an app server, it now uses an internal smart card identity model in the database, but probably most important is the, is the ad-app integration because most folks wanna use it with the ad-app and this is going to be the next step for us to add an ad-app support. So user no longer uses the local DB but can check the certificate in the ad-app server and the other step is certificate extensions because previously what you've seen is we were just using the, the distinguish name, the subject, the common name and email address on the certificate but there might be other tools, for example the subject alternative name extension, which can be, which provide the finer details to what the username and email could be for the user. So these are the plans and yeah, I can see there's a few questions in the group chat. So can I come be created on first login with smart card? So yeah, so actually now if you, if you try to sign in with a smart card which you haven't used previously, it will automatically create a new user for that login. So a new user will be created and then it will be saved as a smart card identity. And next time when you will try to login with the user, that user will be found and logged in again. And the second question, NGINX config made it sound like the client certificates need to be valid. Yes, yes, that's right. The client certificate need to be valid. Otherwise the NGINX will throw an error. Right, so is this integration? I think this is my last slide. So for you. I had to go ahead. Is this intended for primarily for like on-premise customers? Cause it seems like if you were had it on like gitlab.com, there could be things where someone somehow gets a valid certificate with an email address of someone else or something like that. Like is the plan to be mostly on-premise customers? Yes, yes, this is only for on-premise customers. Otherwise like every company needs to like import their own CA file to gitlab, which we don't really want. So yeah, this is only for on-premise customers. It's bringing back, I worked in the DOD back in the day and it's bringing back memories. It was a pain because the support was iffy on some things, but it looks pretty good right now. I like that you did the client certificates first and then you'll move on to the LDAP stuff because that would be a bit big to do both all at once. Yeah, yeah. That was our first thinking because it just seems so, such a huge work and we just split into, I think there are even like three different iterations and this is basically the first one, but now it's shipping goes, so with Omnibus support in London.16 in five days. Cool. So when, I haven't read the documentation, so is it a thing that you have to do in the config file or can you do it in the UI and it'll start up the secondary Nginx? No, you need to do it in the config file. Oh, okay. Yeah, because Omnibus needs to also configure the Nginx, so this is why it's not possible. We don't need using the admin area. I'm trying to think of other questions. I'm sure we still have 30 minutes. Does it work like the email address? Is that fairly standard in terms of like you used a format that's widely used across smart cards? Like, will it work with the... Yeah, so actually... Go ahead. Yeah, so there's actually two different formats one is appending it to the common name and also as a separate field. We actually support both. Oh, okay. But probably it will be better when we add the subject alternative name extension because I think there's also option to like, that might be even more standard solution to define the email address for the user with that extension. But now we support both of the format that is applicable to the subject field. Does it support the common access card now, the DoD one? I don't know. I don't remember where the email address was on those. Yeah, I don't know. So that was one of the issue. I couldn't get a hold of a real smart card. Yeah. So it was really hard to test. I needed to figure out my own how to create a certificate and use it with my Viki. But actually, this is the one thing I'm hoping, getting back from customers to get feedback on the feature because I wasn't sure what extensions are used and how, so it will be very, very helpful to get back some feedback on this feature because I can imagine there's like many different ways. But yeah, I actually am not sure about the DoD one because I don't have a card. I can imagine it's a big requirement for them that they would be one of the groups pushing for it because I just remember like, that's what they were doing with basically everything. If it didn't support smart card, it had too soon, so. But it looks like it looks like a good work so far. And I like that you're using the client certificates because then you have that mutual authentication for the encrypted tunnel as well. So it actually, if I saw it correctly, it actually authenticates to engine X and to Rails. It verifies it twice. Okay. Yes, yes, yes. Yeah, so first, we actually use to only authenticate in engine X and like just forward the end result to GitLab Rails, but as we figured out that might not be the most secure solution because one can just forward the header to GitLab Rails itself without engine X and that could still authenticate the user which we don't want. So we added the verification to the Rails side as well. Anyway, if there's no further question, let me just quickly check back the Zoom chat. Right, so I'm not seeing any more questions, but if you have, or we have one, you can reach us on the g underscore manage channel and feel free to ask questions anytime regarding the smart card authentication. Excellent, thank you very much for the presentation. Yeah, thanks everyone attending. All right, see you, see you then. See ya.