Is_authenticated_anonymously

[ew0kian]

I am very confused about how I should setup my <intercept-url> elements.

What would be the difference between using

<intercept-url pattern="/index.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY"

vs using

<intercept-url pattern="/index.jsp" access="ROLE_ANONYMOUS"

?

--------------------------------------------------------------

and what if instead of

IS_AUTHENTICATED_ANONYMOUSLY

i were to use

"ROLE_ANONYMOUS, ROLE_USER"

^^ Which one is preferred to use?

-------------------------------------------------------

Also why do I need to explicitly set / and /index.jsp url patterns instead of just /index.jsp? And do I need to explicitly set access on /logoff.jsp to be only

ROLE_USER

or both

ROLE_USER

and

IS_AUTHENTICATED_ANONYMOUSLY

?

------------------------------------------------------------------

And one more question : is there any reason why

access="IS_AUTHENTICATED_REMEMBERED"

should ever be set on my patterns if using an

auto-config="true"

? Or does spring automatically enable that for all url patterns that restrict access to

ROLE_USER

?

[Luke Taylor]

As with all access decision scenarios in Spring Security, it depends on the AccessDecisionVoter/AccessDecisionManager combinations that are in use.

IS_AUTHENTICATED_ attributes are handled by the AuthenticatedVoter and are hierarchical - i.e. IS_AUTHENTICATED_ANONYMOUSLY will include any fully authenticated user or remembered user. ROLE_ANONYMOUS will cause a grant vote from the RoleVoter, but only if the user is currently anonymous (i.e. it will vote to deny for authenticated users).

There is no connection between auto-config and IS_AUTHENTICATED_REMEMBERED. If in doubt, remove the auto-config and add the elements explicitly as described in the manual.

[Malhar]

Hi,

If you already implementing functionality for pre-authentication or if you have sso operation then you can go with the specific role name but if you dont have any role at the login level then for that perticular page go with the IS_AUTHENTICATED_ANONYMOUSLY.

[ew0kian]

thanks for the reply luke. you are very active on these forums and we appreciate it.

in the tutorial sample inside the <http auto-config="true"> there is:

  <intercept-url pattern="/secure/**" access="IS_AUTHENTICATED_REMEMBERED" />

so im just wondering why they use IS_AUTHENTICATED_REMEMBERED there? is it granting access to only people who have authenticated as role_user or is it also including users who are anonymous and haven't logged in yet? i am not using method level security so i realize this example may not apply to me but i am curious.

the full code they use inside the <http> element is pasted below:

<intercept-url pattern="/secure/extreme/**" access="ROLE_SUPERVISOR"/>
<intercept-url pattern="/secure/**" access="IS_AUTHENTICATED_REMEMBERED" />
<!-- Disable web URI authorization, as we're using <global-method-security> and have @Secured the services layer instead
<intercept-url pattern="/listAccounts.html" access="IS_AUTHENTICATED_REMEMBERED" />
<intercept-url pattern="/post.html" access="ROLE_TELLER" />
-->
<intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />

[Luke Taylor]

AuthenticatedVoter has no concept of roles. If you read the Javadoc for the class it explains things

http://static.springsource.org/sprin...atedVoter.html

Applications which have remember-me authentication enabled may still require full authentication to access certain parts of the application.

[ew0kian]

thanks for the link. it says:

The "REMEMBERED" will grant access if the principal was either authenticated via remember-me OR is fully authenticated.

it seems very counter intuitive. it would be more intuitive if it was setup so that you specify the levels individually, instead of using the hiearchal setup.

because when i see IS_AUTHENTICATED_REMEMBERED i just assume it is talking about remembered logins and only remembered logins.

perhaps if the samples tutorial had this information included in some comments it would be beneficial for first time users that don't know to look in the javadoc for AuthenticatedVoter

Also, the mixing of access rules based on individual roles such as ROLE_TELLER and access rules based on authentication mechanisms like IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED, IS_AUTHENTICATED_ANONYMOUSLY just seems weird.

