My application has currently two types of users: Admin or Normal user.
The application has several projects: 100 or more. Per project the user has a different role like project owner, client, etc...
I'm now figuring out the best way to put those subroles in place.
Because in my services I want to use PreAuthorise("hasRole('OWNER')") so that only the right people can execute an update or whatever.
What I was trying now was giving every project a list of users that are working on it with a roles (project owner, client, etc...) when I login via Spring Security I retrieve the user and fetch all the projects where he is part of and then I add roles as follows ROLE_PROJECTNAME_OWNER or ROLE_PROJECTNAME_CLIENT.
The thing is that I can't use the HASROLE because there are a lot of projects so I can't annotate in advance which projects there are to allow a method call in my service layer. I also can't just add OWNER because then I don't know in which project. So I'm a little bit stuck here how to do this properly.
Define your own service to manage access with user/project/role and call this service directly on your #PreAUthorize.
Have a look to : https://dreamix.eu/blog/java/implementing-custom-authorization-function-for-springs-pre-and-post-annotations
Why don't you separate your users and the groups they form part of, from the roles and services they can access.
There are various ways you can do this, but one approach is to have the central authentication framework provide you the groups of the user once he performs authentication.
Now within each service, there will be a mapping between groups and roles. The roles are application specific, the authentication service or the other applications do not care about them. You might store this mapping in the individual application's database, or in a simple configuration file (maybe simply in application.yaml of the specific application).
Your groups currently are Admin and Normal but you could have others. A user could also be a member of multiple groups. So in application 1 you could say that Admin users can do role 1, role 2, role 3, while Normal users can only do role 1. Again it is many to many. This is something your UserDetails instance would carry once it recognizes the authenticated user and his groups, which are then mapped to roles as part of your Spring Security configuration. You will then be able to do PreAuthorise("hasRole('OWNER')") etc. on your services.
This way, if you add more users, you just put them in the right groups to give them access to the individual services. If you want to create new profiles, instead of just Admin and Normal, or special groups, you just do it once and update the configuration of the individual application to recognise that group if it is relevant to it (remember the user can be a member of multiple groups, so you don't even need each application to know about each group).
I don't know what mechanism you are using for single sign on authentication. But in spirit of microservices and minimal sharing between applications, you could actually put the groups as scopes in your token (if you are using JWT for example). This way the application receiving the token not only knows that the user was authenticated but knows the groups of the user without even making a query to any other system.
This architecture you will have is shown in the picture.
Each use case (service method annotated with #PreAuthorise) will have a role.
Each user will be associated with a number of groups the authentication system will provide. (For example groups in Active Directory). Upon receiving the authentication information of the user, the groups will be mapped to the roles specific to the application and populated in the UserDetails Spring Security object. Each annotated method will then get the application specific roles (not the global groups).
This gives you the flexibility to add as many groups as you like that can have the same application role.
Related
We have a multi-tenant (used by multiple organizations) application in Java Spring Boot. We have to implement authentication as well as authorization in such a way that;
There can be multiple users in an organization and a user can also be part of multiple organizations.
At a time user can view data of only one organization but he can simply switch between organizations.
In an organization, there can be multiple teams.
A user can have different level of access/permissions for each team. Like maybe a user A is manager of team 1 and same time he can be member of team 2 etc.
We are planning to use keycloak for IAM. So the question is, either this type of access management will be possible to achieve in keycloak or we have to manage these permissions on database level in code? And for multi-tenancy, a separate realm for each tenant will be good or we should go for single realm and multiple groups?
Looking for expert opinions.
So, I have three users in my oracle database: user_role, admin_role, provider_role. They have access to execute different procedures. Also, I have a Spring boot app with a login page. How can I change my connection to the database according to the database role?
In your data model, you should introduce a concept called permissions and roles. A role can hold multiple different permissions. You don't need three different tables like user_role, admin_roles, and provider_role. Just create a single table for users, another tables for roles and permissions. For every user there will be at least one role and each role can hold multiple permissions.
Your SpringBoot application should have an authorization layer. All the execution path should goes through this authorization layer. All your model(DB) layer access, constrained with the permissions allowed for different type of users. That gate keeping task is going to be taken care by your authorization layer in your service.
I need to create an application with authentication and authorization using Java EE 6 (Glassfish Server). I read a lot about Java EE 6 security and just wanted to ask if my concept is correct:
Every user in the company has an account according to "X123456". I want to use this for LDAP Authentication:
Application ---> LDAP
So, I can use the company's infrastructure to authorize the user.
However I want to be in control of the roles in my application. So, I want to define my own roles using JACC. Therefore I will create a database with a user-to-role mapping,
Example: "X123456 -> ADMIN".
The benefits would be:
I don't need to store any password
I can create a kind of admin panel in my application where I can set the existing roles to users dynamically
Do you think this would be technically possible and good practice?
Alternative: Would it be possible to define the roles (Admin, User) in Active Directory and query it via LDAP? So I could outsource my user-to-role mapping into active directory.
Update:
For authentication I currently use a LDAP-Realm (user, password).
For authorization I want to use a database (rolename, user). However I don't know how to tell my application to use the database for authorization. If I would use a JDBC-Realm, I could specify the Group/Role table and column. Is there a way to tell my application to just use the JDBC-Realm for authorization?
We are using Spring Security and it is working fine in the single web application. Now, I need to create another Web application with Spring security. In the first application the user can sell his/her stuff (e.g. EBay). The second app which I am creating now, it is for general users where he can save his general preferences, searches, save some items he looked at etc. He may/may not be the existing user. So the difference between the two users are:
User 1 (existing user): Can post his stuff for sale.
User 2: He/she should be able to login. Save his general activities etc. & if he/she wants to sell his/her item, he/she needs to go thru the additional steps for verification.
All this cannot be done in just one application due to some reasons. My question is on how to handle the security? Should I create separate security filters for each applications or is there a way to use common security implementation who can manager both of these application. Please provide your feedback, I would really appreciate it.
if you wrap both components in two different webapps, each will have his own spring security web filter infrastructure.
So in principle there will be a security session for each web application, to be backed by whatever authentication system you use.
If you use JDBC then the user would have to login twice.
If you want your customers to only login once, you can for example use a token based system.
When you cross link from webapp 1 to webapp 2, you could hook the links up to a redirect servlet.
The servlet then generates a token, persists it in a database and forwards the user with the token in the url to the other webapp.
In spring security you can then implement your own PRE_AUTH_FILTER which reads out the token, verifies if it is persisted in the Database.
For security reasons you should make these tokens only one use.
I have an application built on Spring MVC that uses Hibernate for all of it's DB interaction needs. There is now a need to update the application to use our LDAP infrastructure to drive the user information, including basic user data, such as name and email, as well as authentication and authorization needs as well.
Since everything has been in one spot (the DB) up to now, the reports are all fairly straightforward, since Hibernate is managing retrieval of information as needed when starting with the required queries. Grabbing the users' name, etc. is very simple, since Hibernate loads the data lazily.
With the desire to drive the user information with LDAP, Hibernate will no longer be able to populate the user information on the fly, since it won't be managing the users' data. How should we use LDAP to drive the user data and deal with authentication / authorization without causing to much pain when we need to grab user data like Name, etc.?
We have considered using a hybrid approach where LDAP is treated as the "source" for the data and the current system is left as-is. This would require changes to the transaction processing code to update against LDAP so that the live transaction is using up-to-date information, and also a periodic sync against LDAP to keep the application DB up-to-date for reporting purposes.
This solution seems a bit hacky, and seems to have a lot of moving parts, but I could not find much on this subject elsewhere on the web.
How should user information be handled / how should the app be structured so that all of the user information is still easily accessible and can be easily tied to the rest of the system for reporting purposes? Is there a way to integrate Spring LDAP and Hibernate so that layers above the data layer don't have to know? Or is pulling the info from LDAP into the existing database the easiest way to go?
If you can not drop the user table at all, because it is used from other entities, then my suggestion is to separete the security stuff from the business stuff.
This mean remove the only for security needed information from the user table (login, password, ...), so that only the stuff remains that is needed to implement the buiness cases.
Then rewrite the security stuff so that is is based on the LDAP. I guess you find a way to get the user data base object for an given prinipal.
Only one thing will remain, how to create new user database entities if a new person get a new login. You have 3 choices, what is the best one strongly depends on your application:
Create the database entity if the users first login
Create the database entity if you first need it
Create the database entity when it is created in the LDAO (or some minites later) for example with an cron job, or some Spring Scheduling service.