I have intercept url /test/** and now I am trying to create new intercept url as /test/test1 to different access role.
I tried below but not working
<security:http>
<security:intercept-url pattern="/test/**" access="ROLE_TEST" requires-channel="https"/>
<security:http-basic />
</security:http>
<security:http>
<security:intercept-url pattern="/test/test1" access="ROLE_TEST1" requires-channel="https"/>
<security:http-basic />
</security:http>
Don't create a <http> element for every url you want protected that is going to clutter your configuration, next to the fact that it won't work. Simply add it to the first block. Make sure that the /test/test1 mapping comes before /test/**.
<security:http>
<security:intercept-url pattern="/test/test1" access="ROLE_TEST1" requires-channel="https"/>
<security:intercept-url pattern="/test/**" access="ROLE_TEST" requires-channel="https"/>
<security:http-basic />
</security:http>
See the Spring Security reference especially the note.
Related
I am trying to update my Spring Security version from 3.0 to 3.2. Following is the current config:
<security:http auto-config="true" realm="Domaine XXX" access-denied-page="/jsps/login/access-denied.action">
<security:http-basic />
<security:intercept-url pattern="/services/*" access="IS_AUTHENTICATED_ANONYMOUSLY" />
<security:intercept-url pattern="/index.jsp" filters="none" />
<security:intercept-url pattern="/jsps/i18n/**" filters="none" />
<security:intercept-url pattern="/**/Action1.action" filters="none" />
<security:intercept-url pattern="/**/Action2.action" filters="none" />
<security:intercept-url pattern="/**/Action3.action" filters="none" />
<security:intercept-url pattern="/**/Result.action" filters="none" />
<security:intercept-url pattern="/isalive.html" filters="none" />
<security:intercept-url pattern="/**/layout/**" filters="none" />
<security:intercept-url pattern="/**/acc.action" filters="none" />
<security:intercept-url pattern="/**/loadLoginCombo*" filters="none" />
<security:intercept-url pattern="/**/access-denied.action" filters="none" />
<security:intercept-url pattern="/**/logout.action" filters="none" />
<security:intercept-url pattern="/**/*.js" filters="none" />
<security:intercept-url pattern="/**/*.css" filters="none" />
<security:intercept-url pattern="/**/*.ico" filters="none" />
<security:intercept-url pattern="/**/*.gif" filters="none" />
<security:intercept-url pattern="/**/*.jpg" filters="none" />
<security:intercept-url pattern="/**/setLocale.action*" filters="none" />
<security:intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY" />
<security:logout logout-url="/logout.action" invalidate-session="true" logout-success-url="/logout.action" />
<security:form-login login-page="/index.jsp" authentication-failure-url="/access-denied.action" default-target-url="/pageBlank.action" />
<!-- security:concurrent-session-control max-sessions="5" exception-if-maximum-exceeded="true" / -->
</security:http>
When I host the application , I get the following message:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: The use of "filters='none'" is no longer supported. Please define a separate element for the pattern you want to exclude and use the attribute "security='none'".
What exact changes should I make to conform to Spring Security 3.2 standards?
Since Spring Security 3.1 filter="none" is not supported anymore, see Spring Security Reference:
[4] The use of multiple <http> elements is an important feature, allowing the namespace to simultaneously support both stateful and stateless paths within the same application, for example. The previous syntax, using the attribute filters="none" on an intercept-url element is incompatible with this change and is no longer supported in 3.1.
You have to use <http>, see Spring Security Reference:
From Spring Security 3.1 it is now possible to use multiple http elements to define separate security filter chain configurations for different request patterns. If the pattern attribute is omitted from an http element, it matches all requests. Creating an unsecured pattern is a simple example of this syntax, where the pattern is mapped to an empty filter chain [4]. We’ll look at this new syntax in more detail in the chapter on the Security Filter Chain.
and Spring Security Reference:
13.6 Advanced Namespace Configuration
As we saw earlier in the namespace chapter, it’s possible to use multiple http elements to define different security configurations for different URL patterns. Each element creates a filter chain within the internal FilterChainProxy and the URL pattern that should be mapped to it. The elements will be added in the order they are declared, so the most specific patterns must again be declared first. Here’s another example, for a similar situation to that above, where the application supports both a stateless RESTful API and also a normal web application which users log into using a form.
<!-- Stateless RESTful service using Basic authentication -->
<http pattern="/restful/**" create-session="stateless">
<intercept-url pattern='/**' access="hasRole('REMOTE')" />
<http-basic />
</http>
<!-- Empty filter chain for the login page -->
<http pattern="/login.htm*" security="none"/>
<!-- Additional filter chain for normal users, matching all other requests -->
<http>
<intercept-url pattern='/**' access="hasRole('USER')" />
<form-login login-page='/login.htm' default-target-url="/home.htm"/>
<logout />
</http>
I have a REST services implemented with custom filter, i would like to disable security for all the requests coming with method OPTIONS. I tried to find the information on the web, but could not fine. Any points would be helpful.
I have the same intercept-url for both, only OPTIONS method requests should be disabled for security. One of the option which is tried:
<security:http entry-point-ref="CSSCustomAuthenticationEntryPoint"
pattern="/**" use-expressions="true" auto-config="false"
create-session="stateless">
<security:intercept-url pattern="/**" access="permitAll"
method="OPTIONS" requires-channel="any" />
<security:custom-filter ref="userAuthenticationProcessingFilter"
position="FORM_LOGIN_FILTER" />
<security:intercept-url pattern="/**"
access="isAuthenticated()" />
</security:http>
I'm using Spring to handle security in my JSF application. I have a login page at /login and I've configured Spring like this:
<http authentication-manager-ref="authenticationManager">
<intercept-url pattern="/login" access="IS_AUTHENTICATED_ANONYMOUSLY" />
<intercept-url pattern="/admin" access="ROLE_ADMIN" />
<intercept-url pattern="/javax.faces.resource/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
<intercept-url pattern="/**" access="ROLE_ADMIN,ROLE_USER" />
<form-login login-page="/login" authentication-failure-url="/login" />
<logout logout-url="/logout" />
</http>
I want the admin page at /admin to be available only for users with the ROLE_ADMIN role. Users with ROLE_ADMIN or ROLE_USER may access pages starting from the application root.
When I login with a user having either role I see the page you should see after login. However, whatever my next action may be I get redirected to /login like I'm not logged in. Can someone please explain this as I'm trying to get this thing to work for a day now. I've been reading the Spring 3.1.x documentation but it doesn't give me a clue about how to solve the problem. I'm running Spring 3.1.1.Release by the way.
Extra bonus info: the page you should see after login has an element that should only render if the user had ROLE_ADIN. I can see that element after login. The problems began when I implemented PrettyFaces. I've searched the web for common problems and only came up with that the PrettyFaces filter should appear after the Spring security filter. This is the case so it should work right?
UPDATE: I've updated my config to use expressions. However the problem still exists.
<http authentication-manager-ref="authenticationManager" use-expressions="true">
<intercept-url pattern="/login" access="permitAll" />
<intercept-url pattern="/admin" access="hasRole('ROLE_ADMIN')" />
<intercept-url pattern="/javax.faces.resource/**" access="permitAll" />
<intercept-url pattern="/**" access="hasAnyRole('ROLE_ADMIN','ROLE_USER')" />
<form-login login-page="/login" authentication-failure-url="/login" />
<logout logout-url="/logout" />
</http>
Output in Firebug's console just after login (the page tries an AJAX call):
First, always debug Spring Security when having problems (add log4j.logger.org.springframework.security=DEBUG).
Second, I think that you wanted hasAnyRole:
<intercept-url pattern="/**" access="hasAnyRole(ROLE_ADMIN,ROLE_USER)" />
plus add use-expressions="true" to http:
<http authentication-manager-ref="authenticationManager" use-expressions="true">
to allow ROLE_ADMIN xor ROLE_USER users to access page. In your current config user must have both roles to access /**.
I have my configuration of intercept url like
<security:http use-expressions="true" disable-url-rewriting="true">
<security:intercept-url pattern="/secure/admission/*" access="hasRole('ROLE_ADMISSIONER')" />
<security:intercept-url pattern="/secure/subdean/*" access="hasRole('ROLE_SUBDEAN')" />
<security:intercept-url pattern="/secure/referent/*" access="hasRole('ROLE_REFERENT')" />
<security:intercept-url pattern="/secure/index.xhtml" access="hasRole('ROLE_REFERENT, ROLE_SUBDEAN')" />
<security:intercept-url pattern="/secure/*" access="hasRole('ROLE_OMNI_ADMIN')" />
<security:intercept-url pattern="/**" access="isAuthenticated()" />
But now I have a problem that it is possible to acces url of my application, for example MY_APPLICATION/PririzMaven/secure/admin/updateRole.xhtml with role ROLE_ADMISSIONER, url ..../secure/subdean/* with this same role and so on... but it should by banned to this user.
Do you know where could be a problemme?
Assuming PririzMaven is the context path of your application, /secure/admin/updateRole.xhtml will be matched by the path /** and hence will be accessible to all authenticated users. You have no rule for /secure/admin. Note also that a single '*' does not match subpaths. For example, you should use /secure/admin/** to match everything under this path.
You should also enable debug logging and check how the rules are being applied - you should see the matchers being called against the incoming request URL and will see what is being compared and what is being matched against.
Finally, it's worth adding <security:debug /> at the top of your application context file, which will add other useful debugging information on request handling in a more human-readable format.
My question is similar to this one, but I can simplify it some. Basically I want to authenticate users through the remember me cookie, but I want everything on the server side to be completely stateless, i.e. never create a HttpSession. I have the following setup:
<security:http use-expressions="true" create-session="stateless" >
<security:intercept-url pattern="/index.jsp" access="hasRole('ROLE_ANONYMOUS')" />
<security:intercept-url pattern="/**" access="hasRole('ROLE_TEST')" />
<security:form-login login-page="/index.jsp" default-target-url="/home" always-use-default-target="true" authentication-failure-url="/index.jsp?login_error=1" />
<security:logout logout-success-url="/index.jsp"/>
<security:remember-me key="MY_KEY" />
</security:http>
<security:authentication-manager>
<security:authentication-provider>
<security:user-service>
<security:user name="testUser" password="testPassword" authorities="ROLE_TEST" />
</security:user-service>
</security:authentication-provider>
</security:authentication-manager>
I authenticate just fine with the username and password above and see the remember me cookie in my browser. That part of it is working great. However, I'm finding it is creating a session during this process. I thought the create-session="stateless" was supposed to prevent this. Am I missing something here?
After working with this more, I found out that it wasn't Spring Security that was creating the session. The index.jsp was creating a new session every time I hit it. I simply added <%# page session="false"> to the top of index.jsp, and now there are no sessions being created.