Problem 1: I am integrating Camunda workflow engine in my spring boot application. I have users in a separate business db and need to sync it with Camunda workflow engine to assign the users to particular tasks. The users in the business db are not categorized to groups but have certain roles. I want to sync these roles with the groups in Camunda.
Problem 2: I also want only the assigned users to be able to complete the tasks via REST localhost:8080/rest/task/{id}/complete
How can I be able to achieve this? I cannot find a solid guide that can help me.
Edit: I am able to load the users from my business db to Camunda using this example https://github.com/hashlash/example-camunda-custom-identity-service. This solves problem 1.
Now, I need a way to make sure only the assigned user can complete the assigned task via authorization i.e. Problem 2. Any guides on this?
I don't know if I understood what you want. But I think it makes more sense to associate your users with authorizations than with groups.
If you define in your UserTask the attributes Assignee, Candidate User or Candidate Groups, Camunda will automatically create the authorization for you.
I think you have some additional information on this link:
Additional Task Permissions
You seem to be on the right track. By default Camunda is configured not to enforce authorizations. You need to enabled it using the property:
camunda: bpm:
authorization:
enabled: true
(RE the previous comment: it is better to assign the Camunda authorizations to groups and get the assignment of users to groups from the external identity provider. This way fine grain application-specific authorization management remains in the application.)
Related
We are developing a multitenant application with shared schema for a web application. I would like to know the best practices for designing UI strategies.
We will have different roles for saas owners like Adminsitrators, Helpdesk, Account Manager so The SAAS owner may need to have multiple users who will acess the application and do their job.
HelpDesk: If a tenant put up a ticket, helpdesk team shall be able to view and solve.
Account management: Account Managers may need to access the payment information of the tenants for following up the tenants.
ServiceManagers: To perform maintenance and upgrades etc.
In this case
Do we need to have different UI for "Saas owner" and "Tenants" or is it better to manage it with permissions and roles?
Any best practices?
There are many facets to decide on the mode of delivery
In case you prefer to use Micro FrontEnds, admin and tenant functions can be separate. However, the individual functions like help desk,Accounts management can be a separate micro frontend
There should be options for a tenant to white label the UI (custom logo, custom theme, custom layout (more development effort)) etc.
With or without micro frontends, your UI layer should be working based on the permissions that comes as an aggregation of the user's roles (even across tenants).
The UI always has probes to the API to get the permissions and render the various UI components based on the granted permissions to the user.
We used to build custom UI components like custom grid, custom forms etc so that the permissions could be used to show or hide the various UI elements based on the permissions that a user might posses.
Ex: In the context of a Administrator, I will be able to see all the team members, but in the context of a Service Administrator, I will be able to assign members to various tenant functions like help desk, accounting etc which the Administrator will not be able to perform, but can view the mappings.
Similarly, your business requirements will drive the UI, hence if you follow using the permissions for the UI, it is always very fine-grained and easy to manage than depending upon higher levels of abstraction like Roles.
HTH
we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
I know that Spring Security has a lot of role-based authorization capability. But what if I have two ordinary users accessing data. How do I keep User A from seeing records belonging to User B? For example, keeping User A from seeing the orders created by all other users?
Please note that this is NOT role-based authorization. User A and User B, etc., are all ordinary users, differing only in their identities.
In an existing Spring application I'm currently getting the job done with a filter in each DAO, ensuring that "... and user_id = $1 ..." is part of the queries. This also reduces the volume of fetched data, lowering database access costs.
In the future I will be breaking up my application into microservices. It seems to me that each microservice request must also have the UserDetails information. This sounds like an anti-pattern.
An API gateway would merely be a consumer of the approaches that I previously mentioned. So, is passing the UserDetails information to each microservice my best approach?
I hope the answer is not "create a role for each ordinary user, like "ROLE_USER_A", "ROLE_USER_B", etc.
Thanks,
Jerome.
In an existing Spring application I'm currently getting the job done
with a filter in each DAO, ensuring that "... and user_id = $1 ..." is
part of the queries. This also reduces the volume of fetched data,
lowering database access costs.
This is the correct approach
In the future I will be breaking up my application into microservices. It seems
to me that each microservice request must also have the UserDetails
information. This sounds like an anti-pattern.
There are several approaches you an use here. You could use spring security oauth, and separate the authentication server out into it's own component. Then the credentials will be stored in a central location. This will save you from having to pass the credentials around.
Another approach would be using perimeter security. Basically your gateway service would authenticate each request and then pass the user details to each component.
There are other approaches, but these two are pretty common.
I've got a spring application set up with spring security. I've got my service methods annotated with #PreAuthorize(...). So everyone from the web needs some specific rights to access those methods, which is fine.
But now I've got a new use case. There's a #Scheduled method running to do some checks and send messages. Currently only people with ROLE_USER are allowed to send messages. But now also the application itself has to send those messages.
How should I manage to have some kind of invisible user (= the application), which is logged in all the time and has specific rights? Or maybe "all rights" would be nice as well, so it just ignores all those security annotations.
Or maybe I don't need a "user" at all?
Thanks for your help!
EDIT: The main 2 questions are:
Should I create a real user for the application? Means: An entry in the user table of the database? How did you solve this? Maybe you do simply use the user account of the admin user (which is a real person)?
If I now have this "system" user. What's the best way to "use" it? For example I'd use #Autowired User systemUser to access this user wherever I need it. (Of course there's some point in the application config where I create a bean with this specific user).
EDIT2: Some more thoughts:
I think in the future I want to send messages from different subsystems of the application. So it's no choice to use the admin user, because I need a few different users with different names.
I was faced with similar problem and the solution I implemented was an internal and an "external" service implementation. The external one has the internal one autowired in. Any application-internal component, like your scheduled job, would have the internal service wired in. Any Web-exposed components would have the secured "external" service wired in, which would have the #PreAuthorize etc. annotations in place, but otherwise would act just as a delegate to the internal service.
I also log, before passing message onto the internal service, the principal of the authentication object which was used for authorization. You know you'll have one available in the SecurityContext, so pick it out and just make a note in your logs of someone external invoking internal services. I do the below (your principal could be non-username, but still, wanted to share):
final String currentUser = SecurityContextHolder.getContext().getAuthentication().getPrincipal().toString();
I think that all the answers you provided are fairly common solutions, so it depends very much on your requirements. The app I'm working on has some intense audit requirements so we have a user set up for the application itself to use when it needs to invoke services through a scheduler. This allows us to log against a given principle. Perhaps you should clarify your requirements?
We are upgrading a single-tenant application to a multi-tenant (separate DB for each client) SaaS application. My responsibility is to design the tenant provisioning part. I am thinking of the following steps.
While our admin will install our software, one DB should always be get created.Argument for this step is that Admin will install the software only when at least a tenant comes up. So, creation of a single db as part of installation of our software should make sense.
The common meta data will be stored in a common place. We are thinking of using ZooKeepar to store the common meta data.
Each tenant will be given a subdomain. For example www..samplaTenent.com . This tenant_id will be extracted from the URL in each request and will be used to identify the particular tenant and respective DB.
If more tenants need to be provisioned, the admin will create a new DB instance through user interface.
Technology used:
Java 6
Struts Framework
MS SQL
Now, I would like to get expert opinion about the proposed solutions. Is there any other way by which we can build a robust, secure and scale-able SaaS application?
Thanks.
IMHO, I would suggest that you should have a sibgle code base that can handle the multi-tenancy aspects be it configuration of db, settings per tenant etc.. I am not aware of the code base that you have now. Hence, you can make the provisioning part as follows,
You provision a new tenant by getting all the prerequisite info. You can generate the URL for this tenant automatically or allow the tenant to choose one in the latter a validation has to be made for the URL and the tenant combination.
On this step completion, you can have some scripts at the server that clones a master code base and rolls out a new tenant specific db. So things are automated.
The next step will be to store the tenant db and the app details in your common or shared db so that when a tenant logs in, you can redirect him to his URL. The db details will be required if you want to handle all of the tenant and his user authentication from the main app.
The main perceived advantage of having a single code base is that the customization and configuration can be in one place with ease of code maintenance and bug fixing or enhancing. Though this may not work for all scenarios, this is what I feel more suitable option on the long run.
Please share your thoughts or post additional queries that you may have on multi-tenancy.