New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ivelin opened this Issue Jan 13, 2016 · 36 comments

Comments

Projects
None yet
7 participants
@ivelin
Contributor

ivelin commented Jan 13, 2016

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

This comment has been minimized.

Member

deruelle commented Jan 13, 2016

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

This comment has been minimized.

Contributor

atsakiridis commented Jan 13, 2016

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

@ghjansen

This comment has been minimized.

Contributor

ghjansen commented Jan 13, 2016

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

This comment has been minimized.

Member

deruelle commented Jan 13, 2016

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
#784 (comment)
.

@deruelle deruelle assigned jreyapvas and unassigned ghjansen Jan 15, 2016

@deruelle deruelle assigned thinhly197 and unassigned jreyapvas Jan 26, 2016

@deruelle

This comment has been minimized.

Member

deruelle commented Jan 26, 2016

@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

This comment has been minimized.

Collaborator

thinhly197 commented Jan 28, 2016

@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

This comment has been minimized.

Member

deruelle commented Jan 28, 2016

@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

This comment has been minimized.

Collaborator

thinhly197 commented Jan 28, 2016

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

@thinhly197

This comment has been minimized.

Collaborator

thinhly197 commented Jan 29, 2016

@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

This comment has been minimized.

Collaborator

thinhly197 commented Jan 30, 2016

@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

This comment has been minimized.

Member

deruelle commented Jan 31, 2016

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

Adding @gvagenas to this conversation.

@thinhly197

This comment has been minimized.

Collaborator

thinhly197 commented Feb 1, 2016

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

@deruelle

This comment has been minimized.

Member

deruelle commented Feb 1, 2016

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

thinhly197 added a commit to thinhly197/RestComm-Core that referenced this issue Feb 2, 2016

@gvagenas gvagenas modified the milestones: 7.5.0, 7.6.0 Feb 9, 2016

@gvagenas

This comment has been minimized.

Collaborator

gvagenas commented May 13, 2016

@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

This comment has been minimized.

Member

deruelle commented May 13, 2016

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 deruelle added this to the 7.7.0 milestone May 20, 2016

@deruelle

This comment has been minimized.

Member

deruelle commented May 20, 2016

@gvagenas @ghjansen any further thoughts ?

@gvagenas

This comment has been minimized.

Collaborator

gvagenas commented May 20, 2016

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

@ghjansen

This comment has been minimized.

Contributor

ghjansen commented May 20, 2016

@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

This comment has been minimized.

Member

deruelle commented May 20, 2016

@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

This comment has been minimized.

Contributor

ghjansen commented May 20, 2016

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

This comment has been minimized.

Member

deruelle commented May 20, 2016

@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

This comment has been minimized.

Contributor

ghjansen commented May 20, 2016

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

This comment has been minimized.

Member

deruelle commented May 20, 2016

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

@ghjansen

This comment has been minimized.

Contributor

ghjansen commented May 20, 2016

@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

This comment has been minimized.

Member

deruelle commented May 20, 2016

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

@gvagenas gvagenas modified the milestones: 7.7.0, 7.8.0 May 31, 2016

@gvagenas gvagenas closed this in 3d50833 Jun 2, 2016

gvagenas added a commit that referenced this issue Jun 2, 2016

maria-farooq pushed a commit to maria-farooq/Restcomm-Connect that referenced this issue Jun 6, 2016

Maria Farooq
Merge branch 'master' of https://github.com/Restcomm/Restcomm-Connect
…into issue-5

# By Thinh Ly (6) and others
# Via George Vagenas (6) and others
* 'master' of https://github.com/Restcomm/Restcomm-Connect:
  fix RestComm#1124
  Regression fix for Account menu scrollbar in AdminUI.
  Check for getRawContent. This close RestComm#1150
  Fix for DB upgrade script
  Fixed broken Client creation in AdminUI.
  Fixing broken links
  Surround create Cancel method and provide logging to check for NPE. This refers to RestComm#1128
  Feature flag to disable SDP patching on updatingMediaSession. This close RestComm#1138
  Fixes for WebTrigger. - Refactored web trigger authentication. - Properly handle inactive accounts too.
  Fix RvdController /log method. - Patched RvdController to properly handle RVD context.
  Fixes for issue RestComm#784
  Proper testing for issue RestComm#784
  This resolve RestComm#784 - remove the forgotten printout
  This resolves RestComm#784
  Fix for issue RestComm#784
  This resolves RestComm#784
  This resolves RestComm#784
  Fix for issue RestComm#784
  This resolves RestComm#784
  This resolves RestComm#784
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment