Is it possible to access one SecurityContext from another?

mhoffmann

Hi,

I currently have a project where I'd need to copy a role structure and members from one SecurityContext to another.

Application A has a process for CRUD of these roles.
Application B now needs the same structure which should be a copy of Application A.

The SecurityContexts have an intersection but have to be separated.

Neither ISecurityContext nor the Ivy god object seem to expose a functionality for accessing a different SecurityContext other than the current application's SecurityContext.

My 'bypass' would be to query the structure from the SystemDatabase itself and rebuild it with a service method in Application B.

Is there a better way to have shared role structures between two SecurityContexts or to mirror the roles or is my approach the only option currently?

Best wishes
Mario

Alexander Suter

mhoffmann In general, the main idea behind security contexts is that they should remain isolated and not interact with each other. So, why don’t Application A and Application B live in the same security context?

mhoffmann

Alexander Suter
Because they are two completely different departments in the company.

Application A is an application for quality management.
Application B is an invoicing application.

These applications also have a different set of users, roles, visibility rules etc. and don't really share anything other than one role tree.

This is further to ensure that the users and roles are kept isolated to their specific application since an intersection like this is rather rare, even at this rather big company.

Another reason is that the branding was (or might still, didn't check that in quite some time) be dependent on the context itself.

For this concrete example here: the customer has a rather creative organisation. The customer’s LDAP structure does not model these organizational relationships in a way we can directly reuse - otherwise the whole CRUD process wouldn't even exist and I could just use the groups from LDAP to bind the roles to; it would be the cleanest way without any doubt.

The shared roles are basically a tree of purchaser roles which are structured by department - that's probably also making clear why they have a function in both applications. Adding unwanted complexity, these teams are named by a combination of last names and referred to it like that at this customer, which adds quite a lot of complexity since they also can change when the members change.

When I rethink this, I probably might just change the CRUD process to not write into the SecurityContext directly but rather store it into a database and then build the role structure and set the members from a generic process which works in both application if there's so easy way available to access the SecurityContext from another application.

I further understand your point though, this example might be "special" to begin with. When you have one specific workflow portal for a customer, I think your point is more than valid. But when you don't want certain people to even have access to an application they shouldn't be able to access, I'd argue that a shared SecurityContext doesn't always make sense.

Thanks for your input!

Alexander Suter

mhoffmann Interesting use case! In the vast majority of use cases, we generally recommend running only one single security context.

The challenge here is that if a user needs to work in both applications for some reason, they also need to be created in both security contexts. The engine therefore treats them as two separate identities, even though they represent the same user. This makes it more difficult to maintain, for example, a clean audit trail per user.

With the role-based approach, you can restrict visibility accordingly. However, there may still be some missing functionality that would be required to properly support your use case with a security system. I’d be very interested to hear what those requirements are.

That said, even if all the necessary features were available, changing the system accordingly would still be a significant effort.

As a quick workaround, "ISecurityContextRepository" might be worth looking into. However, please note that this is not an official API.

mhoffmann

Alexander Suter
I understand this approach, yet it often strikes me as a violation of the principle of least privilege, but I really understand that there are different views and approaches about it. For me, it has an uncanny feeling to define a user base (security context) for an application which contains more than the users which should be allowed to access the application. It further allows us to define user / role permission based on the application context and not globally for all applications using it. I personally would argue that e.g. the HR department shouldn't even be able to access the QM's application / portal and as far as I know, this can't be limited when sharing a security context. Many roads lead to Rome here, I'd say.

Regarding the audit trail: Since a user has a uniquely defined primary key from the external security provider, I doubt this should be much of an issue.

The requirement here basically is that these roles have no primary key or have a mapping outside of our Axon Ivy application - you can't refer to them by any meaningful, stable way. Once one of the key personell changes, the role gets a different name (in the background we keep a simple integer as identifier) and this change is also implemented manually. I'll be honest, I think this is solely an organisational issue, not a technical one.

Thanks for providing a workaround which would work, but I'm a bit branded by my experience with the removed access to the IProjectProcessManager with Axon Ivy 12 - I therefore rather build things which work with any public API these days.

Anyway, if I have to implement it in a hurry, your hint is really worth a lot. So I really appreciate it.

Best wishes & a nice weekend
Mario

spWS

Hi all,

following up on this thread, we have a related but slightly different use case that touches on the same SecurityContext questions.

We're building a portal for a customer where that customer wants to invite their own end customers. These end customers should then be able to do self-service, e.g. maintaining their own master data and starting order processes. On top of that, the customer wants to provision these end customers's users using their own Entra ID / Active Directory.

Our idea was to split this into:

one SecurityContext for the portal administration itself (our customer's internal admins managing the portal, onboarding end customers, etc.), and
one separate SecurityContext for each end customer, so that each end customer's users, roles and Entra ID/AD connection stay fully isolated from one another and from the portal admin context.

Essentially, we're trying to achieve tenant isolation (each end customer only ever sees their own users/data) while still giving the portal operator a central place to administer the end customers and work on tasks.
Would appreciate any guidance on whether this is a recommended architecture, or if there's a better pattern for this kind of multi-tenant portal scenario.

Thanks in advance!

mhoffmann

spWS

Depending on the amount of customers, I personally think this isn't a great idea to begin with to define a SecurityContext and application for every customer.

IIRC, you can only setup these contexts properly in the Engine Cockpit - something I'd argue a customer shouldn't be allowed to access.

If your order process is a simple ordering form without any back-routing (Tasks) to the customer, I'd overthink the approach completely and probably rather use a dedicated web app for the customer application and push its data to the internal Axon Ivy engine to start a process per order.

Lukas Lieb

I would also recommend to something similar.

Use one security system per customer.

Currently, it is not possible to restrict cockpit usage. So it is not possible, e.g., to add admins that can only see and change stuff in one security context. So I would not recommend giving a customer access to it.

It is also not possible to have one portal for all security systems. However, it is possible to add manual users to a security system. So you can e.g. add your portal admin user to each security system so it can log in to each customer's portal.