6 Replies Latest reply on Jan 24, 2013 7:00 AM by 927480

    Security Setup not working


      As a part of security setup we have done the following things:

      - Users created and assigned as members of groups. One group is created per entity.
      - Groups have been provisioned for the application and given security class access
      - Security classes have been created and attached to metadata. for e.g, all entities have been attached a Sec class in properties.
      - In application settings, Node Security = Entity, Security for Entities is Checked, Enable Metadata Sec Filtering is also checked.

      Even after this, the security setup doesnt seem to be working. A user with minimal provision (only Data Form Writeback from Excel) and no security class access is also able to see all the entities, also other forms, grids, etc which have been attached diff security classes. He is able to edit the forms and grids.

      Can anyone help out as to what is it that we are missing?
        • 1. Re: Security Setup not working
          Erich Ranz
          Sounds right. Does security work if you create a native ID and provision/assign it directly to the user?
          1 person found this helpful
          • 2. Re: Security Setup not working
            What role(s) do the users have? Any user with the Administrator role bypasses class access checking and is assumed to have full access to everything. No other role provides this bypass.

            Editing forms and grids has nothing to do with Entity security. If the forms and grids have no class assigned to them, they use the [Default] class which I suggest all users have All rights to anyway. If there are grids/forms you do not want users to change, you should assign a specific class to them, other than [Default].

            Enable Metadata security filtering should restrict users from seeing the members for which they have None access to, but as long as they have Read or All access, they will see the members in a pick list.

            1 person found this helpful
            • 3. Re: Security Setup not working
              Yes, I have tried that as well. Created a test user with 'Data form writeback to excel' provisioning. Given access to Sec class of just one entity. But on logon, the user can see all entities in the entity dimension in a data form or grid and can select it as well.
              • 4. Re: Security Setup not working
                Hi Chris,

                No, the users do not have an admin role, but only one of the basic roles such as 'Data form writeback to excel' or 'Default ' assigned. Also, yes, our forms and grids too have a seperate security class attached to them which the user doesnt have access to, but he can still see all those forms and grids, and also all the entities while selecting one. On top of that the user can also go into the Form designer and edit it.

                On doing some more R&D, i observed that even if my user is provisioned to only CONSOL1 application, he can access even CONSO2, 3 and other applications via the Navigate -> Applications -> Consolidation menu and can even open forms and grids in the application. It seems that there is no security restriction on the user even across applications
                • 5. Re: Security Setup not working
                  It sounds like your user could be part of a group that has roles beyond what you think he should have. You can run a security report from Shared Services that shows the roles which the user has both directly and inherited. In Shared Services select:

                  Administration > View Report
                  Show Effective Roles = Yes
                  Shows what users inherit from group membership

                  Look through the list and you can see if the user is a member of another group that has rights that you may not be aware of.

                  1 person found this helpful
                  • 6. Re: Security Setup not working
                    Thanks Chris, but we discovered what the issue was. Somehow, for each application (even new ones which we created for testing the issue), the WORLD user group was automatically getting administrator provisioning for the applications.

                    Don't know why and how this was happening, but removing the provisioning for the WORLD group resolved the issue :)