Spring security configuration:
intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"`
intercept-url pattern="/**" access="ROLE_USER"
form-login login-page='/login.jsp'
I am new in spring security. I have some questions:
what is meaning of "IS_AUTHENTICATED_ANONYMOUSLY"?
why there is error in it? (i read in documentation that there is error in it due to infinite loop.)
If there are more intercept rules than how it will be evaluate?
First things first.. Always Always always give anonymous access to your Login and Registration screens. ANONYMOUS= NO AUTHENTICATION REQUIRED. Failing to do so will never allow any user to use ur application and ur page will end up loading forever.. Also keep your static resources (CSS, JS, Images etc) away from security filters. In MOST of the cases these static resources never require security
This code snippet explains the above description:
<security:http pattern = "/css/**" security = "none"/>
<security:http pattern = "/anonymous/**" security = "none"/>
<security:http pattern = "/loginpage/**" security = "none"/>
<security:http pattern = "/forgotpassword/**" security = "none"/>
<security:http pattern = "/registerpage/**" security = "none"/>
<security:http pattern = "/js/**" security = "none"/>
<security:http pattern = "/images/**" security = "none"/>
IS_AUTHENTICATED_ANONYMOUSLY - this is means anyone can access this page without logged in to your system.
ROLE_USER - Means only users who have ROLE = ROLE_USER can access those URLS that match with your pattern.
If There are more intercept rules than there are follow the same as above, one - by - one but ORDER OF THIS MATERS for the matching. If your first pattern match with your requested URL than it will not look for other. so during given intercept rules you need to take care of the order in which they are written.
Hope this help.
what is meaning of "IS_AUTHENTICATED_ANONYMOUSLY"?
this means anyone can access this page without logging in.
why there is error in it?
You have an infinite loop because the login page should not be secured. The login page should not be secured for anyone to be able to enter it's credentials.
Related
I have this case in my project:
Imagine we have these two lines to define Spring Security access rules:
<intercept-url pattern="/xxx/*" access="isAuthenticated() and (hasRole('roleA') or hasRole('roleB'))" />
<intercept-url pattern="/xxx/yyy*" access="isAuthenticated() and (hasRole('role1') or hasRole('role2'))" />
These two patterns are nested, and an user may have a combination of roles like "roleA" and "role1", or "roleA" and "role2". What I want to achieve, is make users have "roleC" and "role1" cannot access to /xxx/yyy*.
So my question is:
When user with "roleC" and "role1" wants to get access with pattern "xxx/yyy222.html", will all lines of access rule be checked, or only the second line is checked? When considering the access rules for the second line, can I take it for granted that user can get into the url "xxx/yyy*" have only "roleA" and "roleB", or must I put complete rules for each single lines of rule?
The intercept-urls are processed in the order they are defined, the first with a pattern that matches the request path decides the access.
When user with "roleC" and "role1" wants to get access with pattern
"xxx/yyy222.html", will all lines of access rule be checked, or only
the second line is checked?
This matches the pattern of the first line and access will be denied.
When considering the access rules for the second line, can I take it
for granted that user can get into the url "xxx/yyy*" have only
"roleA" and "roleB", or must I put complete rules for each single
lines of rule?
The second line will never be evaluated. Be sure to specify more specific pattern first.
What I want to achieve, is make users have "roleC" and "role1" cannot
access to /xxx/yyy*.
Maybe you want something like:
<intercept-url pattern="/xxx/yyy*" access="isAuthenticated() and !(hasRole('roleC') and hasRole('role1'))" />
I only need Spring Security Basic HTML Authentication Filter in my project to secure the REST API.
As I'm new in Spring Security, I'm wondering which filter for the rest filter chain is not needed. I've done some research said the securityContextPersistenceFilter is necessary to set up in front of any authentication filters, how about the others?
securityContextPersistenceFilter //It should be needed..
logoutFilter, // I'm not so sure about this..
authenticationProcessingFilter, // I guess it should not be necessary, because user will just use header to hold the credential
concurrentSessionFilter, // I guess no
basicAuthenticationFilter, // Should be needed
securityContextHolderAwareRequestFilter, //It's required because the need to judge the ROLE of the user
rememberMeAuthenticationFilter, // I guess no
anonymousAuthenticationFilter, // I'm not so sure
exceptionTranslationFilter, // Should be needed
filterInvocationInterceptor // I'm not so sure
Am I right about everything in the list?
I think you need only:
securityContextPersistenceFilter // It should be needed..
basicAuthenticationFilter, // Should be needed
securityContextHolderAwareRequestFilter, // for internal stuff also
anonymousAuthenticationFilter, // for default/non-logged in user
exceptionTranslationFilter, // catches security exceptions
filterInvocationInterceptor // defines which url are accessible, etc
There is also good description: http://docs.spring.io/spring-security/site/docs/3.0.x/reference/security-filter-chain.html#d0e2952
In appSecurity.xml I have this:
intercept-url pattern="/users/profile/**" access="hasRole('VIEW_PROFILES')".
intercept-url pattern="/users/profile/edit/**" access="hasRole('EDIT_PROFILES')"
I have a page /users/profiles/edit/addnew and when user with role VIEW_PROFILES is trying to access this page, he gets it successfully but the access to user with role EDIT_PROFILES is blocked.
What I'm doing wrong?
Since "/users/profile/edit/" is more specific than "/users/profile/", it should be placed higher in the list.
Why
Patterns are always evaluated in the order they are defined. Thus it is important that more specific patterns are defined higher in the list than less specific patterns. This is reflected in our example above, where the more specific /secure/super/ pattern appears higher than the less specific /secure/ pattern. If they were reversed, the /secure/ pattern would always match and the /secure/super/ pattern would never be evaluated.
Source: Core Security Filters
Both John Farrelly and Ritesh are correct. The intercept-url patterns are matched in the order listed. As soon as a match is found, the rest of the patterns specified are ignored. This is why you should list more specific patterns earlier.
In your case, the pattern for /users/profile/edit/somepage matches the pattern specified in the first intercept-url pattern, so Spring is appropriately checking to see if the user in question has the access role specified. Apparently, your EDIT_PROFILES users do not have VIEW_PROFILES authority, so they are being denied access. Likewise, your intention to restrict access to ../edit/ to users with EDIT_PROFILES authority is being undermined by the earlier statement which grants access to users with VIEW_PROFILES authority.
Switch the order for the easy fix, and you probably want to give your EDIT_PROFILES users VIEW_PROFILES authority (in addition to EDIT_PROFILES authority). Then, consider using access="hasAnyRole('REQUIRED_ROLE')" rather than access="hasRole('REQUIRED_ROLE')", to simplify the access statements.
Make sure that your EDIT_PROFILES rule is above the VIEW_PROFILES rule. If you take a look at the expression for VIEW_PROFILES, you will see that it includes every URL that would match EDIT_PROFILES. That means that if the VIEW_PROFILES rule is first, spring security will never bother to try the EDIT_PROFILES rule.
<security:intercept-url pattern="/person/**"
access="isAuthenticated()" />
<security:intercept-url pattern="/person?reg"
access="isAnonymous()" />
I want for filter to intercept all of the requests that are /person/blabla etc.
But there should be a single one available to anonymous users to register themself.
Whenever I introduce the first rule all sub requests are protected including the bottom one which is not what is required.
If I don't introduce first then the bottom request is allowed, but also all subsequent requests such as /person/myProfile can be accessed by anonymous user.
From the Spring Security docs:
You can use multiple elements to define different access requirements for different sets of URLs, but they will be evaluated in the order listed and the first match will be used. So you must put the most specific matches at the top.
Also, spring uses ant-style pattern matching by default, which doesn't include the parameters when trying to make a match. You're wanting to also match on whether or not a parameter exists. In order to do that, you're going to need to set regex matching via the request-matcher attribute on http.
<http request-matcher="regex">
<security:intercept-url pattern="\A/person\?reg.*\Z" access="isAnonymous()" />
<security:intercept-url pattern="\A/person/.*\Z" access="isAuthenticated()" />
</http>
i tried to search for any previous post related to my issue but couldnt find any. I have a scenario where in page handles 3 different scenarios and one of them not working. This page returns different content depending on if the user is authenticated or anonymous.
localhost:8080/myApp/muUrl?test=authenticatedContent - > used for Scenario 1 & 2
localhost:8080/myApp/muUrl?test=anonymousContent -> used for Scenario 3
Scenario:
1) Authenticated user accesing the page url - the user gets displayed correct information. Works fine
2) Anonymous user accesing page URL with parameters that requires authentication - If anonymous, there is second level of check on the content they are accessing. for example, based on the GET parameters, there is custom logic to determine if the user has to be authenticated. In which case the page gets redirected to login page (WORKS fine).
3) Anonymous user accessing page URL with parameters that doesnt need authentication - in this case i get the SAvedRequest and redirect to the URL which is taking me to an infinite loop.
Am i missing something very obvious or is there a way in AuthenticationProcessFilterEntryPoint to say "DON'T redirect to LOGIN page but process it" ?
thanks.
I found a solution at last (someone suggested it to me on the Spring forums).
The idea is to use the #PreAuthorize annotation in the controllers as described here: see here
See code sample below:
#RequestMapping("/")
#PreAuthorize("isAuthenticated()")
public String authenticatedHomePage() {
return "authenticatedHomePage";
}
#RequestMapping("/")
public String homePage() {
return "homePage";
}