For a non-trivial setup involving session concurrency control, authentication is not equivalent to login. For example, a user can be authenticated successfully but still redirected to a logout or error page if this is a second login attempt and max-sessions="1". If I have post-login logic that needs to be invoked at the point of login (not authentication), what is an optimal way to incorporate this logic into a Spring Security-based webapp? The solution I came up with, based on my limited understanding of the framework, was to implement my own custom ConcurrentSessionControlAuthenticationStrategy adapter extending the framework's ConcurrentSessionControlAuthenticationStrategy and inject it into CompositeSessionAuthenticationStrategy in my Spring Security configuration XML. I created a 1-arg constructor and onAuthentication method. onAuthentication performs my post-login processing before calling super.onAuthentication. Is there a better way to do this?
My custom onAuthentication method looks something like
.
.
if (sessionCount < allowedSessions) {
// Record login timestamp in database
Date now = new Date();
userDao.setLastLogin(now);
userDao.save();
}
super.onAuthentication(...);
Because sessionRegistry member variable is declared private (as opposed to protected) in the parent, I had to declare my own sessionRegistry and initialize it inside the 1-arg constructor so that my onAuthentication method would have access to it.
Related
I'm implementing a cache system to handle my JWT on server side to emulate a Session State , everytime an action is called i must validate the token on the server cache to see if it's still valid, is there a way to create a something like
[Authorize] or [AllowAnonymous]
To search over the request and do whatever is needed to valide it? i already have a singleton class that handles the cache system, all i need is an easy way to call the right methods.
I want to avoid calling via Dependency Injection the method on every action on every method.
I'm using Net Core 3.0, Distributed Cache, and a Web API with JWT validation.
Thank you.
You need to implement an Action Filter. See the documentation for more details
I am using basic authentication mechanism in my Dropwizard application, where I am capturing logged in user details, something like this:
#POST
#Timed
#Consumes(MediaType.APPLICATION_JSON)
#Produces("application/pdf")
#Path("/")
#RolesAllowed("user,admin")
public Response function(#Auth User user) throws Exception {
//some logic around here
}
Now for auditing purposes, I want this user information to be passed at each layer of my application, I mean in services, DAOs, ExceptionMappers etc and I don't want to pass it as function parameter everywhere as it looks clumsy and also has maintainability overhead. so my question is, is there any way by which we can set some global configuration per REST call or user session and can fetch it anywhere I want?
I have been a Ruby user and in that we were able to do something like this:
Thread.current[:user] = user
which which accessible throughout per user session.
One way to achieve this is by using ThreadLocal of Java wherein you can set the User object and it will be available to that particular executor thread.
Add the following to your resource class.
private static ThreadLocal<User> localUser = new InheritableThreadLocal<>();
public static ShortenerServiceUser getUser() {
return localUser.get();
}
Whennever your function() method is invoked, you just need to set the User object into the ThreadLocal variable.
localUser.set(user);
Now, whenever you need to access the User object from the current thread context, all you need to do is as follows
User localUser = YourResource.getUser();
You can clear the User object from the context by using the ThreadLocal.remove() method.
I need to access the user's password in a Jetty application after authentication, and can't figure out how.
I am migrating a set of web pages away from basic authentication in an embedded Jetty servlet application. I cannot, however, completely remove basic authentication from all of the services that these pages call, so I need to forward the user credentials in some cases, which means storing and later retrieving the user's password.
I introduced forms authentication to the root context via the standard markup in web.xml, which works fine but I can find no way of getting the user credentials programatically. As far as I can tell there is no way to place a Filter on j_security_check to intercept and store the form parameters in the session state. Jetty provides all the user credentials in the session state but this is in a container-specific key and although the application is currently tied to Jetty I would strongly prefer a container-agnostic solution. Here are some specific questions that I've tried to formulate after going down a number of seemingly dead-end streets:
How can I obtain the user's password after login? Even if I moved the services away from basic authentication I would still need to perform some secondary action such as obtaining a token, in which case I would still need their credentials under my control for a brief period.
Assuming I can't obtain the user's password directly, perhaps I can leverage something in the container to store the credentials. I can implement my own LoginService that wraps the actual implementation, but that class does not have access to the HttpSession or Request objects. Where is the proper place to do this?
If I need to implement a custom login solution, I'm not quite sure where to start...the FormAuthenticator has a lot of complicated session state management that I would like to preserve and not reproduce willy-nilly, and I would still prefer to defer to the container standard as much as possible. Is there some standard method for extending or overriding the j_security_check logic?
I finally found one solution, for anyone else attempting similar - and I've found quite a few other posts from confused devs, and some badly hacked together workarounds. I believe this one is correct, although you must do the URL filtering yourself and it leaves open the question as to why this is possible, if indeed j_security_check should be exempt from this type of interception for security reasons, as is claimed many places online. Perhaps I am merely exploiting an unknown gap in the Jetty security measures, so I will leave this question open for a while to see if there is a more robust or explicit solution.
ServletRequestListener allows you to latch onto the j_security_check post request before it is fully initialized. There you can get both the form parameters and the session object. So in the end it was just a matter of exhausting every possible servlet-related class in Jetty until I found one that would give me access to the j_security_check request. Some code:
public class PreAuthenticationRequestListener implements ServletRequestListener {
public static final String USERNAME_KEY = "USERNAME";
public static final String PASSWORD_KEY = "PASSWORD";
#Override
public void requestDestroyed(ServletRequestEvent sre) {
}
#Override
public void requestInitialized(ServletRequestEvent sre) {
HttpServletRequest request = (HttpServletRequest)sre.getServletRequest();
if (request.getRequestURI().contains("j_security_check")) {
final String username = request.getParameter("j_username");
final String password = request.getParameter("j_password");
HttpSession session = request.getSession();
session.setAttribute(USERNAME_KEY, username);
session.setAttribute(PASSWORD_KEY, password);
}
}
}
I am currently implementing an adapter based authentication for my Worklight application.
For the record, I am using Worklight version 5.0.6.1.
What I would like to do is, as it seems to be advised in the documentation, to perform some cleanup in the "logout" function of my authentication adapter.
Thus, inside the logout function being called automatically by the Worklight framework, I'd like to retrieve the userIdentity object holding the info about the user being logged out. I tried to achieve this by calling "WL.Server.getActiveUser()", but it does not seem to be possible to do this in the logout function.
I can see the following exception in the logs (WebSphere App Server 7):
[9/3/13 17:13:11:683 IST] 00000039 DataAccessSer 1 com.worklight.integration.services.impl.DataAccessServiceImpl invokeProcedureInternal Procedure 'onLogout' invocation failed. Runtime: Adapter 'onLogout' security test has no user realm.java.lang.RuntimeException: Adapter 'onLogout' security test has no user realm.
The idea behind this is that I want to call an external REST service that will perform some cleanup in a DB, and I need the mobile application userId to be passed as a parameter of this service.
Could someone please give some best practices in order to retrieve the identity of the user being logged out from inside the authentication adapter logout function?
Thanks.
User identity is destroyed by an underlying auth framework before Adapter.onLogout() is invoked. As a result when Adapter.onLogout() is called the user identity doesn't exist any more. Therefore WL.Server.getActiveUser() will return null or throw exception (in your case because it doesn't have any user realm defined, which is perfectly fine).
In case you still require data from userIdentity even AFTER underlying auth framework discards it (and this IS your case) you can save userIdentity in session state. However you need to remember that since you're manually storing it there - it is also your responsibility to wipe it once it is not required anymore.
So the adapter code would be something like:
/* global var, not inside of any function*/
var userIdentity = null;
function submitCredentials(user, pass){
if (/*validate credentials*/){
/* using previously created global var, not declaring it again */
userIdentity = {
userId:user,
displayName:user
};
WL.Server.setActiveUser("realm", userIdentity);
}
}
function onLogout(){
/* do your stuff with userIdentity object and then wipe it*/
userIdentity = null;
}
The main difference with regular adapter flow is that userIdentity object is not created in the scope of a submitCredentials() function but as a global variable, therefore it is a session scoped var.
I'm still pretty new to JEE6 having come from a Servlets + JSP style of development on legacy systems. In the applications I worked on we would just throw objects into the various supplied scopes (request, session and application) keyed on a constant String. For example, the User object that represented the currently logged in user would be in the session scope keyed under "current_user".
I've done the same in our new JEE6 application, when the user logs in the User object is bound into the session scope. I'm wondering though if there is a better, more EE, way of handling this?
The problem I'm having is that now I've got the User stored in the session it's awkward to get access to it again. I can get it via JNDI look up or with a few lines of boiler plate code involving FacesContext but neither are very elegant.
Rather than boiler plate code all over the place (the User object is need in a few places) it would be great if I could just get the object injected into a field or method. After all there can only be one object in the session bound to a particular name so there shouldn't be any ambiguity about what I'm asking for. Is this possible?
Maybe the CDI could be of any help?
Could you define the way you achieve the User object into one, main method?
If so, and you're working with Java EE 6 environment, you could use the Producer method. Something between these lines:
public class ClassWhichCanAccessUserObject {
#Produces
public User produceUser() {
User u = ... // get the user as you do it right now
return u;
}
}
Then in the place you want to use this class you just Inject it (in the field or method) and use it:
public class MyLogic {
#Inject
User u;
}
You need to remember to add the beans.xml file to your classpath, as without the CDI will not work for your module.