something like the following would be better:

<nonAnonymousRole-url pattern="/secure/**" rolesAllowed="ROLE_TELLER, ROLE_CUSTOMER" rememberMeAuthAllowed="true"
<anonymouRole-url pattern="/index.jsp" />

[Luke Taylor]

There aren't many scenarios that would involve only allowing access to remember-me users. If you search the forum, you will probably find the original discussions which resulted in the appearance of AuthenticatedVoter.

Adding a comment on the attribute (or in the description of the sample app in the manual) is probably a good idea - prior to the use of namespace configuration, all the beans were declared explicitly, so it was easier to understand which beans were involved and what Javadoc to look at.

Spring Security doesn't really have a concept of "allowed roles". The architecture is built around the idea of security configuration attributes (metadata) and voters which consume them. This allows much greater scope for customization.

[ew0kian]

There aren't many scenarios that would involve only allowing access to remember-me users.

Nowhere in my post did I suggest only allowing access to remember-me users.

I'm saying that the xml syntax needs to be changed so that the access attribute isn't a catch all place for setting up two very distinct things:

1) mechanism for authorization: remember-me (previous login), anonymously authenticated (no login), authenticated (logged in explicitly)

2) roles allowed: ROLE_TELLER, etc

[Luke Taylor]

Nowhere in my post did I suggest only allowing access to remember-me users.

I thought that's what you were referring to when you said "i just assume it is talking about remembered logins and only remembered logins" .

I was trying to explain why it was probably coded to assume that a fully-authenticated user can do everything a "remember-me" user can. i.e. why the attributes are hierarchical.

I'm saying that the xml syntax needs to be changed so that the access attribute isn't a catch all place for setting up two very distinct things:

1) mechanism for authorization: remember-me (previous login), anonymously authenticated (no login), authenticated (logged in explicitly)

2) roles allowed: ROLE_TELLER, etc

These are both about authorization, so I don't really see that there is much of a distinction or a requirement for a completely new syntax. One is basing the authorization decision on the type of authentication that took place and the other on matching the user authorities against the roles specified.

In 3.0 the recommended approach will be to use EL for the "access" attribute, so you will be able to use an something like, for example,

access="isAuthenticatedFully() and hasRole('USER')"

The traditional attribute/voter system will still be supported, but EL will support more options and be more flexible.

[ew0kian]

I don't think there should be a way to only allow remember-me logins, I was just saying that when you see the following in a sample tutorial (without the prior knowledge of the hierarchical structure involved):

<intercept-url pattern="/secure/**" access="IS_AUTHENTICATED_REMEMBERED" />

The assumption is that access is only going to be allowed for remembered users. i.e. if you are just reading it at face value as an ignorant newcomer to the the spring security framework. Sure the developer should have gone through their due diligence and read the reference manual and javadocs, and after a while it may sink in that the access attribute can handle both roles and auth types, and that there is a hierarchical nature to auth types meaning that IS_AUTHENTICATED_REMEMBERED includes IS_FULLY_AUTHENTICATED, but why make it so confusing for the developer? that's what i'm saying here. That this framework is complicated enough without adding additional complexity.

i don't think you have to trade flexibility for ease of use for newcomers. that EL expression language you mention is nice in that it would let you put two things in the same statement, and if used in the tutorial would implicitly tell the reader that both auth type and role can be specified in the access property, ie:

access="isAuthenticatedRemembered() and hasRole('USER')"

But the hierarchical nature of auth types still exists and is exposed to the developer in even beginning samples, and that would still cause confusion and should be abstracted from the end developer's xml syntax.

In addition, just because both auth type and role allowed are "about authorization" doesn't mean that you should be cramming both into the same attribute if its going to create ambiguity. Perhaps access is too loose of a word to be used as a property. To me access just means who can get in. It doesn't mean how they can get in. That's why in my example of how it should be, the word access isn't even used at all.