You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Kambiz Darabi <da...@m-creations.com> on 2016/05/12 11:31:06 UTC
Isis security module questions
Hi,
we are trying to use the security module which would be a perfect fit
for our needs if it had a fully LDAP based implementation.
To make things even more difficult, we are building up an infrastructure
where several domains with separate databases exist.
Problem 1: the JDO annotations of the domain objects in the module
obviously don't use the DataNucleus extension to specify a different
data store than the default one.
This leads to users/roles being created in the 'default data store' of
the respective service and we are not easily able to redirect the
security related persistence towards a central 'security database'.
Problem 2: a fully LDAP based implementation is what the customer needs
If an LDAP backend is present in a company, then one would expect to
handle all of the authentication/authorisation issues on that side
without the need to have an additional database which might get out of
sync with the single source of truth which should be LDAP.
We have found out that DataNucleus even has an LDAP data store
implementation.
Would it be possible to implement a fully LDAP based backend for the
security module? We would be willing to invest some effort, if you could
guide us on how to tackle the problem.
Thanks
Kambiz
Kambiz Darabi
--
m-creations gmbh
Acker 2
55116 Mainz
Germany
W: http://www.m-creations.com
E: darabi@m-creations.com
T: +49 6131 6224417
F: +49 6131 6224418
--
Registered Office: Mainz, HRB Mainz 7382
Managing Directors: Frank Pacholak, Kambiz Darabi
Re: Isis security module questions
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Kambiz,
appreciate that this thread has fallen by the wayside. I've created a
ticket on the security addon so at least it doesn't get forgotten; please
comment there.
Thx
Dan
https://github.com/isisaddons/isis-module-security/issues/37
On 16 May 2016 at 07:30, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi Kambiz,
>
> Sorry not to reply sooner, have been finishing off work on the new
> InteractionContext stuff (see email just posted to users@ mailing list).
>
> As to your request, have no problem in helping break out the security
> module to allow different persistence implementations. My thinking is that
> I'll factor out some interfaces etc (as Oscar was suggesting) then you guys
> can plug in your own impl.
>
> To do this properly will probably require that the current single "dom"
> artifact will need to break into several different submodules. That might
> require some minor updates to pom.xml and AppManifests, but nothing too
> onerous, I think.
>
> Let me look at it in more detail over the next couple of days.
>
> Thx
> Dan
>
>
> 2016-05-13 16:01 GMT+01:00 Óscar Bou - GOVERTIS <o....@govertis.com>:
>
>> Hi Kamiz,
>>
>> The interface (or abstract class) would be on the Isis Security add-on
>> and your custom implementation on your own Domain jar (despite we could
>> also provide it as an anternative implementation on the security add-on
>> afterwards).
>>
>>
>>
>>
>> El 13 may 2016, a las 16:10, Kambiz Darabi <da...@m-creations.com>
>> escribió:
>>
>> Hi Óscar,
>>
>> On 2016-05-12 17:17 CEST, Óscar Bou - GOVERTIS <o....@govertis.com>
>> wrote:
>>
>> Regarding Users and Roles current implementation, perhaps we could
>> refactor it using interfaces, giving:
>> - a default implementation (the current JDO-based one that persists to
>> the database).
>> - a new one based on the DN LDAP repository support, extending that
>> interface, that you could implement ...
>>
>>
>> Do they have to be separated into different dependencies (= jars)?
>> Or what is the correct way of avoiding the automatic mapping of the
>> JDO annotated classes to the current default data store?
>>
>> Could this approach help?
>>
>>
>> Definitely.
>>
>> The Shiro realm would use LDAP attributes to handle
>> authentication/authorization.
>>
>>
>> Yes, LDAP users and group membership information.
>>
>> Cheers
>>
>>
>> Kambiz
>>
>>
>>
>> Óscar Bou Bou
>> Socio - IT & GRC Management Services Director
>> m: +34 620 267 520
>> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>>
>> LinkedIn: https://www.linkedin.com/in/oscarbou
>> Twitter: @oscarbou <https://twitter.com/oscarbou>
>>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan
>> en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya
>> finalidad es la de mantener el contacto con Ud. Si quiere saber de qué
>> información disponemos de Ud., modificarla, y en su caso, cancelarla, puede
>> hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su
>> D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda
>> Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la
>> Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar
>> que este mensaje o sus archivos adjuntos no contengan virus informáticos, y
>> en caso que los tuvieran eliminarlos.
>>
>>
>
Re: Isis security module questions
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Kambiz,
Sorry not to reply sooner, have been finishing off work on the new
InteractionContext stuff (see email just posted to users@ mailing list).
As to your request, have no problem in helping break out the security
module to allow different persistence implementations. My thinking is that
I'll factor out some interfaces etc (as Oscar was suggesting) then you guys
can plug in your own impl.
To do this properly will probably require that the current single "dom"
artifact will need to break into several different submodules. That might
require some minor updates to pom.xml and AppManifests, but nothing too
onerous, I think.
Let me look at it in more detail over the next couple of days.
Thx
Dan
2016-05-13 16:01 GMT+01:00 Óscar Bou - GOVERTIS <o....@govertis.com>:
> Hi Kamiz,
>
> The interface (or abstract class) would be on the Isis Security add-on and
> your custom implementation on your own Domain jar (despite we could also
> provide it as an anternative implementation on the security add-on
> afterwards).
>
>
>
>
> El 13 may 2016, a las 16:10, Kambiz Darabi <da...@m-creations.com>
> escribió:
>
> Hi Óscar,
>
> On 2016-05-12 17:17 CEST, Óscar Bou - GOVERTIS <o....@govertis.com> wrote:
>
> Regarding Users and Roles current implementation, perhaps we could
> refactor it using interfaces, giving:
> - a default implementation (the current JDO-based one that persists to
> the database).
> - a new one based on the DN LDAP repository support, extending that
> interface, that you could implement ...
>
>
> Do they have to be separated into different dependencies (= jars)?
> Or what is the correct way of avoiding the automatic mapping of the
> JDO annotated classes to the current default data store?
>
> Could this approach help?
>
>
> Definitely.
>
> The Shiro realm would use LDAP attributes to handle
> authentication/authorization.
>
>
> Yes, LDAP users and group membership information.
>
> Cheers
>
>
> Kambiz
>
>
>
> Óscar Bou Bou
> Socio - IT & GRC Management Services Director
> m: +34 620 267 520
> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>
> LinkedIn: https://www.linkedin.com/in/oscarbou
> Twitter: @oscarbou <https://twitter.com/oscarbou>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya finalidad
> es la de mantener el contacto con Ud. Si quiere saber de qué información
> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a
> la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes
> Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la Castellana,
> 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este
> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
> que los tuvieran eliminarlos.
>
>
Re: Isis security module questions
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi Kamiz,
The interface (or abstract class) would be on the Isis Security add-on and your custom implementation on your own Domain jar (despite we could also provide it as an anternative implementation on the security add-on afterwards).
> El 13 may 2016, a las 16:10, Kambiz Darabi <da...@m-creations.com> escribió:
>
> Hi Óscar,
>
> On 2016-05-12 17:17 CEST, Óscar Bou - GOVERTIS <o....@govertis.com> wrote:
>
>> Regarding Users and Roles current implementation, perhaps we could
>> refactor it using interfaces, giving:
>> - a default implementation (the current JDO-based one that persists to
>> the database).
>> - a new one based on the DN LDAP repository support, extending that
>> interface, that you could implement ...
>
> Do they have to be separated into different dependencies (= jars)?
> Or what is the correct way of avoiding the automatic mapping of the
> JDO annotated classes to the current default data store?
>
>> Could this approach help?
>
> Definitely.
>
>> The Shiro realm would use LDAP attributes to handle
>> authentication/authorization.
>
> Yes, LDAP users and group membership information.
>
> Cheers
>
>
> Kambiz
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: Isis security module questions
Posted by Kambiz Darabi <da...@m-creations.com>.
Hi Óscar,
On 2016-05-12 17:17 CEST, Óscar Bou - GOVERTIS <o....@govertis.com> wrote:
> Regarding Users and Roles current implementation, perhaps we could
> refactor it using interfaces, giving:
> - a default implementation (the current JDO-based one that persists to
> the database).
> - a new one based on the DN LDAP repository support, extending that
> interface, that you could implement ...
Do they have to be separated into different dependencies (= jars)?
Or what is the correct way of avoiding the automatic mapping of the
JDO annotated classes to the current default data store?
> Could this approach help?
Definitely.
> The Shiro realm would use LDAP attributes to handle
> authentication/authorization.
Yes, LDAP users and group membership information.
Cheers
Kambiz
Re: Isis security module questions
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi, Kambiz.
Interesting.
Regarding Users and Roles current implementation, perhaps we could refactor it using interfaces, giving:
- a default implementation (the current JDO-based one that persists to the database).
- a new one based on the DN LDAP repository support, extending that interface, that you could implement [1].
Could this approach help?
@Dan
perhaps some alternative/complementary approach based on mixins contributing also to domain entities “marked” with those Interfaces?
The Shiro realm would use LDAP attributes to handle authentication/authorization.
HTH,
Oscar
[1] http://www.datanucleus.org/products/datanucleus/datastores/ldap.html
> El 12 may 2016, a las 13:31, Kambiz Darabi <da...@m-creations.com> escribió:
>
> Hi,
>
> we are trying to use the security module which would be a perfect fit
> for our needs if it had a fully LDAP based implementation.
>
> To make things even more difficult, we are building up an infrastructure
> where several domains with separate databases exist.
>
> Problem 1: the JDO annotations of the domain objects in the module
> obviously don't use the DataNucleus extension to specify a different
> data store than the default one.
>
> This leads to users/roles being created in the 'default data store' of
> the respective service and we are not easily able to redirect the
> security related persistence towards a central 'security database'.
>
> Problem 2: a fully LDAP based implementation is what the customer needs
>
> If an LDAP backend is present in a company, then one would expect to
> handle all of the authentication/authorisation issues on that side
> without the need to have an additional database which might get out of
> sync with the single source of truth which should be LDAP.
>
> We have found out that DataNucleus even has an LDAP data store
> implementation.
>
> Would it be possible to implement a fully LDAP based backend for the
> security module? We would be willing to invest some effort, if you could
> guide us on how to tackle the problem.
>
> Thanks
>
>
> Kambiz
>
>
> Kambiz Darabi
> --
> m-creations gmbh
> Acker 2
> 55116 Mainz
> Germany
>
> W: http://www.m-creations.com
> E: darabi@m-creations.com
> T: +49 6131 6224417
> F: +49 6131 6224418
> --
> Registered Office: Mainz, HRB Mainz 7382
> Managing Directors: Frank Pacholak, Kambiz Darabi
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.