Call Control Web API accespting unauthenticated requests on non-ssl port on 4.6

[Alan Worstell]

Hello,
According to the wiki at:
http://wiki.sipfoundry.org/display/sipXecs/Call+Control+Web+Service
"If you are issuing the curl command from a trusted host ( i.e. one
where sipx proxy is running) please use only HTTPS (no authentication is
required)."

However, If I use the HTTPS port 6666 I get returned data that it
requires authentication. Is a "trusted host" only another cluster
member, or should it not require auth from the local host as well?

if I issue a POST request on port 6667 unauthenticated, the call is
placed, If I use the HTTPS port 6666 I get returned data that it
requires authentication. This happens with requests initiated by remote
hosts as well.

Is this also expected behavior, or does the wiki have reversed data?

Thanks,

[Mircea Carasel]

Post by Alan Worstell
Hello,
http://wiki.sipfoundry.org/display/sipXecs/Call+Control+Web+Service
"If you are issuing the curl command from a trusted host ( i.e. one where
sipx proxy is running) please use only HTTPS (no authentication is
required)."
However, If I use the HTTPS port 6666 I get returned data that it requires
authentication. Is a "trusted host" only another cluster member, or should
it not require auth from the local host as well?
if I issue a POST request on port 6667 unauthenticated, the call is
placed, If I use the HTTPS port 6666 I get returned data that it requires
authentication. This happens with requests initiated by remote hosts as
well.
Is this also expected behavior, or does the wiki have reversed data?

Is this 4.4 or 4.6?
We have done various changes in 4.6 regarding how communication inside
cluster is done and how should we communicate from outside cluster
The wiki document wasn't updated from some time, and does not reflect
changes that we done in 4.6. Trusted host is a concept used only in 4.4.
localhost and primary were trusted host, meaning that if the call was done
from these hosts, authentication layer was bypassed

Here is how it works in 4.4:
-port 6667 is a HTTP port and uses digest authentication
-port 6666 is a HTTPS port and uses basic authentication

In 4.6:
-port 6667 is HTTP port and meant to be used only internal (inside
cluster), no authentication, should not be visible outside cluster (we have
different ways to encrypt data inside cluster and there is configurable in
UI to encrypt or not data inside cluster)
-port 6666 is HTTP (we removed SSL Listener) and uses digest authentication

In 4.6 only apache server that we have in front does SSL and any SSL call
should be proxyed through apache (so there are no SSL listener inside
components anymore) - look into: http://track.sipfoundry.org/browse/XX-10098

For callcontroller we did not yet have a reverse proxy in apache to route
SSL calls (will address it post 4.6) but we do have a REST api in
sipxconfig that is recommended to be used (port 443, SSL, basic
authentication, LDAP authentication) instead of directly connecting to port
6666

/my/redirect/<callcontroller relative uri>

example:
https://192.168.1.102/sipxconfig/rest/my/redirect/callcontroller/200/201(places
a call from 200 to 201)

We decided to route everything throuth sipXconfig authentication layer
because this is the most complex and we can perform LDAP authentication
too.
We did not spend time to create the reverse proxy mechanism in apache to
callcontroller and ivr, because we would have missed the LDAP
authentication. Right now apache proxies calls only to sipXconfig and
therefore we use sipXconfig authentication layer for callcontroller rest
apis and ivr rest apis
I think that the solution here would be to create a dedicated
authentication component that will be independent, outside sipXconfig, and
apache will proxy to it (will tackle this task post 4.6)

Mircea

Post by Alan Worstell
Thanks,
--
Alan Worstell
A1 Networks - Systems Administrator
VTSP, dCAA, LPIC-1, Linux+, CLA, DCTS(707)570-2021 x204
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Alan Worstell]

Hello,
This is in 4.6. Thanks for clarifying the changes in the new version.

Regards,

Alan Worstell
A1 Networks - Systems Administrator
VTSP, dCAA, LPIC-1, Linux+, CLA, DCTS
[phone] x204

Post by Alan Worstell
Hello,
http://wiki.sipfoundry.org/display/sipXecs/Call+Control+Web+Service
"If you are issuing the curl command from a trusted host ( i.e.
one where sipx proxy is running) please use only HTTPS (no
authentication is required)."
However, If I use the HTTPS port 6666 I get returned data that it
requires authentication. Is a "trusted host" only another cluster
member, or should it not require auth from the local host as well?
if I issue a POST request on port 6667 unauthenticated, the call
is placed, If I use the HTTPS port 6666 I get returned data that
it requires authentication. This happens with requests initiated
by remote hosts as well.
Is this also expected behavior, or does the wiki have reversed data?
Is this 4.4 or 4.6?
We have done various changes in 4.6 regarding how communication inside
cluster is done and how should we communicate from outside cluster
The wiki document wasn't updated from some time, and does not reflect
changes that we done in 4.6. Trusted host is a concept used only in
4.4. localhost and primary were trusted host, meaning that if the call
was done from these hosts, authentication layer was bypassed
-port 6667 is a HTTP port and uses digest authentication
-port 6666 is a HTTPS port and uses basic authentication
-port 6667 is HTTP port and meant to be used only internal (inside
cluster), no authentication, should not be visible outside cluster (we
have different ways to encrypt data inside cluster and there is
configurable in UI to encrypt or not data inside cluster)
-port 6666 is HTTP (we removed SSL Listener) and uses digest
authentication
In 4.6 only apache server that we have in front does SSL and any SSL
call should be proxyed through apache (so there are no SSL listener
http://track.sipfoundry.org/browse/XX-10098
For callcontroller we did not yet have a reverse proxy in apache to
route SSL calls (will address it post 4.6) but we do have a REST api
in sipxconfig that is recommended to be used (port 443, SSL, basic
authentication, LDAP authentication) instead of directly connecting to
port 6666
/my/redirect/<callcontroller relative uri>
https://192.168.1.102/sipxconfig/rest/my/redirect/callcontroller/200/201
(places a call from 200 to 201)
We decided to route everything throuth sipXconfig authentication layer
because this is the most complex and we can perform LDAP
authentication too.
We did not spend time to create the reverse proxy mechanism in apache
to callcontroller and ivr, because we would have missed the LDAP
authentication. Right now apache proxies calls only to sipXconfig and
therefore we use sipXconfig authentication layer for callcontroller
rest apis and ivr rest apis
I think that the solution here would be to create a dedicated
authentication component that will be independent, outside sipXconfig,
and apache will proxy to it (will tackle this task post 4.6)
Mircea
Thanks,
--
Alan Worstell
A1 Networks - Systems Administrator
VTSP, dCAA, LPIC-1, Linux+, CLA, DCTS
[phone] x204 <tel:%28707%29570-2021%20x204>
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/