Allow Restcomm client authentication with the user ID and password of a Restcomm account user

[ivelin]

Currently a Restcomm user has to create explicitly a SIP end point with user/pass pair in order for a Restcomm client to register and place calls. The other current alternative is for a Restcomm client to make registrarless calls which is a security concern.

It would be convenient if a Restcomm Server allows a Restcomm client to authenticate with the user/pass pair of a registered Restcomm account. This will work well for basic Restcomm accounts that are intended for end users.

More advanced Restcomm account profiles (e.g. organization admin) can still allow programmatic creation of SIP end points with credentials that are applicable to more complex use cases.

[deruelle]

We should then create a new SIP/RestComm Client on Account Creation at the Rest API with the same credentials as the new account being created. @ghjansen @gvagenas @atsakiridis comments ?

It's a good task for a new contributor to get familiar with the code. Marking as Help Wanted

[atsakiridis]

Sounds good and clean to me @deruelle. Let's see what the restcomm core guys have to say :)

[ghjansen]

Yes, i agree with that too. Sounds like a time saver to make the user life easier :) I was wondering about Twillio compatibility, but maybe for this issue it won't be a relevant concern.

[deruelle]

Yes it's ok. Users can still remove the SIP/RestComm Client if they are not happy with having it created by default.

On Wed, Jan 13, 2016 at 11:53 AM, Guilherme Humberto Jansen < notifications@github.com> wrote:

Yes, i agree with that too. Sounds like a time saver to make the user life easier :) I was wondering about Twillio compatibility, but maybe for this issue it won't be a relevant concern.

— Reply to this email directly or view it on GitHub https://github.com/RestComm/RestComm-Core/issues/784#issuecomment-171253120 .

[deruelle]

@thinhly197 do you think you can take this one as a first contribution ? It shouldn't be too hard for you to get started

[thinhly197]

@deruelle I look into restcomm database and understand the issue like below. Please confirm about it. Thanks. when user register restcomm account on the Restcomm web GUI, this account will be put into restcomm_accounts table. When user register SIP account, it will prefer to their restcomm_account and create the new SIP account into restcomm_clients table.

And now, we want that when user register restcomm_account, we have option for their choose to auto generate the SIP account (e.g: alice/1234, bob/1234).

One thing I don't clear that what is the restcomm_registration meaning?

[deruelle]

@thinhly197 correct now what we want is that when a user creates an account either through the web GUI or REST API, it creates a a new line in restcomm_account and restcomm_clients tables with the same username and password

Restcomm_registration is the table that acts a SIP Registrar and holds the IP Address and Port of where a user is registering (SIP REGISTER) with their SIP Client. Olympus WebRTC Application is a SIP Client.

[thinhly197]

@deruelle thanks. it's clear. let me dig the source code. cheers

[thinhly197]

@deruelle Hi, I'm trying to implement in the AccountsEndpoint.putAccount(). In this function I prepare some data for client and call ClientsEndpoint.putClient().

But I got the NullPointerException, it seems that DAO object is null this context. I don't know why and still investigate it.

[thinhly197]

@deruelle Hi Jean,

I finished implementation. But I think it should be the security problem. You know that the password of restcomm account has been encrypt by MD5 and stored to database, and the password of Client has not. In this case, the client maybe know the password of its administration.

How can I do in this case? Just ignore it, or...

Thinh

[deruelle]

@thinhly197 good catch, that's indeed a security issue. How would you solve that issue ?

Adding @gvagenas to this conversation.

[thinhly197]

I think we can put the default password is email or username also. And user can change its password later if they want.

[deruelle]

I think we should just encrypt any passwords that is stored in the DB no matter what.

[gvagenas]

Before merging this work to master the following issue needs to be cleared. @ghjansen When we create an account for "user@company.com", we use the "user" part to create the equivallent client so Restcomm client "user" with password same as the account will be able to register a sip client. Regarding Organizations work, will this client be unique in a Restcomm instance with many organizations? From what I see this will be a problem, because Organizations work doesn't take care the SIP domain, so even thought "george@company.com" and client "george" will be ok, what will happen with "george@anothercompany.com" (this will work) and client "george" again?

