 Hello, I'm Chosé Goulot from the company IoT Visitage. I'm here to present to you how we leveraged OpenID Connect to improve security of our embedded system. The main component that I will present to you is named SecGate OpenID Connect, or SecureGate. So, welcome to ARS. That's the event that is presenting my talk. And I'm from IoT Visitage, a company that is located in France in a country named Labortyne. We worked on HGL for the first version of the application framework. And we use it at the moment to create a new distribution whose name is Hyde Pesco S, whose intended to be a long-term support distribution for our embedded system. So, what I will present to you is the Secure Gateway. And now I will talk about why we did it. The Secure Gateway is a component that comes in a wide system. It's the connector that allows people to identify themselves and get access to internals of the embedded system. The way it works is that it's connected to a social identity provider that can grant that the people that is here is the people that it claims to be. This is used to grant accesses to protecting items of the system. So, the main idea is that each access to the system goes through the Secure Gateway. When authenticated, the client gets access to part of the system that is protected or is denied to access it. The master piece is that we use OpenID Connect to get the access. OpenID Connect is a flexible standard and it is widely supported by the measure. Also, it has a design that allows extension. Well, primarily, OpenID Connect delivers information on the user. But not on the user as being its name, but as the user being what it claims to be itself. Then we can, in some circumstances, get more information about the user. Let's go in that. OpenID Connect is a protocol normalizing that is based on top of OS2 authentication protocol that is also used internally by Secure Gateway. And it enables to verify the identity that a user claims to have and to get some profile information about it. If possible, but not always. Anyway, it's a protocol based on SAML2, but re-write it for JSON REST. And it is widely supported by measure operators. In this presentation, we will use words. These words. OS2 protocol, it's a protocol of authorization that is widely used. Authorization server. This is a server that accepts to deliver authorization. So you need to present some grants and you get authorized. It delivers a token that allows you to ask a token server to get a token to access resources. On top of that, OpenID normalize fact that you can get a token to get identity data or profiles. Then what is an identity provider? OpenID server that delivers you OpenID identity. Based on that, we can trust or not the fact that the user is what claims to be based on trust on the identity provider or on the protocol it follows to get identity fee. So we manage levels of assurance in what the user is. With a level of assurance of zero, we don't trust the user. We don't know who he is. With a level of assurance of one, well, we trust it. But less than with a level of assurance of two or three. So it's partly normalized and it's used into our system to access protected resources using bear tokens that are tokens that open spirals. So if your gateway managed to have several identity providers, it's a benefit because we can have a fallback in case of lake or issue in accessing an identity provider. It means that we have to connect the identity of some user for more than one identity provider that's named Federation. We can federate identity as a particular thing. We can also require to have two authentication for enforcing the security. Well, open the new chapter now. We will speak more precisely about the secure gateway and how it works and its mechanism. Well, principles are that each access must be transport layer secure, otherwise it's denied. It's imposed by the POS protocol, by OpenID protocol, so let's go TLS. You can optionally add a client certificate to increase the trust that you have in your client. Well, on accesses to an unprotected resource, an unprotected resource are open and public. But accesses to forbidden or protected resource is not possible if you are not authenticated. So if you're not authenticated and try to access a protected resource, you are redirected to an authentication server that will authenticate you, and then redirected back to the service that now knows your identity, that you are what you claim to be. And based on what is your right, I know it's configured in the system, your access will be either forbidden because you are what you are and you cannot access this resource or granted because, well, that's okay. When you're not authenticated, what happens is that you are redirected to an authentication server for starting the authentication process. Well, it is that you are committed to Internet. We also provide some local server that can be used without Internet. For example, with the available authentication module of Linux, or using some devices like a SIM card or NFC type, fingerprint that is linked to the available authentication system. Anyway, if you're not authenticated, you first have a page that gives you a choice between several identity provider services you choose and then get to the identity provider that authenticates you and delivers token access to the secure gate. This is the summary of the conversation between the client, the service, the identity provider. So it explains briefly with the graphic what I already said before. Based on that, the state of the connection of the user is managed. So either at the beginning you are unknown, then you enter in an authentication process and either you are authenticated or not. So if you're authenticated, you're known and the system knows what are the resources that you can access. At the end, either on expiration or explicit or implicit disconnection, the connection is turned back to an end. The data provided by the identity provider on Street OpenID Connect protocol are very few. You have two things, the identity of the identity provider itself and an identifier of the user in the context of that identity provider. Well, if you master the OpenID or the identity provider, you can also implement some claims, specific claims that can add data about the user. But you have to know to master the identity provider. Well, let's open a new chapter. The management. Because you have a system now, how to tune it, how to create it. Let's get in. Here is the use case. The main thing of our concern is the operator. The operator that comes on the equipment and wants to connect with its identity. The first must authenticate to the identity provider. The identity provider knows the operator because the operator's manager has set up the operator and its role. On the system side, when the identity of the operator is known, the age equipment has to know what are the permissions granted for the role given to the operator. This is set by the fleet supervision because, well, these equipments are not one that is created and managed like a personal computer. This is an equipment that is a cell and that's not unique. Let's check that. First, the easiest part, management of the operator. So the manager of the operator is in charge of setting the system for the operator, giving it in roles and permissions. That's a role-based system. We think it's the simplest way to provide permissions to an operator. Internally, the secure gateway doesn't use the word of role, but it uses the word of attributes. So a user gets attributes to its identity and this attributes maps well to roles, groups, permissions, etc. Fleet management is a situation more complex. You have to manage equipment that you sell and that is numerous. So you provide a configuration statically at the beginning and then maybe you can update the configuration, but it leads to a situation where some equipment are up to date and some of those are not because they had connectivity issues to the updating system. On the fleet management side, also you have to establish a connection between the roles and the attributes given at the identity provider and the exact permission that the user has inside the system. You have to do that for each identity provider because identity providers maybe have not the same logic or attributes. You have to set up the identity providers. You have to set up the authorization server, etc. for each one. There is maybe several identity providers that you have to set up and its configuration is not so easy. You have to be precise. Setting up an identity provider requires you to establish to declare the secure gate application to the identity provider getting a client ID for the secure gateway, a secret ID, some redirections where you have to be registered and you also need some time to tell what is the flow that has to be used. Setting it is sometimes easier when you have a well-known discovery and trip on for identity provider. Otherwise, you have to set up each configuration. Then you have to configure profiles telling, well, for this identity provider, these roles and attributes and I have this level of assurance and I give these permissions. You have to provide for the redirection page icons and the URL of the login page. This is an example of configuration showing how to set an identity provider. Here you have an ID that is one login that is logically linked to the one login site. This one is easy to set up because it has a well-known discovery entry point. Then you set what is the login page, the vehicle and here you tell what are the trust that you have based on the scope granted by the client. Let's speak now about the implementation of the security on the edge side. At first, you have an authentication. Here the open ID process of authenticating is abstracted in this small square and when you are authenticated, the secure gateway provides you permissions to the Cinegora database for the session of the client. Then when the client access to some service, its session is first checked by the secure gateway. Then the service that requires permissions asks Cinegora for the permission if it's granted or not. Cinegora answers and the service is satisfied or not. As I said, on the edge side we have to connect works between the roles given by the identity provider and the permissions of the system. On the edge side we encourage service developers to have a fine grain of permission so that the security is better if it's the case. Conversely, you have a big amount of permissions and it's not really easy to tune. We have to manage the permissions by groups so we allow to map permissions to one or more group of permissions. Conversely, for identity provider we have roles, we have attributes, we have a level of assurance. Then we map an identity provider, a level of assurance and given attributes to a set of permission group. Then the match is done. Let's see how it works on the basic configuration file. On the left you have the mapping of identity provider to permission groups. Then as you see, if you come from IoTBZH that identified you with the attribute setup, if the level of assurance is 2, you get the group setup. Otherwise you get the group edit. But if you have the LOI 2, then you also have the LOI of 0 and you get also edit. On the right side you see the configuration for permissions. We simply hear a lot the name of the permission but it's given that the permission admin is linked to the group admin. The permission setup is linked to the groups admin and setup. You also have a mechanism for pattern settings. Now the Synagora binding that is a component that is used to manage Synagora internally provides a session. It's an agent, it's binding. Service access Synagora binding and delivers permission. Synagora access Synagora binding agent to check unknown sessions. And then Synagora binding that has the mapping of permissions role and attribute answers based on the session. That's Synagora binding as it's seen on the top right that manage the permissions that have mapping roles and permissions. So in one side it speaks to the service that knows role, identity provider, level of assurance, attributes. And on the other side it speaks to Synagora that knows sessions, permissions. This is now time to have a larger view and speak about the modularity that is implemented in the secure gateway. The secure gateway now is an extension of the binder. That's a new feature of the binder. So it is a binder but with extensions that gives a new feature like filtering connection and loading plugins and bindings. Today we have built-in modules for LDAP or as to OpenID Connect. We have pluggable modules for NFC and PAM that is pluggable authentication module for Linux. We have planned for further extension like open banking OpenID, FedID, FedFinancialGrade, FEPI, FEPI English. Time now for a short demo of the system. Welcome to this demonstration of the secure gateway. So what we can see here on this screen is we have three security zones going from public with a level of assurance of zero which means anonymous access. A second zone that is private that requires basic authentication in this case is going to be handled by PAM with login password. And the last one that is confidential that requires a more advanced authentication model and in this case we use an NFC token for the demonstration. So let's have a quick look to the configuration of the secure gateway. So we can see it is a standard binder. We find out the port and the different certificate for the TLS connection. Then we have the configuration of the extension which is really where we load the secure gateway by itself. And in all case we have two authorities that are defined. The first one is using PAM for login password authentication and we can see here that this is a level one of authentication. The second one uses a secure NFC token and in this case we have a level of assurance of two. Then to finish what is important in the configuration we see here the three different zones going from public with no authentication to confidential where we require an authentication level of two. And you can see here on the log that it is a standard binding. So let's try to play with it. If I click on public there is no authentication. As we said it is a level zero authentication. On the other hand if I click on private we can see here on the exchange that it proposed to IDP because the requirement is a level one. I'm going to select PAM using RedPest demo login and here I am. Okay so I am logged in. Obviously if I request again as a private I don't have to log a second time. Now I'm going to go on the confidential one. In this case I only have one authority because there is only one IDP that supports the LOR2 in my configuration. If I click on NFC we can see that the only authority is available is the NFC reader. So you can see on my camera that if I put the card I am logged in. And if I remove the card I am logged out. So we have a direct authentication model that impose the user to have the card present. Okay thank you for your time. It's time to conclude now. So we now have with secure gateway a secure access point to the system that is secured through TLS and authentication. The authentication is very flexible and use widely supported standards. We can also as benefit track identity of people that interact with the system. That's all. Thank you for your interest. I give you a few links. This one is on OpenID Connect and OS2. And this one is on our company and our product red desk. Well time for questioning now if you have.