WEBVTT 00:00.000 --> 00:10.000 Thank you for joining this conference with afternoon. 00:10.000 --> 00:17.000 Yes, today we are going to talk about authentication and authentication in the 00:18.000 --> 00:24.000 and how we can use single sign-on to the C-plound. 00:31.000 --> 00:36.000 So my name is Jan Monier, I'm part of the Lincoln team. 00:39.000 --> 00:44.000 So we are going to introduce basics about authentication, 00:45.000 --> 00:49.000 a bit of the story of the authentication. 00:49.000 --> 00:58.000 We are going to discuss the specific case of what and GWT for voice of I.T. 00:58.000 --> 01:03.000 And to illustrate how we can do that we've been informed, flexible, 01:03.000 --> 01:08.000 and at the end we can have some questions. 01:08.000 --> 01:11.000 Just have a quick introduction to the info. 01:11.000 --> 01:15.000 So probably you already know, the info is an open source. 01:15.000 --> 01:21.000 Voice of RAP, voice of RAP is software implementing the C-plound call. 01:21.000 --> 01:25.000 It was developed in 2000. 01:25.000 --> 01:32.000 So it's a pretty old project but still active and developed. 01:32.000 --> 01:38.000 So now it is possible with the info to place voice call video call 01:38.000 --> 01:46.000 and we also have some conferencing capabilities and chat. 01:46.000 --> 01:53.000 On top of the info we also developed a server, proxy C-plound C-plound C-plound 01:53.000 --> 01:57.000 which is quite similar to open C-plound. 01:57.000 --> 02:04.000 We just discussed in the previous presentation. 02:04.000 --> 02:10.000 And we were going to talk about this C-plound C-plound C-plound C-plound C-plound 02:10.000 --> 02:20.000 which is the proxy is part of the authentication schema. 02:20.000 --> 02:22.000 Okay. 02:22.000 --> 02:24.000 Authentication is very important. 02:24.000 --> 02:28.000 We need to know who is using digital services. 02:28.000 --> 02:33.000 If when we place a phone call it's very important to make sure that the person 02:33.000 --> 02:37.000 with calling is really authorized to use the identity. 02:37.000 --> 02:43.000 So there is no matter with that, it's something that we have to deal with. 02:43.000 --> 02:50.000 But voice of RAP is not the only place where authentication is important. 02:50.000 --> 02:52.000 You have to log into your computer. 02:52.000 --> 02:57.000 You will access to your mail service. 02:57.000 --> 03:02.000 You also need to access some internet contents. 03:02.000 --> 03:05.000 Find sharing and on your mobile device. 03:05.000 --> 03:12.000 You also need to be able to pull your identity. 03:12.000 --> 03:17.000 Well, so it's a lot of different user name, but a password. 03:17.000 --> 03:18.000 So it's pretty difficult. 03:18.000 --> 03:20.000 So what's the solution? 03:20.000 --> 03:22.000 Can we apply? 03:22.000 --> 03:26.000 Well, use the same password for all your accounts. 03:26.000 --> 03:27.000 Not very secure. 03:27.000 --> 03:32.000 To write everything on the paper, not secure as well. 03:32.000 --> 03:45.000 So to deal with this type of issue, the ID is to use a centralized solution. 03:45.000 --> 03:52.000 With a centralized solution, it would be possible to use the same credentials for all the services. 03:52.000 --> 03:58.000 Computer logging, mail, internet access, mobile etc. 03:58.000 --> 04:04.000 And of course, voice of RAP. 04:04.000 --> 04:09.000 The protocol, which can be used for that, is 0-2. 04:09.000 --> 04:17.000 So what's 2 is an IATF protocol, which describes how to perform single sign on. 04:17.000 --> 04:19.000 It's widely used so far. 04:19.000 --> 04:32.000 So the basics are you have first an authorization state followed by an access token requirement. 04:32.000 --> 04:41.000 When you are authorized, you get the access token and later you can use the access token to access the resource. 04:41.000 --> 04:51.000 The ID is to do exactly the same in the scope of voice of RAP. 04:51.000 --> 04:59.000 This is just more precise example, which is a derivative on the phone. 04:59.000 --> 05:05.000 How to use HTTP thing forward to get authorization. 05:05.000 --> 05:16.000 So at the beginning, there is an HTTP request to authorization through the user is prompt on the web page to enter it. 05:17.000 --> 05:24.000 Then the information application gets back the authentication token. 05:24.000 --> 05:34.000 And the information present with authentication token to the resources so far in order to get the access token. 05:34.000 --> 05:45.000 And this access token is then used for an HTTP request, which in this case we use to get the remote configuration of the application. 05:45.000 --> 05:51.000 So that's okay for the HTTP case, but what about CIP? 05:51.000 --> 06:07.000 In the case of CIP, there is a new RFC, which is the 88, which describes how to use port in the case of CIP. 06:07.000 --> 06:12.000 The basic step on the phone is to start with a registered message. 06:12.000 --> 06:25.000 The CIP server is going to challenge this registered request with 401, but with a new type of authentication which is built. 06:25.000 --> 06:28.000 And with a special parameter, what server? 06:28.000 --> 06:42.000 In the other server, the CIP server specify which authorization server has to be contacted by the application. 06:42.000 --> 06:49.000 In fact, we perform the authentication using the username password. 06:49.000 --> 07:01.000 And we get back an access token, exactly in the same way as HTTP, but this access token cannot be used to authenticate the registration. 07:01.000 --> 07:04.000 And then we save the 200K. 07:04.000 --> 07:12.000 So it's really the same idea as HTTP, but in the case of CIP. 07:12.000 --> 07:16.000 So it's for the standard. 07:16.000 --> 07:22.000 If we go into detail, the first message is the register, the 401. 07:22.000 --> 07:31.000 You can see that the WWW.authenticate editor contains this new type of authentication which is built. 07:31.000 --> 07:40.000 And the other server, where the address of the two authentication server is set. 07:40.000 --> 07:48.000 And then following the authentication, the register is re-applied with an authorization editor. 07:48.000 --> 07:53.000 And with the access token and all during. 07:53.000 --> 07:57.000 So this is for the protocol details. 07:58.000 --> 08:16.000 Now, the WWT is a way for a authorization server to provide an access token to a site, to client. 08:16.000 --> 08:25.000 The WWT token is basically a day, the 54, I'm going to say the string. 08:25.000 --> 08:35.000 But within this token, there are some important fields, which are the audience, which is basically the client ID. 08:35.000 --> 08:43.000 The authorization time, issue work, and a new claim that we added, which is CIP identity. 08:43.000 --> 08:55.000 The proper of this claim is to perform the link between the GWT token and the CIP account. 08:55.000 --> 08:58.000 So now, it works. 08:58.000 --> 09:04.000 We start the link phone application from a computer. 09:04.000 --> 09:19.000 The CIP register is sent to the Plexi CIP proxy, which challenge the register message. 09:19.000 --> 09:28.000 The link phone client opens a web browser connected to the authorization server. 09:28.000 --> 09:32.000 We have provided a username and password. 09:32.000 --> 09:36.000 The authorization server checks if the connection is okay. 09:36.000 --> 09:47.000 And I generate a GWT token, add the CIP identity claim, which is configured on the server side. 09:47.000 --> 09:53.000 And provide the phone back, with this access token. 09:53.000 --> 10:01.000 This access token is now provided in the new register message to the CIP proxy. 10:01.000 --> 10:16.000 The CIP proxy presents some check, who the sure check demandatory claim, check if the CIP identity is the same as the CIP identity of the CIP network. 10:16.000 --> 10:26.000 Check the expiration, and check the valid identity of the GWT token thanks to its signature. 10:26.000 --> 10:30.000 We do not perform life-ticking. 10:30.000 --> 10:37.000 We rely on the signature of the GWT token. 10:37.000 --> 10:43.000 And then the registration is accessible. 10:43.000 --> 10:52.000 This is for the initial request, and later it is possible to perform some riffs to refresh this access token, 10:52.000 --> 10:59.000 because usually an access token is for about a minute, but you also have another token, which is the refresh token, 10:59.000 --> 11:08.000 which allow to refresh the access token without having to prompt the user for its username and password again. 11:08.000 --> 11:17.000 Okay, this is almost the same, but I want to mention that we perform a test with CIP yolk. 11:17.000 --> 11:24.000 CIP yolk is a pretty good project, which allows you to perform the signature sign on. 11:24.000 --> 11:37.000 And it can be connected to an LDAP server as well, so it's a way to perform this kind of test. 11:37.000 --> 11:48.000 This functionality is available on the Lymphone version 6, which is the new one, which is on the development and complexity to the 2.5. 11:48.000 --> 11:56.000 So, it's just to show you the configuration, it's quite a simple, you have the authentication module. 11:56.000 --> 12:00.000 You provide the authorization server URL. 12:01.000 --> 12:12.000 You provide the RELAMM, the audience is Lymphone, it's the OpenID, known for its client ID of code. 12:12.000 --> 12:22.000 And the name of the claim in which you configure the CIP address. 12:22.000 --> 12:36.000 So, we open the configuration, Lymphone is started, we have to apply the RELAMM configuration. 12:36.000 --> 12:45.000 It's very directed to the T-Clock authentication, authentication is performed, and again you go back to Lymphone. 12:45.000 --> 12:49.000 It's registered. 12:49.000 --> 12:51.000 Okay. 12:51.000 --> 12:58.000 In conclusion, with CIP yolk sign on, we can have better security, CIP yolk. 12:58.000 --> 13:06.000 And it's possible to have really a single password for all the users. 13:06.000 --> 13:16.000 Okay. 13:16.000 --> 13:34.000 In fact, yes. 13:34.000 --> 13:45.000 The question is, how to avoid the 2-on-3 password, 2-on-3, especially when an incoming call arrives. 13:45.000 --> 13:52.000 You cannot ask the user to provide its credentials, right? 13:53.000 --> 13:59.000 In fact, in OpenID and the whole, there are two types of token. 13:59.000 --> 14:04.000 One, which is an access token, which is very short, but there is also this three-trash token. 14:04.000 --> 14:13.000 And the three-trash token can be valid for days or weeks. 14:13.000 --> 14:20.000 So, it's a lot to, if you are connected at least one time a week, it's okay. 14:20.000 --> 14:26.000 And now, on Lymphone, we also use what we call the push notification. 14:26.000 --> 14:35.000 So, we send a push notification to the application, to wake up the application and perform some, from registration. 14:35.000 --> 14:40.000 And it could be the opportunity to refresh the access token. 14:44.000 --> 14:50.000 And the question is, is there a connection? 14:50.000 --> 14:58.000 Well, the question is, is there a connection? 14:58.000 --> 15:00.000 Hmm. 15:00.000 --> 15:01.000 No. 15:01.000 --> 15:02.000 Not yet. 15:02.000 --> 15:04.000 We do not use... 15:04.000 --> 15:05.000 What do we need to do? 15:06.000 --> 15:07.000 Sorry. 15:07.000 --> 15:11.000 Do we rebook the authorization after a call? 15:11.000 --> 15:13.000 More or less? 15:13.000 --> 15:14.000 No. 15:14.000 --> 15:30.000 I know that there is a channel to rebook the access token, but it's not something that is implemented in the condition of information. 15:31.000 --> 15:34.000 Why do you need to do this? 15:34.000 --> 15:45.000 It's just because I don't, I'm not aware of the server need to check the GWT token. 15:45.000 --> 15:54.000 And I don't know if OpenTPS performs such check. 15:54.000 --> 15:56.000 Good. 15:56.000 --> 16:08.000 So, probably, if possible, you use the phone with a manual, in fact, circumstances available. 16:08.000 --> 16:09.000 Okay.