[deruelle]

@gvagenas @ghjansen Organizations should allow us to have SIP Clients for a given Organization to be isolated from another organization. ie multitenancy at Organization level. ie both george@mycompany.com and george@yourcompany.com should be allowed.

[gvagenas]

@deruelle In terms of Restcomm accounts, Organizations already took care to support and allow george@mycompany.com and george@yourcompany.com, these would be two different accounts in the system. My concern here is that the Restcomm client that will be created from the first account "george@mycompany.com" will be "george" and the Restcomm client from the second account "george@yourcompany.com" will "george" again and it will fail. Organizations design doesn't take care of the SIP domains so to have clients with same username in different domains, unless if I am wrong ? @ghjansen can you confirm? @deruelle do you have a design document for the feature here so we can comment?

[deruelle]

Organizations design doesn't take care of the SIP domains so to have clients with same username in different domains,

@ghjansen @gvagenas then it's a flaw, the SIP Client should be tied to a given Organization to account for the domain name. primary key should be clientID (client username) + organizationID (domain name) I think

[gvagenas]

@deruelle do we have a design document for the feature ?

[deruelle]

@gvagenas you mean Organizations https://docs.google.com/a/telestax.com/document/d/1On1cqXMQBjzgNdXqEXT851BUMb3X61UJk4qU3hQDNZw/edit?usp=sharing ?

[gvagenas]

No I meant for current #784 issue

[deruelle]

I don't think so. The requirements are in https://github.com/RestComm/Restcomm-Connect/issues/784#issue-126307884 and https://github.com/RestComm/Restcomm-Connect/issues/784#issuecomment-171239225

[ghjansen]

@gvagenas @deruelle if i got it right, it means that two different Clients, from two different Accounts and Organizations must have two different SIP URIs, like:

Client 1: sip:george@mycompany.restcomm.com Client 2: sip:george@yourcompany.restcomm.com

This way will be possible to define what is the Organization and distinguish the Client. But what about the cases when we use only the IP?:

Client X: sip:george@127.0.0.1

[gvagenas]

@ghjansen @deruelle beisides using IP address which is a valid question, another issue is how we dial these clients? Clients are used inside a Dial verb with just the name of the cllient and in the case of same username different domain, clients cannot be dialed because "george" client cannot be resolved to single entity. @ghjansen what do you think?

I am not sure we can support the feature here and more important the issue here revealed issues on the Organizations design.

[deruelle]

@ghjansen

Client 1: sip:george@mycompany.restcomm.com Client 2: sip:george@yourcompany.restcomm.com

that's correct

Client X: sip:george@127.0.0.1 The IP is equivalent to a domain name in that case, so the uniqueness of the client is within the boundaries of the IP Address.

@gvagenas We can think of 2 ways:

1. Dialing Client is allowed only in the context of the same domain the request is done. A DID is tied to a domain, an application is tied to a domain so the Dial of that application can only dial clients in the same domain. Dialing Clients from a different domain should use Dial SIP as we really are targetting a SIP URI that's in a different domain.
2. We allow the the Dial Client to take on the host but I think 1. is cleaner.

[gvagenas]

@deruelle @ghjansen The issue here is that we cannot have Client username with "@" character because SIP Clients will either not accept the character in the username or will interpret it as the SIP domain, while for Restcomm the "@company.com" is part of the username.

So problem is that later with Organizations, account "george@mycompany.com" will have client "george" and a different account "george@anothercompany.com" will also have client "george".

The issues with this are:

• how we dial Client "george" for specific account?
• how sip client for client "george" of account "george@mycompany.com" will register?

Currently Restcomm doesn't support SIP domains

one option could be to replace '@' with dot '." so client will be "george.mycompany.com". This will make client unique.

