In this next installment of our series on Golden Rules for Metadata Security Model Design, this time we'll look at Rule 6: Design your security model first and implement it early.
If you missed the first three posts in this series, you should read part 1, part 2 and part 3 before this one.
I want to acknowledge the work of Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, who published the first six of these eight Golden Rules in their paper ‘Metadata Security in SAS® 9.4 – Step-by-Step’. I have expanded on their work (adding two more rules, additional explanation, and much else besides) in an overall GEL Recommended SAS 9.4 Security Model Design approach, which I recently published in the SAS Community Library - here are part 1 and part 2.
Rule 6: Design your security model first and implement it early
Detail
Design an outline structure of your security model, with examples of detailed structural elements that you will repeat per team, project, data topic, business unit etc., early in the life of a SAS deployment.
Document your design clearly, in enough detail that someone else can understand it and implement it.
Be prepared to change the names of objects in your security model from time to time, but avoid major redesigns in a live system.
Explanation
A security model implemented in a haphazard way without a clear design and without good design documentation is likely to contain numerous design errors and likely to be implemented badly. Security models may appear simple, but are usually complicated. You must make a design and follow that design closely in your implementation of the security model.
Ninety percent of the effort involved in creating a robust, maintainable security model is the design and the documentation. In comparison, implementation of the model is very easy. Do not be tempted to skip the design and go straight to the implementation work.
The downside of designing your security model early is that the names of groups, and their associated ACTs, folders etc. chosen early in the life of a SAS deployment are often found to be inadequate as the use of the SAS deployment matures. A group which is named “Developers” early on in the a DI project’s delivery lifecycle, intended to represent any user performing any type of development may need to be changed when it later becomes clear that you need “DI Developers” and a new group “VA Report Developers”, with corresponding new ACTs and folders. Your design should take account of the fact that you expect to have to change the names of some objects in the security model over time, to better reflect what they now are. Minor changes, such as to object names (groups, ACTs, folders) can usually be managed without too much impact.
Some ongoing change in your wider security model design over time is unavoidable, as your customer’s work and their organizational structures evolve. However, it is exceptionally disruptive to users of a SAS deployment for major design changes to the security model to be made while the application content that those users work with is in development, and it is even worse once the deployment is in live production use. Implementing the security model early in the lifecycle of the SAS deployment will minimize this disruption.
If you are unfortunate enough to take over responsibility for an existing, poorly designed security model, consider designing a new model starting from the templates presented in the GEL Recommended SAS 9.4 Security Model Design series of papers (published here as part 1 and part 2), and re-building the user’s application content into that new model. Using the object naming conventions described in these papers for multitenancy, you should be able to isolate the groups, ACTs and folders etc. in your new security model design from any existing groups, ACTs and folders etc. in the existing poorly-designed security model. Doing this is likely to be less work, and less disruptive to end users, than trying to ‘improve’ an existing security model structure bit by bit.
The series concludes next time, when we look at Rules 7 and 8. See you then!
