[RANGER-324] Phase-II - REST, Store: validation of policy/service/service-def

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.5.0
• Assignee: Alok Lal
• Reporter: Alok Lal
• Created: 23/Mar/15 04:54
• Updated: 19/May/15 07:32

Description

Policy/Service/ServiceDef validation should be added during create/update/delete operation. Here are some of the validations to add:

• values are provided for all mandatory fields (names, resources, etc)
• values are valid (for example: based on validationRegEx in the resource def, enum values, no duplicate names for service-def/service/policy-within-a-service)
• ensure that user has permissions to create/update/view policy/service/service-def
• check for conflicting/overlapping policies

Issue Links

• is a clone of: RANGER-278 REST, Store: validation of policy/service/service-def

Sub-Tasks

• Service validation: validate the data values sent in for parameters.: Open
• Policy validation: validate policy information about conditions against condition definition: Open
• All validations: validate that version of entity matches its current version to avoid loosing changes due to stale update.: Open
• Service def: deletion: deny deletion if def is referenced elsewhere.: Open
• Service: deletion: deny deletion if def is referenced elsewhere.: Open
• Validation: validate context enhancers details in policies and service def: Open
• Turning on new validation rules on an existing system/policies could cause problems. We need a way to mitigate those possible problems.: Open
• Policy validation: resource uniqueness: to guard against someone editing the resource value directly, we should auto-heal the hash signatures of resources that are used for uniqueness check: Open
• REST API should return all of the the failure reasons contained in exception thrown by validation: Open