Announcement Announcement Module
Collapse
No announcement yet.
Is_authenticated_anonymously Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is_authenticated_anonymously


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

    What would be the difference between using
    Code:
    <intercept-url pattern="/index.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY"
    vs using
    Code:
    <intercept-url pattern="/index.jsp" access="ROLE_ANONYMOUS"
    ?

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

    and what if instead of
    Code:
    IS_AUTHENTICATED_ANONYMOUSLY
    i were to use
    Code:
    "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
    Code:
    ROLE_USER
    or both
    Code:
    ROLE_USER
    and
    Code:
    IS_AUTHENTICATED_ANONYMOUSLY
    ?

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

    And one more question : is there any reason why
    Code:
    access="IS_AUTHENTICATED_REMEMBERED"
    should ever be set on my patterns if using an
    Code:
    auto-config="true"
    ? Or does spring automatically enable that for all url patterns that restrict access to
    Code:
    ROLE_USER
    ?

  • #2
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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:

        Code:
          <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" />
        Last edited by ew0kian; Jul 29th, 2009, 03:36 PM.

        Comment


        • #5
          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.

          Comment


          • #6
            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" />
            Last edited by ew0kian; Jul 30th, 2009, 02:14 PM.

            Comment


            • #7
              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.

              Comment


              • #8
                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

                Comment


                • #9
                  Originally posted by ew0kian View Post
                  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,
                  Code:
                  access="isAuthenticatedFully() and hasRole('USER')"
                  The traditional attribute/voter system will still be supported, but EL will support more options and be more flexible.

                  Comment


                  • #10
                    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:

                    Code:
                    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.
                    Last edited by ew0kian; Jul 30th, 2009, 10:12 PM.

                    Comment


                    • #11
                      Well, things aren't made to confuse developers, at least not intentionally .

                      I think if you are a newcomer to the framework you need to realize that a lot of the code has been there for at least 5 years and has evolved since then into the current form. You have to make allowances for that. Most people will just accept that that's the way AuthenticatedVoter is now, because that's how someone wanted it to work, possibly for their own purposes when they wrote it. That's why I suggested you check out the forum history - it will be in there somewhere, but it's from before my time on the project. If you say that something should be different then there has to be a very strong justification for changing it, as you will break it for all the exisiting users who have come to expect it to work the (possible quirky) way it already does.

                      When Acegi started out, the kind of people who used it were pretty much hard-core developers who would look at the code to find out how it worked and how they could change it and add new stuff. One of its major attractions was its customizability which requires a knowledge of the code anyway. As time has gone by, more people are using it and a lot more who don't have the same in-depth knowledge. Adding things like the namespace has made it easier to knock up a simple configuration but also obfuscates the underlying beans and hides them from the user.

                      In an ideal word we would have everything documented and a complete set of tutorials to help people at every stage. I hope to get a chance to write a blog/tutorial on how to start to move on from the namespace to finding out how the framework architecture works and what the key classes are, but doing things like that has to be balanced with a whole pile of other project-related issues.

                      So in practice people have to make allowances and expect to dig a little to find out how things work. And if they don't quite work the way you expect, then you have to make allowances for that too .

                      Comment


                      • #12
                        i never said you intentionally made it confusing.

                        changing the xml syntax to the way i mentioned would make it easier for newcomers. that is the justification. the way it stands now it is confusing. what more do you want me to say to convince you?

                        it wouldnt break anything. you just change the syntax. why are you just assuming that it would break things? it seems you are just opposed to making things easier because you think people should be "hardcore" and spend alot of time digging around the code and reference manual when all they want to do is get some basic stuff running. if people want to use the old way you could let them use the old way.

                        all i'm suggesting is to save newcomers some time and confusion. you don't need to spend alot of time making a blog or writing a bunch of long tutorials. just change the syntax as i suggested to make things more clear, and make the tutorial have proper comments that explain what is going on. you are just dodging the real issue here by telling me a story about how old the framework is and who the original users were. do you want people to keep coming on these forums and asking the same questions over and over? do you want the framework to be accessible to more people? do you care about that sort of thing? if so then you can make the changes, if not then i guess there's nothing more i can say to you about this because you obviously don't want to address the problem.
                        Last edited by ew0kian; Jul 31st, 2009, 02:58 PM.

                        Comment


                        • #13
                          Originally posted by ew0kian View Post
                          i never said you intentionally made it confusing.
                          And I never said you did . I just meant that sometimes we can make things confusing, but that we don't necessarily mean to.

                          changing the xml syntax to the way i mentioned would make it easier for newcomers. that is the justification. the way it stands now it is confusing. what more do you want me to say to convince you?
                          The syntax you have suggested would not fit with the existing architecture. I've already explained that the framework has no concept of roles as such, so having specific attributes such as "rolesAllowed" doesn't make sense. Where it really comes apart is when someone wants to add their own attributes and custom voters. Let's say they have a DayOfTheWeekVoter which only allows the operation on a particular day and handles "DAY_" atttributes. If they want to annotate a method or URL with

                          Code:
                          access="DAY_MONDAY,ROLE_USER"
                          how would your syntax deal with this case? What if they have an IP_RANGE attribute and voter? It isn't possible to add a "dayOfTheWeekAllowed" or "ipRangeAllowed" attribute to the XML syntax (as you have done with rememberMeAllowed and rolesAllowed) because you don't know in advance how people are going to use it. Adding XML attributes for each possible type of access-control metadata is not a scalable approach and will make even less sense as we move towards the use of EL, where the access-decision logic is captured in the expression.

                          Comment


                          • #14
                            I agree that there shouldnt be an attribute for every possible type of access-control metadata.

                            I'm just suggesting a change to the syntax to make it easy to get the "basics" up and running with minimal complexity.

                            Maybe have the basic syntax like i suggested in addition to a custom attribute that would allow for putting custom things like ip ranges as you suggested.

                            most people probably just want to setup the guest vs user access controls. and as of now the tutorial sample and syntax is confusing for people trying to do that. which is why it would be beneficial to make an attribute that just allows for that and nothing else, and for there to be a tutorial sample that just does that and nothing else, and is well commented. currently that is not the case. which is why people are confused on the forums.

                            Comment

                            Working...
                            X