If I want to introduce the concept of blocked users, where is the most appropriate place to make the check if a user is blocked, without breaking the principles of good design?
Till now, I've been using Spring Security, to annotate the controller methods on whether a particular user has the permissions to do a certain action. With this blocked users thing, it gets a bit more complicated. Should I try to fit this again in the controller (possibly with Spring security again) or this is something which I should let the domain object decide itself?
I guess it'd be better to leave this on the controller leve, but I fear if my controllers won't turn into an if...else mess one day.
One approach could be to introduce role called "BLOCKED", assign it to all users when they are blocked and annotate all methods that do not allow blocked users to access them with:
#PreAuthorize("!hasRole('BLOCKED')")
public void secureMethod();
Another approach would be to store blocked status in user database or in some other storage. Then extend the UserDetailsService to return additional user information including the "blocked" flag. And the again use security EL to filter methods that do not allow blocked users to execute them:
#PreAuthorize("!principal.blocked")
public void secureMethod();
UPDATE:
Problem you mentioned in the comments can be approached in some similar way:
#PreAuthorize("!#photo.owner.blockedUsers.contains(principal.name)")
public void likePhoto(Photo photo);
For any more complex and/or generic rules I would advice to use AOP aspects to keep your code clean from too many ifs.
Related
I'm using Vaadin Flow to develop a web app with Java. I would like to know the best way to handle login and authorization. I've been giving this a thought and I'm not sure the best way to do this.
I have a login view and a main app view with a content holder for nested layouts.
How do I check that the user is logged in and what permissions does it have to see or not see some part of the app? I've read about BeforeEnterEvent and ReRouting but it's still not very clear.
Do I have to use BeforeEnterEvent for each class I have? Do I have to create a class with user parameters like a boolean to check if it's logged in and a string for the kind of authorization it has? And where do I create or save this instance?
Is there a simple way to do this? Like to start with an empty layout and to start that with the login screen, then the login screen decides to swap for the main app view? And how do I prevent the user to type the address of the main view in the bar and access parts it shouldn't access like: /app/adminsettings
I'm sure this is way simpler but I think I have my head overloaded by now, thanks anyone in advance!
As always, there are no silver bullets. The "best way" always depends on
the requirements and your options range from Basic Auth to some external
OIDC provider.
There are already some tutorials out there with the most prominent from
Vaadin itself about Spring
Security
(which in a previous iteration had a flaw that compromised security,
which of course shows again, that security is no product but a process
and demands constant validation).
So I want to strategize here a bit more about the problems you are
facing and some things to consider:
Be aware, that when you use a security library, that has or allows for
an web path centric approach, that you should only use it for the
root and to open up paths to resources etc. The history API may only
look like you are fetching URLs from a server or web sockets may be
used under the hood and suddenly those rules no longer apply.
If you are using the annotation based way to add routes, you end up
with all the routes, that are there, for your UI per user. So it's
good to familiarize yourself with how to register routes
dynamically.
E.g. only add the routes the user is allowed on login; this usually
also has implications for the UI (e.g. menu entries).
There usually is some initial "declarative" security part (can the
user even enter this view; this usually means some simple role check).
A good place to check for this is a BeforeEnterListener added to the
UI; it will be called before any navigation to any view. See
navigation
livecyle
The next entry point(s) to guard are the BeforeEnterEvent you can
listen on in the view itself and/or maybe it implements
HasUrlParameter. If you take params from the "request" or the path,
the usually mean further checks (e.g. is the acting user allowed to
edit the blog entry with the id 42). See routing and URL
parameters
and also navigation
livecyle.
Deeper into the application you end up with something more imperative,
that libraries often make appear declarative, because they generate
some code for you from some annotation (e.g. some AOP that generates
the code around your #SecurityCheck('${u.owner}==${currentUser}')
void save(User u) method, that checks for the role and whether the
User u belongs to the acting user).
Be very certain, that your IoC system/library/... sees those
annotation and generates the code accordingly. Only #Route e.g.
will get the full DI treatment with Vaadin+Spring - for the rest it's
your job that the DI-framework can do it's job (a NPE from a missed
#Autowired is spotted very quickly, but a security check not being
called, is not). The obvious way around this, is to be imperative and
write the code yourself instead of relying on it to be there.
If you have an anonymous system and then some login, make sure to send
users over to a fresh session (and therefor UI); not only does it
prevent a session fixation attack, but it also allows you put all your
route-setup and UI derivations according to security in one place at
the beginning of the UI creation. If you have state you want to carry
over, make it part of the URL, that your successful login process
sends them back to or park in the browsers local storage.
In Spring Security OAuth2, I can limit the scopes that a client is permitted to request by configuring the ClientDetails. However, in addition to limiting by client, I also want to limit the scopes available to individual users; for example, a user should only be able to access the admin.forceLogout scope when holding ROLE_ADMIN.
I don't want to directly map user authorities to scopes, as checkUserScopes does; instead, I want to run custom logic to inspect and modify the scopes associated with a particular token grant. What's the best way to do that?
I see two possibilities, neither of which looks ideal:
Provide a TokenEnhancer that modifies the token after issuance. This seems like it's intended more for including additional information, such as audience claims, than for rewriting the already-available scopes. In particular, this runs after the confirm_access step.
Provide a custom OAuth2RequestFactory. At a minimum, this involves duplicating a lot of security-sensitive logic. Overriding checkUserScopes() seems like the perfect place to put the custom policy, but it's private, and the only override point is on the entire createTokenRequest().
Is there a better way to do this sort of "intersection" filtering, or are these the two options?
The background: there is a requirement to attach auditing data to persisted entities, basically creation-timestamp + user ID and last-update-timestamp + user ID.
I'm not keen on passing the user ID as a method parameter through all layers/components. So I need to somehow pass user identifcation (derived from HTTP headers, the details are unimportant) through a REST endpoint (using RESTEasy, but that's probably not important, either) back to the data access/repository layer.
I've thought of using ThreadLocal but it feels a little hackish and might fail in a non-blocking IO environment. Maybe I'm wrong about that, not sure.
I also have a vague idea that AOP could help, though I'm not well-versed in AOP so not sure.
Any strategies appreciated, with or without code.
You can use entity lifecycle callback methods for your requirement: #PrePersist, #PostPersist, #PreUpdate, #PostUpdate.
It is one of the auditing strategies mentioned here.
It turns out that Spring's SecurityContextHolder is a reasonable place to do this (don't ask why the application isn't already integrating "properly" with Spring Security). It's basically the ThreadLocal option but with some nice interface around it.
The tradeoff is that you need to be acutely aware of the thread-bound nature of this solution. A controller that somehow uses other thread to do the work that needs the user context, will need to take some steps to make sure those threads can get it since they don't, by default, inherit the ThreadLocal. There is a mode you can set on SecurityContextHolder that will use inheritance of the ThreadLocal in any newly created threads, but that does not help if a thread pool is used (since threads won't be created by the request thread but rather pulled from the pool). Even then, most thread pools provide a way for the client thread to do "something" when obtaining and releasing threads, so it's possible to pass the security context on that way.
I'm learning AOP and am comfortable with Pointcuts, Advices etc.
What am going to ask, am pretty sure is not possible, but want to ask anyways.
I have a method which takes a userId, fetches the user's record from a database and then does something to the record. I have like twenty different methods that do different things, but all of them take the userId as input and fetch the record from database. This to me looks like a cross cutting concern that can be pulled into an aspect.
But how? I know I can access the arguments (userId in this case), access the return value of the method and catch the methods exception. But how do I give the method something to work with (record in the database in this case?)
public String printUserDetails(String userId)
{
Record record = Database.fetchRecord(userId);
System.out.println(record.getDetails());
return record.getTitle();
}
So, is there a way to pull that database accessing code into an aspect?
One way I can think of is declare something like the following for input
class RequestObject
{
String userId;
Record record;
}
and inject the record in the Aspect and then call proceed(). But this somehow feels wrong.
IMO, resolving a user, using the userid, is not a cross-cutting concern and hence aspect is not the right way. The first landing page that receives a userId should actually resolve it to UserRecord and from then on, the userRecord should be the one moving around in the application.
A simple analogy I can draw to your scenario from one of my applications is, all authenticated servlets expect the servletRequest.getRemoteUser() to return the valid user login corresponding to the user sending the request. We decorated the HttpServletRequest to resolve this to a User object in our application and all the authenticated servlets downcast the HttpServletRequest to AuthenticatedServletRequest and extract this object. No one else within the application tries to resolve a user login anymore.
You cannot access a method's local variables from AspectJ if this is what you wanted to know.
The rest of the question is rather about design and the answer dependent on what you want to achieve. You can avoid code duplication in multiple methods using a template method design pattern. You can inject real or mock objects into classes if you refactor them to have a member instead of local variables. It is another question if you create the member by directly refactoring your classes or via AspectJ's (ITD)[http://www.eclipse.org/aspectj/doc/next/progguide/starting-aspectj.html#inter-type-declarations] mechanism. A third question would be if you possibly want to use an aspect for caching in order to avoid fetching the same object from the database multiple times.
I am not sure what exactly you want to achieve, so I cannot answer more specifically.
i wrote a own Security Manager and my problem is, that i run code from other users in my program, and i have to ensure that there is no abuse.
So my Question is: How i am able to find out in the Methods of the Security Manager , who asks for the Access in the checkXXXXX() - methods.
Thanks
No there is no simple way to do this in the general case.
(If you were running within a web container, that might provide a way to get hold of the current request's authentication details. But that doesn't sound like your use-case.)
I guess there are a variety of ways that you could attempt to implement this, though you'd need to be careful to protect against code that spoofs the user identity. One idea is to associate each user identity with a distinct ThreadGroup, and get your security manager to block creation of threads in other thread groups; read the javadoc for Thread(ThreadGroup group, Runnable target, String name), paying attention to what it says about the thread group check.