I am using spring security 4 and I realized that if I add a url handler in the controller and forget to specify access rights in spring security xml , this page will not be secured and will be accessible to all. I was trying to use:
<intercept-url pattern="/**" access="denyAll" />
But it bans all users, even those I specifically open access to in other tags.
Maybe you think about something like that?
access="isAuthenticated()"
as said here it returns true if the user is not anonymous.
I think the main idea of keeping app secure is not to make mistakes by human too... Even the best security system is not secure when human forgot to set a password.
Related
I am trying to provide security to the REST endpoints. I am following instructions from this page. In my case I don't have view hence I haven't created controller to specify the views and haven't added viewResolver in my AppConfig.java
After implementation it correctly shows the access denied error upon calling a secured REST endpoint. But even though I specify username/password in the request header I get the access denied error. I am testing in postman setting username/password in Basic Auth. What am I missing any idea?
The example you have followed is implementing a form-based authentication. In order to change it to http auth (which is more suitable for REST services) you need to look for the following form-login tag in your security.xml:
<form-login
login-page="/login"
default-target-url="/welcome"
authentication-failure-url="/login?error"
username-parameter="username"
password-parameter="password" />
And just change it to an empty http-basic tag:
<http-basic />
If you did not change anything else, then it supposed to work perfectly. You can also test your setup from your browser, by trying to access your page. If you configured everything properly you will get a popup this time, not a form. That will be HTTP-basic authentication welcoming you.
Since likely you are using the Java-based configuration, the equivalent of this change would be to replace:
http.authorizeRequests()
.antMatchers("/admin/**").access("hasRole('ROLE_ADMIN')")
.antMatchers("/dba/**").access("hasRole('ROLE_ADMIN') or hasRole('ROLE_DBA')")
.and().formLogin();
with:
http.authorizeRequests()
.antMatchers("/admin/**").access("hasRole('ROLE_ADMIN')")
.antMatchers("/dba/**").access("hasRole('ROLE_ADMIN') or hasRole('ROLE_DBA')")
.and().httpBasic();
we use Spring security 3.1.2.RELEASE and we need to switch off HttpSession. Is there any way how to do it? We tryed to use create-session="stateless" attribute of http element, but without any success. Is there any way how to switch of session or at least find where session is created? Thanks
I'd start with this FAQ. You can also find out where the session is created by adding <debug /> to your XML configuration.
Some authentication mechanisms require a session, but others don't. If you use never as the create-session attribute value then Spring Security won't create a session itself. The stateless option should be supported in 3.1, so I'd guess your application is most likely creating the sessions itself. In any case it would help if you clarify what you mean by "without any success" - i.e what actually happens, is there an error?.
Is it possible to somehow bypass spring security for certain cases? We are currently using spring security 3.1.x and this setup is working well (form-login, etc).
For our web-api, we now have a requirement that certain objects can be set as 'external' meaning that they should not require login. All objects will be under /api/* but the actual path will be dynamic (usually its /api/{type}/{id}).
Any suggestions?
you can define the url pattern in separate http to bypass spring security filter chain, like this
<http pattern="/api/**" security="none"/>
I am new in ss3,and I have read its reference,also I read the spring security book.
However I do not find anything about the role-permission.
For example,here is the config for form-based authentication.
<http auto-config='true'>
<intercept-url pattern="/user/add/**" access="hasRole('USER_ADMIN')"/>
<intercept-url pattern="/user/delete/**" access="hasRole('USER_ADMIN')"/>
<intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
<intercept-url pattern="/**" access="ROLE_USER" />
<form-login login-page='/login.jsp'/>
</http>
I want to control the user operation(add/delete):
<intercept-url pattern="/user/add/**" access="hasRole('USER_ADMIN')"/>
<intercept-url pattern="/user/delete/**" access="hasRole('USER_ADMIN')"/>
I define the role of 'USER_ADMIN',but this is not enough,since I want to differ the user who have 'add' permission from user who have 'delete' permission.
Maybe I can add more roles like 'user_admin_add' and 'user_admin_delete'.
But I do not think this is a good idea since the 'add' or 'delete' are permissions,not roles.
How to make it?
Also,it seems that all the roles should be configed to the xml file,I wonder if I can add new roles and permissions dynamically(in the administrator page)?
Think of roles as a privileges. And granulate them as much as you need. Another thing is that maybe you should make a more RESTFul implementation. But this is another thread.
For example, your "delete" could be a "DELETE" HTTP method. Then you could be:
<security:intercept-url pattern="/users/*" method="DELETE" access="ROLE_DELETE_USER" />
and a curl -X DELETE -u login:password 'http://example.com/users/1'
would delete the user with id 1.
By a RESTFul, since uris are either identifiers or actions, there is no use in add roles (privileges) dinamically. Since those roles are meant to be used against a new resource that should contain the xml file.
I'm afraid you cannot do this, unless you use ** wildcards. Which in my opinion if used uncarefully can lead to troubles.
Maybe I can add more roles like 'user_admin_add' and 'user_admin_delete'.
This is the way. Permissions are roles and generally there are people who view differentiation between them as unneeded.
I don't think there is much difference in having a role ROLE_USER_ADDER or a permission PERMISSION_ADD_USERS.
You can however use roles as a concept to group permissions if you need to. For instance you can have a role admin which can add and remove users. So the role ROLE_ADMIN will have PERMISSION_ADD_USER and PERMISSION_REMOVE_USER. Still spring will view both roles and permissions simply as authorities.
As for dynamic roles adding you can do it by loading the current user permission from your DB for instance. Have a look at the UserDetailsService of spring security. The UserDetails object it returns has a getAuthorities() method which you can populate from your DB.
/**
* Returns the authorities granted to the user. Cannot return <code>null</code>.
*
* #return the authorities, sorted by natural key (never <code>null</code>)
*/
Collection<GrantedAuthority> getAuthorities();
Here is a very good example of implementing your own UserDetailsService.
In my personal opinion spring security has several (lets say) unfortunately chosen names. So do not pay so much attention to the Term "Role" it works perfectly if you use it for privileges.
In my applications a use a naming convention to choose between Roles ans Privileges. (roles are written upper case, privileges lower case). But pay attention the Role Voter will pay attention only the the strings that starts with "ROLE" (Default configuration, can be changed.)
See also Spring security group based authorization
You should be thinking of roles more along the lines of, well, roles, rather than permissions. If you want to differentiate between adding and removing users, you might define roles described as ROLE_SALES and ROLE_USER_ADMIN. Sales staff might well need to be able to add new users into a system.
Regarding the dynamic application of roles, you should look at the architecture of Spring Security. You'll most likely want to use, or implement, a suitable UserDetailsService. See the UserDetailsService reference documentation.
If you're storing your user authorization information in a JDBC database, for example, you might want to use the JdbcDaoImpl.
There are some examples of using different authentication providers in the namespace introduction.
I am newbie in Spring Security 3, and I am having the next problem.
Using the spring-security Namespace, I try to configure a single basic authentication, in wich I want only to filter the POST method.
From my servlet.xml configuration:
<security:http auto-config='true'>
<security:http-basic></security:http-basic>
<security:intercept-url method="POST" pattern="/**" access="ROLE_USER" />
</security:http>
Well, the thing is that, after starting the server, it works fine the first time (that is, the other methods doesn't prompt any authentication screen). But after a first use of the POST method, it prompt the authentication screen for all the method. Does anyone knows what am I missing?
Thanks in advance for your time! ;-)
Ok, auto-answer! xD
I was using to try it a Firefox plugin called Rest Client (I really recommend it ;-) ). My failure was, after the first login tryial with the POST method, that it saved in cache that it has prompted an HTTP-BASIC authentication. After cleaning my history, it works fine.
After that, I have learned:
-Think always in the cache when you use a browser
-Give more information about your environment when you ask something in Stackoverflow xD
Thanks everyone!!