Additional datastore for CUBA core tables

Hi,

We have an IDP and several SPs, in IDP we have sec$user extended, and we want that customer info only kept in IDP so that we don’t need duplicate user info in different databases and avoid data sync between IDP and SPs. But in SP, we have BPM integrated, in which it requires sec$user associated with work flow entities. Hence the idea come to us is to use sec$user as external source in additional data store.

However, I have impress that Konstantin mentioned in a post that CUBA core tables, e.g. sec$user, should be in main datastore. So we gave it a try yesterday, in studio it generates external entity SecUser:

@DesignSupport("{'imported':true}")
@NamePattern("%s|name")
@Table(name = "sec_user")
@Entity(name = "fillprod$SecUser")
public class SecUser extends BaseUuidEntity implements Versioned, SoftDelete, Updatable, Creatable {
    private static final long serialVersionUID = -228774808472332738L;

    @Column(name = "login", nullable = false, length = 50)
    protected String login;

    @Column(name = "login_lc", nullable = false, length = 50)
    protected String loginLc;

    @Column(name = "password")
    protected String password;
...

So, my question is, will it work? if yes, how should we integrate external SecUser with BPM? if no, any suggestion?

Thank you!

1 Like

Answering your question directly, I should say that there is no way to “substitute” the sec$User entity with some other entity located in a different data store. But if you explain your task in more detail, we could try to propose a solution.

Do I understand you correctly that in BPM of an SP you need to work with the information that is stored in extended fields of the User entity of the IDP?

Hi Konstantin, thank you for your reply!
I am planing a solution with server architect as in the picture below. As my SP servers needs to refer sec$user@idp datastore, like BPM entities, and roles, access group, and my own business logic in SPs.

As there are multiple SP servers, so I don’t want to sync sec$user data from idp datastore to SP datastores, that’s also why i have an IDP server.

So is it possible to have the SP servers directly use sec$user in idp store?

I also think about to have one uniform DB for IDP and all SPs, but considering that may hard to scale as business grows.

I also think about have one DB for user/role/bpm things, and my business logic in another datastore; but BPM table also refer to business entity.

Looking forward to your advice :blush:

image

Let me first clarify something about how CUBA SSO works. An IDP only authenticates users, all subsequent authorization is done on SPs, so they need the same user records as on IDP, but they can have different attributes (except login), different sets of roles, etc. So SSO is not a centralized security system, it’s just a way for users to login once.

In theory, you could use a single database for all apps as their main data store, and hence share the users and other system data. But we have no experience with such approach and I cannot predict possible pitfalls. An obvious downside is the need to place application entities to additional data stores, so you won’t be able to generate DDL scripts for them in Studio.

I still think that the right way is to replicate users in some form between IDP and SPs. If users are modified only on IDP, it will be a simple single-master replication without any possible conflicts. You can implement it right in the application, for example by using entity listeners for security entities sending modified instances to some queueing mechanism.

This way your system will be more loosely coupled and more robust in case of network or servers issues.

Thanks Konstantin for your detailed explanation! You are right, we understood IDP incorrectly from the beginning, we hope it could be something like security center.

With your suggestions, now it’s clear to us that we will implement message queue in SP to sync sec$user. So that our SP can be running on separate database from IDP. This looks great and clear architecture.

Thank you again!