Currently:

                When a Subject creates an object in Grouper the system currently assigns "Admin" privileges to that subject if they do not already get "Admin" from inherited privileges to the new object.

 

Proposed:

                It would be helpful, for many use cases, if a Member ( Grouper local cache of the Subject ) could have a configuration that would request that a different Subject be used instead of themselves.

               

                This would be effective with or without Inherited Privileges and should be used drive towards a "group" instead of a "person" being privileged to all objects.

 

Example cases:

                Subject is an "Admin" of a single application in Grouper.

                A WebService account (acting on behalf of a connected application/service)

 

                All things they create should default to being owned by a group (Subject) that manages that application instead of the direct subject that created the object.

 

It would also be helpful if this could be a "list" of values for users who manage more than one application in Grouper. (A "default" could be identified for a Member too.)

                The UI could default to the default value and allow the user to select from the list of configured values before/during the create process.

                WS could allow the user to supply a value during create or use the configured default value.

 

It would also be helpful if the default value could be selected based on "location in Grouper" too. (An attribute on a parent stem could help with the selection of the correct value for a Subject. )