30 Jan
2008
30 Jan
'08
2:09 p.m.
Hola, mi experiencia con Radius es nula, nunca lo he usado para nada. Mi
pregunta es sencilla: ¿existe alguna razón para usar OpenSer con Radius en
vez de MySQL directamente?
Me refiero básicamente a las secciones de autenticación y accounting (y tal
vez el módulo "group").
Si resulta que Radius es conveniente en entornos grandes por la razón que
sea... pues nada, a aprender, que es gratis :) pero la cuestión es que me
gustaría saber si realmente aporta alguna ventaja o no.
En principio, la base de datos estaría en un servidor a parte (replicado y
esas cosas). Supongo que en caso de añadir la capa Radius el servidor estaría
en el mismo host. En ese escenario, ¿qué ventajas tiene usar Radius teniendo
en cuenta que no es imprescindible?
Gracias por cualquier aclaración.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
30 Jan
30 Jan
2:13 p.m.
On Wednesday 30 January 2008 10:09:58 Iñaki Baz Castillo wrote:
En principio, la base de datos estaría en un servidor
a parte (replicado y
esas cosas). Supongo que en caso de añadir la capa Radius el servidor
estaría en el mismo host. En ese escenario, ¿qué ventajas tiene usar Radius
teniendo en cuenta que no es imprescindible?
O sea, por velocidad no va a ser, porque si OpenSer tiene que hablar con el
servidor Radius que a su vez consultará la BD esto será más lento que si
Openser consulta directamente la BD. ¿Entonces? ¿por qué tanto Radius
Radius...?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
2:16 p.m.
Yo lo conozco de mi anterior experiencia laboral. Usabamos radius para la
autenticación generalizada de todo el sistema.
Y teníamos openser. El radius en este caso estaba en local. Es mucho más
rápido que MySQL y quizá Jesús pueda dar más datos :)
Saludos
On 1/30/08, Iñaki Baz Castillo <ibc(a)in.ilimit.es> wrote:
On Wednesday 30 January 2008 10:09:58 Iñaki Baz Castillo wrote:
En principio, la base de datos estaría en un
servidor a parte (replicado
y
esas cosas). Supongo que en caso de añadir la
capa Radius el servidor
estaría en el mismo host. En ese escenario, ¿qué ventajas tiene usar
Radius
teniendo en cuenta que no es imprescindible?
O sea, por velocidad no va a ser, porque si OpenSer tiene que hablar con
el
servidor Radius que a su vez consultará la BD esto será más lento que si
Openser consulta directamente la BD. ¿Entonces? ¿por qué tanto Radius
Radius...?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
2:17 p.m.
En el caso que comento, se cacheaba las cuentas de usuarios, etc.. por lo
que si eran cuestiones sencillas como autenticación SIP no se consultaba a
BBDD nada mas que en el arranque o cuando había nuevas cuentas de usuario.
Saludos
On 1/30/08, Alberto Sagredo <info(a)voipnovatos.es> wrote:
Yo lo conozco de mi anterior experiencia laboral. Usabamos radius para la
autenticación generalizada de todo el sistema.
Y teníamos openser. El radius en este caso estaba en local. Es mucho más
rápido que MySQL y quizá Jesús pueda dar más datos :)
Saludos
On 1/30/08, Iñaki Baz Castillo <ibc(a)in.ilimit.es> wrote:
On Wednesday 30 January 2008 10:09:58 Iñaki Baz Castillo wrote:
En principio, la base de datos estaría en un
servidor a parte
(replicado y
esas cosas). Supongo que en caso de añadir la
capa Radius el servidor
estaría en el mismo host. En ese escenario, ¿qué ventajas tiene usar
Radius
teniendo en cuenta que no es imprescindible?
O sea, por velocidad no va a ser, porque si OpenSer tiene que hablar con
el
servidor Radius que a su vez consultará la BD esto será más lento que si
Openser consulta directamente la BD. ¿Entonces? ¿por qué tanto Radius
Radius...?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
2:22 p.m.
La "gracia" es tener un único punto de autentificación y autorización de
usuarios. Esto permite que todos los elementos del sistema que pretendan
verificar un usuario o perguntar si tiene suficientes permisos vayan a
preguntarselo al mismo tipo, ese tal radius.
Este control centralizado de usuarios permite tener un único punto donde los
usuarios estan definidos y permite aplicar políticas más facilmente que si
el "profile" del usuario esta diseminado por varios elementos.
Dado que la mayoría de aplicaciones pueden usar radius (webs, exchanges,SIP
proxies,intranets,queseyo...) y que éste define un estandard para la
autentificación y accounting (aparte de otras cosas) pues tiene su utilidad
ya que si añades un elemento nuevo que tenga compatibilidad con RADIUS para
autentificar usuarios no tienes que recrear las tablas de usuarios y puedes
utilizar las existentes.
Más o menos es algo así.....para más info tienes internete que lo sabe too,
Sam
2008/1/30, Iñaki Baz Castillo <ibc(a)in.ilimit.es>es>:
On Wednesday 30 January 2008 10:09:58 Iñaki Baz Castillo wrote:
En principio, la base de datos estaría en un
servidor a parte (replicado
y
esas cosas). Supongo que en caso de añadir la
capa Radius el servidor
estaría en el mismo host. En ese escenario, ¿qué ventajas tiene usar
Radius
teniendo en cuenta que no es imprescindible?
O sea, por velocidad no va a ser, porque si OpenSer tiene que hablar con
el
servidor Radius que a su vez consultará la BD esto será más lento que si
Openser consulta directamente la BD. ¿Entonces? ¿por qué tanto Radius
Radius...?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
2:23 p.m.
La "gracia" es tener un único punto de autentificación y autorización de
usuarios. Esto permite que todos los elementos del sistema que pretendan
verificar un usuario o perguntar si tiene suficientes permisos vayan a
preguntarselo al mismo tipo, ese tal radius.
Este control centralizado de usuarios permite tener un único punto donde los
usuarios estan definidos y permite aplicar políticas más facilmente que si
el "profile" del usuario esta diseminado por varios elementos.
Dado que la mayoría de aplicaciones pueden usar radius (webs, exchanges,SIP
proxies,intranets,queseyo...) y que éste define un estandard para la
autentificación y accounting (aparte de otras cosas) pues tiene su utilidad
ya que si añades un elemento nuevo que tenga compatibilidad con RADIUS para
autentificar usuarios no tienes que recrear las tablas de usuarios y puedes
utilizar las existentes.
Más o menos es algo así.....para más info tienes internete que lo sabe too,
Sam
2008/1/30, Iñaki Baz Castillo <ibc(a)in.ilimit.es>es>:
On Wednesday 30 January 2008 10:09:58 Iñaki Baz Castillo wrote:
En principio, la base de datos estaría en un
servidor a parte (replicado
y
esas cosas). Supongo que en caso de añadir la
capa Radius el servidor
estaría en el mismo host. En ese escenario, ¿qué ventajas tiene usar
Radius
teniendo en cuenta que no es imprescindible?
O sea, por velocidad no va a ser, porque si OpenSer tiene que hablar con
el
servidor Radius que a su vez consultará la BD esto será más lento que si
Openser consulta directamente la BD. ¿Entonces? ¿por qué tanto Radius
Radius...?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
2:24 p.m.
On Wednesday 30 January 2008 10:17:24 Alberto Sagredo wrote:
En el caso que comento, se cacheaba las cuentas de
usuarios, etc.. por lo
que si eran cuestiones sencillas como autenticación SIP no se consultaba a
BBDD nada mas que en el arranque o cuando había nuevas cuentas de usuario.
Gracias Alberto. Pero ¿cómo funcionaba ese cacheado? ¿lo hacía Radius?
OpenSer también puede usar cacheado para mantener en memoria usuarios y evitar
consulta BD. Y si se crea un usuario mediante "openserctl sdd..." entonces se
inserta primero en memoria y más tarde se sincroniza a BD.
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
2:41 p.m.
Realmente era un programa en perl que hablaba radius. No era propiamente un
servido de radius de los que hay por ahi. Era un programa de diseño propio.
Nunca me atreví a tocarlo ;)
On 1/30/08, Iñaki Baz Castillo <ibc(a)in.ilimit.es> wrote:
On Wednesday 30 January 2008 10:17:24 Alberto Sagredo wrote:
En el caso que comento, se cacheaba las cuentas
de usuarios, etc.. por
lo
que si eran cuestiones sencillas como
autenticación SIP no se consultaba
a
BBDD nada mas que en el arranque o cuando había
nuevas cuentas de
usuario.
Gracias Alberto. Pero ¿cómo funcionaba ese cacheado? ¿lo hacía Radius?
OpenSer también puede usar cacheado para mantener en memoria usuarios y
evitar
consulta BD. Y si se crea un usuario mediante "openserctl sdd..." entonces
se
inserta primero en memoria y más tarde se sincroniza a BD.
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
3:31 p.m.
Lo que sí hace radius es tener una "cache" de las últimas peticiones
recibidas de modo que si realizas muchas veces la misma petición, el
servidor no busca en la base de datos la respuesta porque ya la tiene.
Funciona de modo muy similar a la cache de las actuales bases de datos, yo
que sepa seguro mysql.
Ahora no recuerdo donde se configuraba pero fijo que hay unos parámetros por
ahi que controlaran el timeout i el tamaño de memoria de esta cache....
Pequeño matiz: cuando habla de radius, me refiero a FreeRadius, supongo que
otras implementaciones funcionarán de forma diferente.
sam.
2008/1/30, Alberto Sagredo <info(a)voipnovatos.es>es>:
Realmente era un programa en perl que hablaba radius. No era propiamente
un servido de radius de los que hay por ahi. Era un programa de diseño
propio.
Nunca me atreví a tocarlo ;)
On 1/30/08, Iñaki Baz Castillo <ibc(a)in.ilimit.es> wrote:
On Wednesday 30 January 2008 10:17:24 Alberto Sagredo wrote:
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
En el caso que comento, se cacheaba las cuentas
de usuarios, etc.. por
lo
que si eran cuestiones sencillas como
autenticación SIP no se
consultaba a
BBDD nada mas que en el arranque o cuando había
nuevas cuentas de
usuario.
Gracias Alberto. Pero ¿cómo funcionaba ese cacheado? ¿lo hacía Radius?
OpenSer también puede usar cacheado para mantener en memoria usuarios y
evitar
consulta BD. Y si se crea un usuario mediante "openserctl sdd..."
entonces se
inserta primero en memoria y más tarde se sincroniza a BD.
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
3:43 p.m.
Hola Iñaki,
On Wednesday 30 January 2008 10:09:58 Iñaki Baz
Castillo wrote:
Como ya han comentado antes, con Radius puedes centralizar toda la
política AAA de muchas aplicaciones, Openser entre ellas.
Desde el punto de vista de Openser la ventaja de radius con respecto a
mysql es que carga menos los servidores (es menos costoso enviar un
paquete UDP que hacer una query y eso cuando tienes muchas
transacciones por segundo se nota).
De todas formas, si quieres usar radius no tiene que ser un todo o
nada. Puedes tener la autenticación en mysql (sobre todo si usas el
modo de caché) y tener el accounting en Radius. Dependiendo del
servidor radius que utilices puedes usar como backend infinidad de
sistemas. Personalmente siempre recomiendo Radiator [1] que, aunque es
de pago, es el más versátil, potente, flexible y mejor servidor Radius
que he usado (y hace ya al menos 8 años que lo uso) y con un soporte
técnico mucho más que excelente (y el precio no es ninguna barbaridad).
La decisión de usar o no Radius creo que depende del volumen que
puedas tener y qué necesitas para tratar la información que te va a
generar y como la quieres tratar.
[1] http://www.open.com.au/radiator
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
En principio, la base de datos estaría en un
servidor a parte
(replicado y
esas cosas). Supongo que en caso de añadir la capa Radius el servidor
estaría en el mismo host. En ese escenario, ¿qué ventajas tiene
usar Radius
teniendo en cuenta que no es imprescindible?
O sea, por velocidad no va a ser, porque si OpenSer tiene que hablar
con el
servidor Radius que a su vez consultará la BD esto será más lento
que si
Openser consulta directamente la BD. ¿Entonces? ¿por qué tanto Radius
Radius...?
3:56 p.m.
On Wednesday 30 January 2008 11:43:40 Jesus Rodriguez wrote:
Como ya han comentado antes, con Radius puedes
centralizar toda la
política AAA de muchas aplicaciones, Openser entre ellas.
Desde el punto de vista de Openser la ventaja de radius con respecto a
mysql es que carga menos los servidores (es menos costoso enviar un
paquete UDP que hacer una query y eso cuando tienes muchas
transacciones por segundo se nota).
De todas formas, si quieres usar radius no tiene que ser un todo o
nada. Puedes tener la autenticación en mysql (sobre todo si usas el
modo de caché) y tener el accounting en Radius. Dependiendo del
servidor radius que utilices puedes usar como backend infinidad de
sistemas. Personalmente siempre recomiendo Radiator [1] que, aunque es
de pago, es el más versátil, potente, flexible y mejor servidor Radius
que he usado (y hace ya al menos 8 años que lo uso) y con un soporte
técnico mucho más que excelente (y el precio no es ninguna barbaridad).
La decisión de usar o no Radius creo que depende del volumen que
puedas tener y qué necesitas para tratar la información que te va a
generar y como la quieres tratar.
Gracias Samuel y Jesús. Me queda más claro y ya estoy en ello ;)
En cuanto al volumen que pueda tener... ¿por qué hacer algo sencillo y no
escalable podiendolo hacer a lo grande? XD
En cuanto al servidor Radius, de momento lo intentaré con FreeRadius debido a
que compañeros tienen experiencia con él.
Gracias a todos.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
4:10 p.m.
On Wednesday 30 January 2008 11:43:40 Jesus Rodriguez wrote:
De todas formas, si quieres usar radius no tiene que
ser un todo o
nada. Puedes tener la autenticación en mysql (sobre todo si usas el
modo de caché) y tener el accounting en Radius.
Una duda que me surge. Hasta donde me he enterado, si uso backend DB para
Radius (o use el que use) la información se guarda en tablas simples con
campos en plan:
- usuario - atributo - valor -
Es decir, si uso autenticación por Radius no podría usar la tabla "subscriber"
de OpenSer para nada, y el tema de administración de usuarios (aplicación web
y tal) se complicaría un pelín.
¿Me equivoco en algo?
En caso de estar en lo cierto creo que me decantaría, como sugiere Jesús, por
mantener a los usuarios en MySQL (tabla "subscriber"), por lo que la
autenticación sería vía MySQL, y el accounting vía Radius.
Y me surge duda en cuanto al módulo "group" y "avpops"
(tabla "usr_preferences") ya que esas tablas de por sí son de
tipo "usuario-atributo-valor" y no perdería nada por implementarlo en Radius.
Bueno, gracias de nuevo.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:03 p.m.
Hola,
On Wednesday 30 January 2008 11:43:40 Jesus Rodriguez
wrote:
Sí :)
Aún usando radius puedes usar la tabla subscriber para autenticar.
Simplemente le dices al radius qué campos tiene que usar en la query.
También puedes obtener en la misma respuesta del radius valores
adicionales (el equivalente al load_credentials del auth_db):
http://www.openser.org/docs/modules/1.2.x/auth_radius.html#AEN55
De todas formas, si quieres usar radius no tiene
que ser un todo o
nada. Puedes tener la autenticación en mysql (sobre todo si usas el
modo de caché) y tener el accounting en Radius.
Una duda que me surge. Hasta donde me he enterado, si uso backend DB
para
Radius (o use el que use) la información se guarda en tablas simples
con
campos en plan:
- usuario - atributo - valor -
Es decir, si uso autenticación por Radius no podría usar la tabla
"subscriber"
de OpenSer para nada, y el tema de administración de usuarios
(aplicación web
y tal) se complicaría un pelín.
¿Me equivoco en algo? En caso de estar en lo cierto creo que me decantaría,
como sugiere
Jesús, por
mantener a los usuarios en MySQL (tabla "subscriber"), por lo que la
autenticación sería vía MySQL, y el accounting vía Radius.
Y me surge duda en cuanto al módulo "group" y "avpops"
(tabla "usr_preferences") ya que esas tablas de por sí son de
tipo "usuario-atributo-valor" y no perdería nada por implementarlo
en Radius.
Si tu servidor MySQL aguanta lo que le echen, yo dejaría el accounting
en Radius y el resto en el MySQL :) . Si llegas al punto en el que
tienes que afinar tanto que una query puede marcar la diferencia,
entonces siempre puedes pasar al radius.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
5:29 p.m.
On Wednesday 30 January 2008 13:03:13 Jesus Rodriguez wrote:
Vaya, es cierto, además lo acabo de comprobar viendo que la query que hace
FreeRadius para autenticación es totalmente configurable.
Creo que tiraré por ahí (powered by KISS) ;)
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Una duda que
me surge. Hasta donde me he enterado, si uso backend DB
para
Radius (o use el que use) la información se guarda en tablas simples
con
campos en plan:
- usuario - atributo - valor -
Es decir, si uso autenticación por Radius no podría usar la tabla
"subscriber"
de OpenSer para nada, y el tema de administración de usuarios
(aplicación web
y tal) se complicaría un pelín.
¿Me equivoco en algo?
Sí :)
Aún usando radius puedes usar la tabla subscriber para autenticar.
Simplemente le dices al radius qué campos tiene que usar en la query. En caso de
estar en lo cierto creo que me decantaría, como sugiere
Jesús, por
mantener a los usuarios en MySQL (tabla "subscriber"), por lo que la
autenticación sería vía MySQL, y el accounting vía Radius.
Y me surge duda en cuanto al módulo "group" y "avpops"
(tabla "usr_preferences") ya que esas tablas de por sí son de
tipo "usuario-atributo-valor" y no perdería nada por implementarlo
en Radius.
Si tu servidor MySQL aguanta lo que le echen, yo dejaría el accounting
en Radius y el resto en el MySQL :) . Si llegas al punto en el que
tienes que afinar tanto que una query puede marcar la diferencia,
entonces siempre puedes pasar al radius.
5941
days inactive
5941
days old
sr-users-es@lists.kamailio.org
13 comments
4 participants
participants (4)
-
Alberto Sagredo -
Iñaki Baz Castillo -
Jesus Rodriguez -
samuel