Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: SVN trunk
    • Fix Version/s: SVN trunk
    • Component/s: framework
    • Labels:
      None

      Description

      Parent Task for Security Re-Implementation – Details defined here: http://docs.ofbiz.org/x/-B0

        Issue Links

          Activity

          Hide
          Adrian Crum added a comment -

          Andrew,

          Why doesn't the new security API accommodate an admin permission? If the goal is to make the new API more like other software, shouldn't it include a supervisor/super user/admin permission?

          Show
          Adrian Crum added a comment - Andrew, Why doesn't the new security API accommodate an admin permission? If the goal is to make the new API more like other software, shouldn't it include a supervisor/super user/admin permission?
          Hide
          Andrew Zeneski added a comment -

          Adrian,

          I'm not sure I understand what you mean. There are "base" permissions :
          access, create, read, update, delete

          Which are all part of the seed data and associated with the FULLADMIN security group. These are indeed "admin" permissions since there is no granularity attached.

          Check out the comments on the page : http://docs.ofbiz.org/x/JR4 there a brief description on how these permissions are handled. If I'm missing something, or not answering your question please let me know.

          Show
          Andrew Zeneski added a comment - Adrian, I'm not sure I understand what you mean. There are "base" permissions : access, create, read, update, delete Which are all part of the seed data and associated with the FULLADMIN security group. These are indeed "admin" permissions since there is no granularity attached. Check out the comments on the page : http://docs.ofbiz.org/x/JR4 there a brief description on how these permissions are handled. If I'm missing something, or not answering your question please let me know.
          Hide
          Adrian Crum added a comment -

          Andrew,

          Following your logic then, FULLADMIN would have to include ALL possible permissions. Maybe it would help if your new framework could accept widlcards:

          access:*
          create:*
          read:*
          update:*
          delete:*

          Show
          Adrian Crum added a comment - Andrew, Following your logic then, FULLADMIN would have to include ALL possible permissions. Maybe it would help if your new framework could accept widlcards: access:* create:* read:* update:* delete:*
          Hide
          Adrian Crum added a comment -

          Also, it would be helpful if the new API would return all permissions for a given context. I had suggested this on the dev mailing list some time ago, and there seemed to be some interest.

          Show
          Adrian Crum added a comment - Also, it would be helpful if the new API would return all permissions for a given context. I had suggested this on the dev mailing list some time ago, and there seemed to be some interest.
          Hide
          Andrew Zeneski added a comment -

          To answer your first question, if a user has 'update' that is effectively the same as 'update:', the * is just not needed. If the user has 'update:party' then that would mean 'update:party:'. We define the most granular permission required when defining the permission for a piece of functionality. So, to update person information the permission would be defined as 'update:party:detail:$

          {partyId}

          '. The partyId would be expanded at runtime.

          The user will need either:
          update
          update:party
          update:party:detail

          Or if none of these permissions are associated with the user, then the DA logic kicks in to see if they are allowed to access the single party record.
          So,

          1. 'update' means update anything in the entire system,
          2. 'update:party' means update anything in the party app.
          3. 'update:party:detail' means update any party's detail information (name, groupName, etc)

          As for you second comment, I'd like to hear more about this. I'm not sure how that would look and what the definition of 'context' is in this case. But I'm happy to add something which are helpful! We can take this over to the dev list if you like.

          Show
          Andrew Zeneski added a comment - To answer your first question, if a user has 'update' that is effectively the same as 'update: ', the * is just not needed. If the user has 'update:party' then that would mean 'update:party: '. We define the most granular permission required when defining the permission for a piece of functionality. So, to update person information the permission would be defined as 'update:party:detail:$ {partyId} '. The partyId would be expanded at runtime. The user will need either: update update:party update:party:detail Or if none of these permissions are associated with the user, then the DA logic kicks in to see if they are allowed to access the single party record. So, 1. 'update' means update anything in the entire system, 2. 'update:party' means update anything in the party app. 3. 'update:party:detail' means update any party's detail information (name, groupName, etc) As for you second comment, I'd like to hear more about this. I'm not sure how that would look and what the definition of 'context' is in this case. But I'm happy to add something which are helpful! We can take this over to the dev list if you like.
          Hide
          Adrian Crum added a comment -

          Andrew,

          Thank you for the explanation. It's starting to make more sense now.

          Getting all permissions would look something like:

          *:party

          where party is the context and a list of party permissions are returned. This is sorely needed, because right now if you need to query multiple permissions, you have to make multiple permission service calls. Let's say a block of code needs to check view, create, and update permissions (to control the display of screen elements for example). Right now three permission checks would have to be made. It would be nice to get a list of permissions, then check the list for view, create, and update.

          The Jira comments are sent to the dev list, so this discussion is already there.

          Show
          Adrian Crum added a comment - Andrew, Thank you for the explanation. It's starting to make more sense now. Getting all permissions would look something like: *:party where party is the context and a list of party permissions are returned. This is sorely needed, because right now if you need to query multiple permissions, you have to make multiple permission service calls. Let's say a block of code needs to check view, create, and update permissions (to control the display of screen elements for example). Right now three permission checks would have to be made. It would be nice to get a list of permissions, then check the list for view, create, and update. The Jira comments are sent to the dev list, so this discussion is already there.
          Hide
          Adrian Crum added a comment -

          Thinking about this more...

          (sorry - it would have been helpful to discuss this on the dev ml before you got started)

          it would be awesome if the new permissions could be expressions. Example:

          (update:context1 | update:context2) & update:context3

          which would express "if (update:context1 OR update:context2) AND update:context3."

          I know there have been times when this would have been helpful in the permissions service interface. It would eliminate a lot of little mini-language permissions scripts. The single permission check for service calls is very limiting.

          After working with UEL, I can see where implementing functions would be helpful too:

          update:context1 & someFunction(...)

          Show
          Adrian Crum added a comment - Thinking about this more... (sorry - it would have been helpful to discuss this on the dev ml before you got started) it would be awesome if the new permissions could be expressions. Example: (update:context1 | update:context2) & update:context3 which would express "if (update:context1 OR update:context2) AND update:context3." I know there have been times when this would have been helpful in the permissions service interface. It would eliminate a lot of little mini-language permissions scripts. The single permission check for service calls is very limiting. After working with UEL, I can see where implementing functions would be helpful too: update:context1 & someFunction(...)
          Hide
          Andrew Zeneski added a comment -

          unused

          Show
          Andrew Zeneski added a comment - unused

            People

            • Assignee:
              Andrew Zeneski
              Reporter:
              Andrew Zeneski
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 624h
                624h
                Remaining:
                Time Spent - 48h Remaining Estimate - 576h
                576h
                Logged:
                Time Spent - 48h Remaining Estimate - 576h
                48h

                  Development