[OpenSER-Users-ES] OpenSer y Radius
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@in.ilimit.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@in.ilimit.es
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@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@in.ilimit.es
_______________________________________________ Users-es mailing list Users-es@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. Saludos On 1/30/08, Alberto Sagredo <info@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@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@in.ilimit.es
_______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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@in.ilimit.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@in.ilimit.es
_______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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@in.ilimit.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@in.ilimit.es
_______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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@in.ilimit.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@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@in.ilimit.es
_______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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@voipnovatos.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@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@in.ilimit.es
_______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
_______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Hola Iñaki,
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...?
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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
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@in.ilimit.es
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@in.ilimit.es
Hola,
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?
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
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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
On Wednesday 30 January 2008 13:03:13 Jesus Rodriguez wrote:
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.
Vaya, es cierto, además lo acabo de comprobar viendo que la query que hace FreeRadius para autenticación es totalmente configurable.
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.
Creo que tiraré por ahí (powered by KISS) ;) Gracias. -- Iñaki Baz Castillo ibc@in.ilimit.es
participants (4)
-
Alberto Sagredo -
Iñaki Baz Castillo -
Jesus Rodriguez -
samuel