spi-security: Different datastore for datatables, also LDAP implementation

[danhaywood]

from https://github.com/isisaddons-legacy/isis-module-security/issues/37

Kambiz wrote:

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

[danhaywood]

Oscar commented:

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

[danhaywood]

Kambiz replied:

Hi Óscar,

On 2016-05-12 17:17 CEST, Óscar Bou - GOVERTIS o.bou@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

[danhaywood]

Oscar wrote:

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).

[danhaywood]

Dan 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.