Announcement Announcement Module
Collapse
No announcement yet.
(new)ACLs, Before Invocation, AfterInvocationProviderManager and groups/permissions Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • (new)ACLs, Before Invocation, AfterInvocationProviderManager and groups/permissions

    Hi,

    I know, that this has been discussed quite often and I have preused lots posts concerning this subject, yet there are still a few open questions and I'd be really grateful for your input.

    AFAIU (please correct me if I'm wrong) with the new ACL package, Acegi checks authorization at two points:
    1. BeforeMethodInvocation: Roles / permissions are checked (e.g. voters)
    2. AfterMethodInvocation: Access to specific objects (object identities) is checked (e.g. AclEntryAfterInvocationProvider)

    As discussed in a previous thread (http://forum.springframework.org/showthread.php?t=14696) it is fairly simple to map roles to groups and/or users. One sample scenario could be as follows:
    user ->(belongs to) group -> (has) permissions, yet AFIK this only applies to the BeforeMethodInvocation check. What I am wondering is how to apply the group concept to the AfterMethodInvocation check - is it possible to restrict access to a specific object to a certain group? Can Acegi do this out of the box?

    Thanks,
    Tom

  • #2
    After looking some more at the table structure of the new ACL package, I guess my question boils down to this: Does the SID entry in ACL_SID have to be a real user or can I put a group here? How would I then map the users to their groups? I assume this would have to be done programmatically - but where? Is this the correct approach at all?

    Thanks,
    Tom

    Comment


    • #3
      The final attempt

      Does Acegi support the group concept on the ACL/object identity level? I've just been looking at the contacts sample from Acegi 1.0.3 again - DataSourcePopulator to be more specific. All entries in the ACL_ENTRY table have a specific owner and a specific mask. What I am looking for is UNIX-like behaviour where it is possible to assign group-access as well.

      Example:

      foo.bar.Book with id 1 belongs to user Moe. A group called The Be Sharps has read access - all other access is denied (rwx/r--/---)

      Is it possible to achieve this with Acegi, without creating the ACL entires for each member of the group? If so, I'd be grateful for any hints, pointers, etc.

      Thanks,
      Tom

      Comment


      • #4
        The sid entry can be a principal(user) or an authority/role(group) ie its implementations are PrincipalSid and GrantedAuthoritySid. If you look at the acl_sid table the principal field is a boolean indicating if the record represents a principal or authority.

        In our application we have the same set up as you (user ->(belongs to) group -> (has) permissions). We flatten the group / permissions into a single authority list. We use the permissions for the role voter to block entire operations at the service level and we use the groups for acl security (so we have a sid retrieval strategy that only returns the principal and the group authorities).

        The ACLs then work against group or user.

        Comment


        • #5
          Hi David,

          Originally posted by david_geary View Post
          The sid entry can be a principal(user) or an authority/role(group) ie its implementations are PrincipalSid and GrantedAuthoritySid. If you look at the acl_sid table the principal field is a boolean indicating if the record represents a principal or authority.
          I was wondering about that field as well, didn't figure out its meaning though. Thanks for clearing that up!

          Originally posted by david_geary View Post
          so we have a sid retrieval strategy that only returns the principal and the group authorities
          Does that mean, that all you had to modify was the retrieval strategy? That would be really nice because I already have a custom retrieval strategy. Thanks for the pointers, I'll give it a try. One more question though: where did you find this information? Is there documentation?

          Thanks again,
          Tom

          Comment


          • #6
            It depends how you organise your authority list - because we have global permissions and groups in our authority list it makes sense to filter out the bits we don't need for performance, but it would work without that i think anyway.

            It should work pretty much as is if you populate your authorities list with your groups.

            There isn't much documentation really - a little in the reference manual, the code and these forums is about it.

            Hopefully some better documentation will be available soon.

            Dave

            Comment


            • #7
              Putting it in a nutshell

              So basically, this means, that:
              1. there can be groups, denoted by a false in the PRINCIPAL column of the ACL_SID table
              2. goups can be owners of objects
              3. real principals can be mapped to groups via an additional table (?)
              4. a modfied SidRetrievalStrategy has to take care of loading the correct groups for a given principal (?)
              I am not sure about the last two points - is there already support for this feature in Acegi or do I have to implement it?

              Thanks,
              Tom

              Comment


              • #8
                The mapping between users and groups is nothing to do with the ACLs or authorization in general - this should be done as part of your authentication.

                The ACLs use the principal and authority list (groups if you want) in the authentication object - this should have been populated by what ever you are using to authenticate with eg LDAP or your own implementation of UserDetailsService

                Comment


                • #9
                  Got it

                  Hello David,

                  sorry - I guess I was a little dense. The part that I didn't get, was simply that if you put an entry in ACL_SID with Principal false, than this (String)entry simply has to match your roles/groups which are initially loaded during the authentication. That was all I was missing - after that Acegi worked its magic - now my ACLs are working and I am happy. Thanks again for saving my friday.

                  Regards,
                  Tom

                  Comment

                  Working...
                  X