I am using the Spring Security default login page and if my user get to a page that he should not be getting to based on role and url he gets the following error on the screen:
org.springframework.security.access.AccessDeniedException: Access is denied to login
How can I make it some Spring goes to the default login with or without a error. please help me out
As documented in the <access-denied-handler> element in the documentation's Appendix B, you can set the errorPage attribute to forward to a custom JSP. This could be your login page or whatever else you want. Keep in mind that at this point, the user is already logged in, so forwarding them to the login page (again) may be confusing.
As Raghuram suggested, you can also implement AccessDeniedHandler yourself, but I'd hold off on doing that unless you really need to.
I don't have the info in front of me, but if I remember correctly when you setup spring security you can give it url patterns to apply the security to. It sounds like your setup is including the login page in the patterns that security is applying to. You need to make sure that it is not. Go back to the spring security doco and you should be able to work this out. Also the spring logs are usually very good at helping with this sort of thing.
What you probably need to do is to override the default AccessDeniedHandlerImpl as documented here.
Related
I don't know if I worded this question correctly, Spring Security is something I'm not very familiar with.
In my spring boot application the login is done with OAuth 2.0 and gluu. So far it works well and without issue. However, after the user logs in I check whether a user with the ID provided by the gluu server exists in our database because I need additional information on the user. Now, this is done after the login when checking things like permissions and fetching user-specific properties like settings. If the user does not exist on our end I get a NullPointerException. This case should (in an ideal world) not happen but I'd still like to handle it properly.
I'd like to make that check happen as part of the authorization process, so the login fails if we don't have any information on the user instead of checking it after the login has completed.
Does that make sense? I'm having a hard time wording it properly so I couldn't find any useful results on google. A link to some tutorial or docs would be greatly appreciated!
You can handle this with an Interception Script. And you will also need to add customAuthParamz in oxAuth configuration (JSON Configuration > OxAuth).
If you want to do it in spring-security, you can provide a Converter<Jwt, AbstractAuthenticationToken> #Bean (to replace default JwtAuthenticationConverter).
This bean would call your user repo (maybe on a #Cachable method) and could even return an Authentication of your own with all user data you need for your security rules (maybe either create missing user record in databse or return AnonymousAuthenticationToken when user is not known in your system).
I have something a bit like that in this tutorial (extra user data is retrieved from token private claims and not from a database, but you get the idea).
I'm trying to get Spring Security to handle authorization via GET variables. All the examples I've been able to find focus pretty much entirely on role-based authorization, which doesn't really work for my application. The way the authentication/authorization process needs to work is as follows:
User authenticates through external system, gets a session ID.
User passes two GET parameters to my application, sessionId and objectId.
Application verifies that session is valid (already figured this part out)
Application verifies that the object is visible to the user (need help here)
Application returns object information to the user
All the examples I've seen have been demonstrating how powerfully Spring Security can check a granted authority on a URL pattern or a Java method. But I need to implement a custom check on step 4 to make sure that the user has the correct permissions in the backend (users can be granted object-specific rights, so a role approach won't work here).
I am new to Spring Security, so it could be that my thought process is just all sorts of wrong. If I am, feel free to correct me!
You need to use ACL feature or you can emulate the same thing via some custom code (for example via custom web security expression). See this post for details.
I think you need to look at the Pre-Authentication Scenarios section in the documentation. In particular, you will probably need to implement a AbstractPreAuthenticatedProcessingFilter to pre-authenticate the user based on the GET parameters.
I have a java web application running on tomcat, and will use single sign on (against an Active Directory) for authentication.
What I want to accomplish is, that only certain pages in the web app are allowed to be the first "landing page" in the site.
The use case is that one may point the browser to index.jsp, and then be authenticated behind the scenes, and then be forwarded to some_content.jsp.
However, if I point the browser directly to some_content.jsp, I want the request to be denied, somehow, and NOT authenticated behind the scenes.
To rephrase, if I go to some_content.jsp first, without already being authenticated, I do not want authentication to happen, eventhough I have SSO set up.
Is it a matter of some fairly simple security-constraint, or what could a solution be? I am looking for a solution that can be configured, rather than adding code.
Thanks a lot!
This won't work with container managed security. The only method to have a concrete login-entry-point with container-manager auth like in Tomcat is FORM auth. I use SPNEGO auth myself and Tomcat will perform it on any URL if it is denoted as protected. So a routing login page is not possible unless you write a custom authenticator.
I used jdbcRealm in my web application and it's working fine. I defined all constraints also in my web.xml. Like all pages of url pattern /Admin/* should be accessed by only admin. I have a login form with uses standard j_security_check, j_username and j_password.
Now, when i type Admin/home.jsf it rightly redirects me login.jsf and there when i type the password i am redirected to home.jsf. This works alright but problem comes i directly go to login.jsf and then type password and username. This time it again redirects me to login.jsf. Is there any way through which i can specify which page to go when successful login is there? I need to specify different different pages for different roles. For Admin, it is /Admin/home.jsf for general users it is /General/home.jsf because login form is shared between different type of users. Where do i specify all these things?
Secondly, i want to have a remember me checkbox at the end of login form. How do i do this? By default, it is submitted to j_security_check servlet and i have no control over its execution. Please help. This doesn't seem so hard but looks like i am missing something.
I found the answer to my own question. This is for any newbie who drop on this thread in future. Ok, the solution that i found after much thinking is that i make one folder and one jsp page say flag.jsp. Next, I give access to it to all the roles.
Now, you might be wondering what good would that do?:) Well, just follow it and you might be done. :p
Next in your welcome-file in web.xml mention the url of this file. Thus, when application starts it will go to this url and container will find that i am unauthenticated thus redirect me to login page. That's it. Now, the final part is you can write simple scriplets in our shared roles jsp file and redirect to home based on role.
Eg. if httpservletrequest#isUserInRole("Admin") then redirect to "/admin/home.jsf" and so on.
Well, this is not so efficient but important thing is that it works! :). This idea accidently bumped to me today. I guess, now i can rest and use container managed security easily. Waiting for your comments.
My web app has a secure area which users log in to via a JSP. The JSP posts the user name and password to a servlet, which then checks to see if the users credentials are valid. If they are valid then the user is directed to the secure resource. How can I ensure that users can't just navigate to the secure resource without validating first?
A common approach is to set a token in the user's session i.e.,
session.setAttribute("loggedIn", "true");
or even
session.setAttribute("loggedInUser", "someUserName");
and check that on any page that should be secured. A good strategy is to perform the check using a servlet filter that you attach to any page to be secured. If they don't pass the check, the filter can redirect to the login page. Also see here: http://java.sun.com/products/servlet/Filters.html
This is a good article on using filters for authentication also: http://www.developer.com/java/ent/article.php/3467801
What bout using the security-contraint in your web.xml :
<security-constraint>
<web-resource-collection>
<web-resource-name>Secure</web-resource-name>
<url-pattern>/secure/*</url-pattern>
</web-resource-collection>
Make sure people always access your app through a single servlet, where the servlet dispataches the request to a JSP, and returns the resulting response to the browser. This way you will always be in control of what happens because there is a single entry point.
A different approach is to have a session variable (server side, or even in a cookie) which gets checked by each and every JSP which requires authentication.
Security is really hard to get right. Much more than you would usually think. The use of a framework (Acegi comes to mind), or the standard "" section of web.xml as LenW pointed out is a must ! At least use a filter to handle the authorization part of your security.
I dont really like the solution of using a single point of entry (as suggested by Rolf). It seems to me like an artificial constraint put on your architecture. And there is a lot of good reasons to have multiple servlet in a webapp.
Whatever you do, dont use a technique where you rely on manual code on every page (like : every JSP begining with "if user_authentified ..."). You will forget to put it somewhere ...