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