@deruelle @ghjansen what do you think?

[deruelle]

The Organization to which everything is attached (SIP Clients, Accounts, DIDs, ...) will define the domain name ie mycompany.com (and as such the SIP domain as well)

No other DB column need to contain it, they should use the Organization as part of the primary or foreign key to find out the domain name and avoid conflicts. No needs for hacks on @ and . The username should never contain the domain name in the DB.

As I understand it, I think this PR if working technically should be merged, it has the same limitations as the SIP DID, ie it is currently unique and not Organization multi tenant enabled but the work from @ghjansen will take care of that.

[deruelle]

@gvagenas @ghjansen any further thoughts ?

[gvagenas]

@deruelle From my side what you suggest is ok. I will proceed to merge this

[ghjansen]

@deruelle just confirming if i got it right: in the case george@127.0.0.1 RestComm must assume a namespace that corresponds to this IP and look for the george SIP Client inside this Organization only, right? But how this relationship between an IP and a namespace should work, it will be a restscomm.xml configuration? Or maybe we could comfortable assume the Default Organization to all cases involving IP on the first iteration?

Im thinking about create a separated issue so we can continue this discussion, ok for you guys?

[deruelle]

@ghjansen @gvagenas actually I'm thinking george@127.0.0.1 shouldn't be allowed and the user should be george@company.com but the SIP UA configured to reach the IP of the Restcomm node (Route Header). That should cover us and make the solution simpler right ?

[ghjansen]

Got it @deruelle thanks! Seems simpler indeed, then SIP UA will probably identify the Organization by extracting the namespace from domain and lookup the Client.

Well, it turns the implementation easier i think, but following this path we may create different requirements per resource when running RestComm as standalone. What i mean is that, for cases like mine where RestComm runs as standalone in my OS, i'll be able to use RestComm Admin UI, RVD and all the APIs without any concern about DNS, because RestComm will be able to obtain the Organization from the account i use to authenticate in each one of those resources. But considering now SIP calls, seems to me that the configuration in /etc/hots will be mandatory, otherwise softwares like Jitsi or Linphone wont be able to reach RestComm using george@mycompany.com. (Btw, and what about Olympus?)

So currently, i see the configuration in /etc/hosts as mandatory to make half of RestComm work. IMO, we should take care about that to assume this /etc/hosts configuration as absolute and mandatory or not mandatory at all, to make easier to understand how Organization works.

wdyt @deruelle @gvagenas ?

[deruelle]

@ghjansen great !

But considering now SIP calls, seems to me that the configuration in hots.conf will be mandatory, otherwise softwares like Jitsi or Linphone wont be able to reach RestComm using george@mycompany.com. (Btw, and what about Olympus?)

Not really. In jitsi and sipphone you can configure the registrar independently of the user account name ie have user name george@mycompany.com and REgistrar set to 127.0.0.1:5060 so that jitsi can still route to Restcomm. You can try that locally today already if you want. Same thing for Olympus, you login with george@mycompany.com but behind the covers Olympus sets the WebSockets URL to wss://127.0.0.1:5083

[ghjansen]

Awesome @deruelle , its getting better now. 😄 So this way, the /etc/hosts won't be required at all.

Should we also bring to the table REGISTRARLESS feature in the same scenario or even in other scenarios? (not only standalone)

[deruelle]

no we decided to remove REGISTRARLESS @atsakiridis removed it from iOS already

[ghjansen]

@deruelle i meant REGISTRARLESS as a SIP standard, because maybe this is common in other softwares like Linphone and Jitsi, so maybe one guy will not be able to use this feature without including some domain in /etc/hosts first. This is a valid concern?

I know this is very specific and we may choose to skip for now, but since we are brainstorming its good to have it in mind at least.

[deruelle]

@ghjansen they will be able to call DIDs ie 1234@IP but not other clients in REGISTRARLESS mode which is the behavior we want.