In the final part of this series on Golden Rules for Metadata Security Model Design, we look at Rule 7: Apply ACTs to folders where possible, and Rule 8: Name security model objects clearly and simply. If you missed the first four posts in this series, you should read part 1, part 2, part 3 and part 4 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 7: Apply ACTs to folders where possible   Detail Where possible, apply ACTs to metadata folders, rather than to objects. Only where that is not possible because the object is not in a metadata folder, you may apply ACTs to an object directly.   Explanation For example, to secure a library, put the metadata library definition in a metadata folder, and apply the necessary ACTs to that folder. As another example, if tables should have the same permissions as their parent library, put those tables in the same folder as the library. But where a table requires different permissions to its parent library, put it in another folder (e.g. a subfolder of the folder containing the library), and apply ACTs to that folder to set the required permissions for the table. Some objects which must be secured are not in the metadata folder tree. In order to set permissions on those objects and prevent them from being modified by users who should not be able to modify them, it is necessary to apply ACTs to the objects directly. Examples object types for which this applies include ACTs themselves, Application Server Contexts such as SASApp and SASMeta, metadata server and logical server definitions, spawners etc. Several examples are given in the accompanying paper ‘Recommended SAS® 9.4 Security Model Design: Data Integration’ (available here) in section ‘9.1.1 Apply ACTs to the DI ACTs and to SASApp’.   Rule 8: Name security model objects clearly and simply   Detail Groups should be named to clearly indicate what they are. ACTs should be named for the single group they feature, where possible.   Explanation Groups in an LDAP Provider such as Active Directory should be named in a way which satisfies the corporate naming convention for LDAP groups, while also indicating that the group is associated with a specific SAS deployment, tenant and or project. Good elements to include in the group name are: “SAS” (to distinguish the group from Active Directory groups which have nothing to do with SAS) The name of the whole SAS ecosystem if the customer has more than one (e.g. Marketing, Drug Development, Credit Risk, Pensions, Polling Data, Aerospace, Shipping) – a large SAS customer may have multiple SAS ‘applications’ built on entirely separate sets of hardware and managed essentially separately from each other, yet they may share a common corporate LDAP service. You should omit this element if the customer has only one SAS ecosystem or environment. If there are multiple SAS deployments in one ecosystem, the name of the SAS deployment within in its ecosystem (such as Dev, Test or Prod). In the LDAP service, there will be groups with otherwise identical names, one set for each of the SAS deployments n the customer’s ecosystem (Dev, Test and Prod). Having the name of the SAS deployment as one part of the group name helps the SAS and LDAP administrators distinguish between the groups belonging to for each separate SAS deployment, in the directory service. If relevant, the name of the tenant organization and/or project within the ecosystem, when a single SAS deployment or ecosystem us used by several different companies, divisions, departments, teams or projects. The part of the group name which indicates what its members do in the SAS deployment, e.g. DI Developers, VA Report Designers etc. In an organization with many SAS ecosystems, each having multiple tenants, and each tenant having multiple projects, the names of groups in Active Directory can be long and complex. Dynamic groups (i.e. groups which are synchronized into SAS metadata from an LDAP service provider) should have names which match the name in that LDAP service provider as closely as possible. This is why in ‘Table 3 – Example group names in Active Directory (or another LDAP service)’ in the Core Principals and Practices paper (attached to my recent post here), the first column is titled ‘Example Active Directory Group Name , also name of corresponding dynamic group in SAS metadata’. Keeping the names the same or very similar same makes it easier for administrators to understand which groups correspond to each other later. One element you may consider removing from group names as you synchronize them with SAS metadata is the part which identifies the deployment within the ecosystem (e.g. Dev, Test or Prod). If you choose to implement shadow groups (static groups which mirror your dynamic groups, see section 5.3.5 and Appendix B – Shadow Groups in the Core Principals and Practices paper, you can keep the deployment name element in the dynamic group name. If you will use dynamic groups directly in ACTs (more on this in sections 5.3.3 and 5.3.4 of that same paper), you should remove the ‘SAS deployment name’ (Dev/Test/Prod) element from the SAS metadata group name, so that your ACTs contain groups with the same name in each SAS deployment in your ecosystem. If the corporate naming convention does not allow LDAP groups to be named in this manner, define the best names you are able to in the LDAP directory service, and create a lookup table and a step in your user and group synchronization program, to associate each dynamic group with its corresponding static group. That lookup table is then the reference defining which groups correspond to each other. Static groups in SAS metadata (i.e. groups which are NOT synchronized from an LDAP service provider) should have names which omit most of the elements above, concentrating on the part of the group name which indicates what its members do in this specific SAS deployment, e.g. DI Developers, VA Report Designers etc. One SAS deployment does not usually need to have objects in it whose names reference other SAS deployments, or even hint that other SAS deployments may exist. For example, it is not necessary for DI Developers in a Development environment to be labeled “Dev DI Developers”; “DI Developers” is better.   I hope you have found these Golden Rules, and the reasoning behind them helpful in any security models you design. Please do let me know if you have any other ideas for practices that should always be followed with security model design. And releases of products on SAS Viya which include the General Authorization system begin to roll out, we will start seeing some real-world lessons learned for security model design in SAS Viya. Please do let me know of you see any interesting new trends emerging, that we can share with the wider community. Until next time, thanks for reading! ... View more

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! ... View more

Continuing our series on Golden Rules for Metadata Security Model Design, this time we'll look at Rule 4. It describes how to deny a group of users some permissions down inside a folder structure, without breaking Rule 3. Rule 4 itself is simple, but to understand it fully takes some explanation, so this is the longest post in the series. And we also review Rule 5, which ensures you don't remove Administrator access to metadata when you deny it to everyone else. If you missed the first two posts in this series, you should read part 1 and part 2 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 4: Where necessary, apply ACTs to deny access to PUBLIC/SASUSERS, in combination with ACTs to grant a reduced set of permissions to explicit groups   Detail This rule covers situations where you need to reduce or remove the access one or more groups have to a metadata object (such as a folder) and its children. Only design permissions for a folder like this when no sensible alternative exists for designing the folder structure a different way. If possible, redesign the folder structure to move a more restricted folder somewhere else so that it is not beneath a more widely-open folder. If that is not possible or would result in a confusing folder structure, it may be necessary to apply ACTs to deny broad access, and re-grant more limited access as follows. To reduce or remove access to an object for the groups which would otherwise inherit broader access than you want them to have, apply: The PUBLIC and SASUSERS Denied ACT The SAS Administrators ACT, Select other ACTs to grant permissions for select other groups The first of these is not part of the standard set of ACTs created when you first deploy SAS Metadata Server. To see its design, look at Table 1 – GEL Recommended ‘Core’ Access Control Templates to include in any security model design, in section 8.2 of the Core Artefacts paper attached to this article, for the detailed design of the first two of these ACTs. See also Rule 5 below for more on the SAS Administrators ACT and why you should apply it alongside the PUBLIC and SASUSERS Denied ACT. If the existing ACTs featuring these groups are too permissive, create a new ACTs which grant only the permissions you want, and apply those new ACTs to the object. Rule 4 does not conflict with Rule 3, because Rule 3 prohibits denying permissions to members of an explicit group, but in Rule 4 we apply ACTs which deny access to implicit groups only. All users (whether authenticated or not) are members of the implicit group PUBLIC. Authenticated users are also members of the implicit group SASUSERS, and probably belong to at least one explicit group (i.e. any group other than SASUSERS or PUBLIC). Explanation This rule defines how you should restrict access to metadata objects in your folder or object hierarchy. It allows you to grant access to a more limited group or set of groups, and ‘hide’ the metadata object and its child objects from all other groups. To explain this rule, let’s consider a permission such as ReadMetadata (RM), granted or denied for an object such as a metadata folder. The rule applies in exactly the same way to any permission on any object, but we will use this example because it is simple and easy to follow. In this example, suppose that two groups, group A and group B, have inherited (grey) a grant of RM on the folder, but we only wish group A to have RM, and we want RM to be denied for group B. In this example, there is a Group A ACT which grants RM (among other permissions) to Group A. There is also a Group B ACT which grants RM (among other permissions) to Group B. Figure 1 – A folder intended for Group A only is beneath a parent folder that is accessible (i.e. it has Read Metadata permission granted) to Group B as well as to Group A But we do not wish Group B to have Read Metadata permission on ‘folder for Group A only’. The simplest way to prevent Group B from reading the content of that folder would be to explicitly deny Group B Read Metadata on that folder. But doing that would break two of our golden rules: Rule 1: Only use ACTs, never ACEs Rule 3: ACTs only grant access to explicit groups, never deny So, we will solve this problem using an ACT. And we won’t create or use an ACT which denies Read Metadata (or any other permission) to Group B. The correct way to meet to our requirement to effectively deny Group B access to the ‘folder for Group A only’ involves a PUBLIC and SASUSERS Denied ACT and a SAS Administrators ACT, both defined as shown in the paper Recommended SAS® 9.4 Security Model Design: Core Artefacts, in section 8.2 Recommended Core Access Control Templates. The figure below only shows the Read Metadata grants in these ACTs, to avoid the figure becoming unnecessarily complicated. Many other permissions besides Read Metadata are set in the complete definitions of these two ACTs.   Figure 2 – Partial representations of a PUBLIC and SASUSERS Denied ACT, and a SAS Administrator Settings ACT, showing only the Read Metadata permissions they deny and grant. You should also apply the SAS Administrator Settings ACT wherever you apply the PUBLIC and SASUSERS Denied ACT. Rule 1 says we must not explicitly apply an ACE on this folder to deny RM for group B. Rule 3 says we must not deny RM to group B in an ACT, and apply that ACT to the folder. Instead, to remove the inherited RM permission for group B, leaving it intact for group A, we apply: The PUBLIC and SASUSERS Denied ACT. This, on its own, denies ALL permissions for ALL users. Hint: do not apply this on its own! If you do, only an Unrestricted User will be able to see the object and its children! The SAS Administrators ACT. This grants back the necessary minimum permissions SAS Administrators should have on all objects, and grants RM to SAS System Services which requires RM on every object. Note: There is a now conflict between the PUBLIC and SASUSERS Denied ACT above which denies RM (and all other permissions) to SAS Administrators, and this ACT which grants RM (and other permissions) to SAS Administrators. However, the conflict is safely resolved in favor of the grants from this ACT, because they are for an explicit group (SAS Administrators), and the denies are for implicit groups (SASUSERS and PUBLIC). The explicit SAS Administrators group is closer to the user in his or her identity hierarchy than the implicit groups, and all else being equal (permissions from two ACTs applied directly to the same folder), the permission for the closest group to the user in the identity hierarchy wins. The identity hierarchy is discussed in the SAS 9.4 Security Administration guide. The Group A ACT which grants RM (among other permissions) to Group A. Again, the conflict between the grant in this ACT and the deny in the PUBLIC and SASUSERS Denied ACT is resolved in favor of the grant in this ACT, because an explicit group (Group A) is closer to the user in his identity hierarchy than an implicit group (SASUSERS or PUBLIC).    Figure 3 – In this illustration, three more ACTs (highlighted in orange) have been applied to ‘folder for Group A only’, with the result that Group A still has access to that folder, Group B does not, and none of the golden rules of security model design have been broken. This leaves the folder accessible by SAS Administrators, SAS System Services and Group A as intended, but inaccessible (RM is denied) for members of Group B, as intended. Of course, in this simplified example, in addition to the PUBLIC and SASUSERS Denied ACT and the SAS Administrators ACT which effectively set the permissions on a folder back to a minimum, we only added the Group A ACT back to ‘re-grant’ access to the folder to that group. In real customer SAS deployments, there may be more than one group which needs to be ‘re-granted’ access when you ‘start again’ by applying the PUBLIC and SASUSERS Denied ACT and the SAS Administrators ACT. You may have to apply several additional ACTs to the same folder to restore the desired permissions. As you can see, the logic for determining effective permissions on an object for a user is somewhat complex. Follow rule 4 to avoid having to resolve the complex inheritance and precedence logic in your head (and to avoid SAS having to resolve that same logic in metadata) in order to determine who wins in the event of conflicting grant and deny permissions effective on an object for a particular user! Rule 4 allows you to deny access to a folder, without breaking rules 1 and 3, and while keeping the logic simple and easy to follow.   Rule 5: Always Apply the SAS Administrators ACT when PUBLIC and SASUSERS are denied access   Detail Apply this rule in conjunction with Rule 4. Always apply both the SAS Administrators ACT and the PUBLIC and SASUSERS Denied ACT together.   Explanation While Unrestricted Users are not subject to metadata permissions, all other users including members of the SAS Administrators group are. If you deny access to an object and its children to PUBLIC and SASUSERS, there is no magic rule built in to SAS which grants access back to SAS Administrators. You must do it yourself: always apply both the SAS Administrators ACT and the PUBLIC and SASUSERS Denied ACT together. This is illustrated in the figures for Rule 4 above.   The series continues next time, in a (mercifully) shorter post, when we look at Rule 6. I hope you'll come back for that one. ... View more

This time, we'll look at the most important Golden Rule for Metadata Security Model Design. If you missed the first post in this series which covers the first two Golden Rules, you may wish to read that before this one. The first six of these eight Golden Rules closely follow those developed by Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, in their paper ‘Metadata Security in SAS® 9.4 – Step-by-Step’. I have included their work 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. There are eight rules, and this time we'll cover the first two. Rule 3: ACTs only grant access to explicit groups, never deny   This is the most important rule of all   Detail It is absolutely strictly forbidden for an ACT to deny any permission to any group except PUBLIC or SASUSERS. You may deny (or grant) any permission to PUBLIC or SASUSERS in an ACT without breaking this rule.   Explanation Following this rule guarantees that your security model cannot suffer from permission conflicts. Avoiding permission conflicts is a good thing. A permission conflict occurs when two or more access controls with conflicting settings (at least one grant and at least one deny), for an effective permission such as read metadata, apply to the same object for a particular user. The word effective is important – permission conflicts can and frequently do occur as a result of permissions inheritance through a group hierarchy, or through an object hierarchy. Permissions conflicts usually occurs when: A user is a member of two or more groups, at least one of which effectively grants the user a permission on an object, and at least one other of which effectively denies them that permission on that object. The user may be in more than two groups, so there can be more than one conflicting grant and/or deny for the same permission. The groups may be organized in a hierarchical structure and conflicting effective permissions can originate from any of the groups in that hierarchy. The object for which the permission is being evaluated is in a hierarchical structure, and inherits permissions from one or more parent objects (e.g. folders). Two or more ACTs are applied to the object itself, or to any parent of the object, one granting the user or a group to which the user belongs the permission and one denying it. Permissions conflicts can occur in other ways too: follow this rule to avoid them all. SAS has a very fast and robust permissions resolution engine, that determines if the grant or deny ‘wins’ according to a clear, well-documented but necessarily complex set of rules, which cover all possible precedence and inheritance situations including all the situations described in the paragraph above. But that complexity is a big problem which you must seek to avoid. When there is a permission conflict, to figure out whether SAS will grant a permission on an object for a user or deny it, you must know about and consider each grant or deny of that permission which could affect the object in question, and determine which of them takes precedence. You have to consider the group hierarchy, which allows membership of multiple groups directly, and multiple inheritance paths from multiple parent groups. You have to consider the entire object hierarchy. Then, you must consider that ACEs take precedence over ACTs, which take precedence over permissions inherited from parent objects. ACTs and ACEs can be applied for multiple groups of which the user is a member. The rules SAS follows to determine how the conflicting permissions should be resolved are clearly defined, but are complex, and can be exceptionally difficult for an administrator to follow. Few experienced SAS administrators understand the rules well enough to correctly predict whether the grant or deny will ‘win’ in even simple scenarios. If you follow Rule 3 (“ACTs featuring explicit groups (not PUBLIC or SASUSERS) may only grant access, never deny”), it does not matter whether a user is a member of one group or many groups. The effective permissions that user has on an object are much easier to understand. Simply look up the object hierarchy to determine the level nearest to the object at which PUBLIC and/or SASUSERS are denied a permission. The user’s permissions are the sum of any permissions granted by other ACTs at that level of the hierarchy or below. This rule is also one of the more difficult to comply with. It can be very tempting to check a deny checkbox in an ACT or worse, in breach of Rule 1 check a deny checkbox in the Authorization tab of an object or folder, to compensate for a group having unwanted access to a specific resource. But if you break this rule, you will sooner or later cause yourself, your colleagues or your successors a real headache.   If you need to deny a group permissions some levels down inside a folder structure, start again. Rule 4, which we will look at next time, explains how to do this without breaking Rule 3. We will also cover Rule 5, which ensures you don't remove Administrator access to metadata when you deny it to everyone else. See you then! ... View more

Over my next few blog posts, I would like to propose a set of Golden Rules for Metadata Security Model Design. These rules are fundamental to an overall SAS Global Enablement and Learning (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. There are eight rules, and this time we'll cover the first two. The first six golden rules closely follow golden rules developed by Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, in their paper 'Metadata Security in SAS® 9.4 – Step-by-Step'. Some of the words in this blog post are taken directly from their paper - they are so well written I cannot improve on their explanation. I have however added or expanded the explanations for most of the rules I will describe in this series.   These golden rules are the core principles of GEL’s metadata security best practices. These golden rules still allow you a great deal of freedom and creativity in designing your security model. Some rules make obvious sense. The value of other rules may appear debatable outside the context of the GEL Recommended SAS 9.4 Security Model Design series of papers. But in that context, they make good sense, and I will refer to supporting material where relevant. There are two simple pre-requisites for understanding these rules properly: You need an understanding of SAS metadata security, especially how permissions are inherited You must know what the white, green and grey background colors mean in the Authorization tab in SAS Management Console   Rule 1: Only use ACTs, never ACEs   Detail Secure resources using a combination of inheritance (tick marks with grey background) and Access Control Templates (ACTs, tick marks with green background). In our recommended approach to metadata security design, it is absolutely strictly forbidden for you to use Access Control Entries (ACEs, tick marks with white background on resources).         Explanation If you only apply ACTs and not ACEs, your job as an administrator will be easier because you can maintain all security changes centrally in the Authorization Manager Plugin of SAS Management Console.   Permitted exceptions When SAS is deployed, some ACEs are already applied to certain objects by the SAS deployment wizard. Do not change these. The security design behind row level security on information maps and cubes forces you to apply ACEs. No other exceptions are permitted.   Rule 2: Only add groups to ACTs   Detail Add groups to ACTs. Do not add users to ACTs. We suggest you add only one group to each ACT and include the group name in the ACT name. Take adequate precautions if you have groups which are synchronized from an external LDAP provider.   Explanation  It is much less effort to maintain your security model for groups rather than for individual users. If you only use groups in your ACTs, you can grant users the permissions they need by placing them in the appropriate groups. You can change a user’s permissions by changing the groups they belong to, far more easily than by removing that user from a number of ACTs (or worse, removing their ACEs if you can find them!) and then adding that user to new ACTs. Avoid adding groups which are automatically synchronized into SAS Metadata from an LDAP provider, using something like the User Import Macros, unless you have taken adequate precautions to ensure that those groups are unlikely to be deleted inadvertently. See my previous blog post 'Shadow Groups for LDAP Synchronisation' for a discussion of shadow groups and why you may wish to use them, or some other method to protect your security model from inadvertent deletion of synchronized groups. More next time, when I will present Rule 3, the most important rule of all.   You can find all the other posts in this series here: Part 2 Part 3 Part 4 Part 5 ... View more

SAS 9.4 comes with macros for synchronising users and groups from LDAP into metadata. When everything works, they are great. But if you schedule a user synchronisation job to run regularly in batch, and something goes wrong, it could make a real mess of your implemented security model. Let's look at what can go wrong, and three options for things you can implement to stay safe! The User Import Macros SAS provides a set of User Import Macros, with a sample program to call them. You can adapt the sample program, first to bulk load selected groups and users from Active Directory or another LDAP server into SAS Metadata Server. Then afterwards, you can create a scheduled batch job to regularly run the code, to synchronise your metadata users and groups from the LDAP service. Many SAS customers schedule such a job so that it runs nightly. See the SAS® 9.4 Intelligence Platform: Security Administration Guide, especially the Appendix on User Import Macros, at http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/p1ar98lajfgm4jn1wa1h6e19jjre.htm (or search the web for “SAS 9.4 User Import Macros”, and similar sections can be found for earlier versions of SAS 9). In this post, I will call the groups created by code which synchronises them in from LDAP dynamic groups, and the non-LDAP ones static groups, if I need to be clear which sort I mean. They're exactly the same type of metadata object, there's no difference at all; this is just a label to help us distinguish where they came from in the explanation which follows. Ok. So you created some dynamic groups, and they have users in them who originated in an LDAP directory service. Now that you have your users and groups in metadata, you can start using those groups in ACTs, and assign those ACTs to folders and other objects, right?   Well, no, I would not advise you do that, unless you take steps to protect the batch synchronisation process from potential problems. What could possibly go wrong? Several things, but it all comes down to the dynamic groups and using them in ACTs. While you are developing and debugging your SAS code to synchronise users from an LDAP provider (such as Active Directory) into SAS Metadata, and even after that code is in production and has been working well for some time, it is possible that something may go wrong with the LDAP->Metadata syncronization. For example: A network issue, changed password or LDAP outage could result in the query your SAS program runs against the LDAP provider returning no groups. A well-meaning administrator may delete or rename your SAS groups in Active Directory without telling the SAS administrator who maintains the syncronization code first. If the sync code decides that your groups have been deleted, and you don't build in some protection against this risk, the group deletion will be propagated through to SAS Metadata, deleting some or all of your dynamic groups (and users) in SAS metadata.   If you delete a group, the metadata server also removes that group from any ACTs in which it featured. Now all the ACTs which featured those groups, no longer do, and may even have nothing in them. As a result, your SAS users (including interactive and batch/service users) will most likely lose access the metadata they need to do their work, and your SAS applications and services will stop working. Oops, I'll just fix that! Oh... You can fix the issue (or get someone else to fix it), and then re-run the synchronisation to create the groups again. But doing this won't add the new, replacement groups to all your existing ACTs. Those aren't the old groups. They are new ones of the same name. How well did you record the design of the ACTs? Is that record up to date? It's certainly an interesting way to resign. You had better go get a box for your stuff. When we've heard about this happening at real customer sites, the first that the SAS administrator knows about the problem is usually that users cannot log in, or that they have lost access to pretty much everything in metadata. When the SAS Administrator opens SAS Management Console to investigate, his or her first indication that something is wrong is that the dynamic groups are no longer there. But by the time this happens to you, the damage to those ACTs has already been done. The groups they used to contain have disappeared. Even if you re-create the groups, they have to be laboriously added back in to the ACTs, and the appropriate grants and denies have to be set (by hand or by a script if you have one), or a metadata backup has to be restored to recover them, losing work done in SAS metadata since the backup was taken. Whatever you do, don't delete the damaged ACTs, and attempt to re-create them. That would make the problem even worse! When you delete an ACT, you remove it from any objects it was applied to. Re-creating the ACT does not re-apply it to those objects. How well did you document the current state of which ACTs were applied to which objects?! And is that documentation up to date? Never mind your box of personal stuff, we'll send it to you. If you are in this unfortunate position, your best remaining options are to either: restore a metadata backup and lose whatever other changes were made since the backup was taken, or re-promote the ACTs from another environment in the same ecosystem (e.g. from Test or Staging back into Prod) if they were originally promoted in from that other environment, or add the groups and their grants back into the existing ACTs by whatever means you can - manually, or by running a script. None of these is a very simple or painless solution. So, prevention of this problem is going to be better than a cure. What are your options? Option 1: The Metacoda Identity Sync Plug-Ins Metacoda Pty Ltd in Australia sell a set of Metacoda Security Plug-ins for SAS Management Console, which can help a SAS administrator with many tasks relating to metadata security. Personally, I think they are good value, and for the avoidance of doubt I have no vested interest in the company. Since version 5.0, they have included an Identity Sync Plug-In, which can “import, check and synchronize identity-related SAS metadata with enterprise directories without the need to edit SAS code”. It has a graphical user interface, and the ability to "check" what would change before you commit the change to metadata is the big benefit here, if you are running your synchronisation of users and groups interactively. At the time of writing, The Metacoda Identity Sync Plug-In interfaces with Active Directory, but not with other LDAP services. It also uses SAS’s User Import Macros behind the scenes, so it updates metadata via a supported method. You can read more about it at, www.metacoda.com.   Option 2: Shadow Groups Another good solution to this problem is to set up something called shadow groups, and use those in your ACTs instead. Again the term 'shadow groups' is just a label. They are normal, static metadata groups. Create them in a 1:1 relationship with your dynamic groups, make each dynamic group a member of its corresponding shadow group, and use the shadow group in your ACTs. I'm sure you can picture the arrangement if you set your groups up like that. Here's how things would stand if you then lost your dynamic groups:  Your users have still lost access to the system, so you still have an outage in this situation. But once you fix the issue that caused the loss of the dynamic groups, and re-run the synchronisation job to re-create the users and groups who were lost, it's much easier to make each dynamic group a member of its corresponding shadow group again. Once you've done that, users have the correct permissions again. Option 3: Sanity checks in the synchronization code Another good solution is to introduce some logic into the LDAP user and group synchronization code, which can recognise when there are a lot of groups being added or deleted, and will stop and alert a SAS Administrator to the high volume of additions or deletions. For example, if more than 10% of your existing groups are being deleted, or certain named groups you know should never be deleted are in the 'groups to delete' dataset in the synchronisation program, have the program alert the SAS Administrator and stop. The SAS administrator can then investigate, and may decide to run the synchonization code interactively, to force the mass creation or deletion of users and groups if that is what is supposed to happen. But if there is a problem, he has time to figure out the root cause and fix it, and no harm was done to the existing users and groups.   Conclusion The options are not mutually exclusive - you could use all of them. For a larger site with more users (and a bigger budget), I think Option 1 is a strong choice. For a smaller site, or one where there is no realistic chance of buying a third-party tool to help with user synchronisation (and other security-related administration tasks!), a combination of both Option 2 and Option 3 is ideal. ... View more

SAS Studio 4.1 for SAS Viya® 3.1 has many configuration settings you can adjust. Some of them can be set in more than one place. In this article, we'll see how to change the root directory users see under the Files folder tree, and do it in such a way that your change is not lost when your Viya deployment and SAS Studio are updated. SAS Studio 4.1 has a default configuration properties file at /opt/sas/viya/home/SASStudio/war/config/config.properties.  In a multi-machine deployment, you'll find this on the Viya host, the one serving SAS Studio, which was in the [sas-viya] host group during deployment. The picture below shows part of this file, in MobaXterm's build-in text editor:  The webdms.customPathRoot property highlighted in the screenshot above sets the root folder users see when they expand Server Files and Folders > Files (/) in SAS Studio. With no value set for this property, SAS Studio maps the Files root to the filesystem root folder on the Viya server:     With a value set for this property (important: read on before you change it, though!), you can have the Files folder start at another folder in the filesystem, instead of root. Why might you want to do this? As an administrator, think about what you must do to: Create and secure filesystem directories for users’ work Backup and restore users’ work Manage disk space Migrate to newer versions of SAS Promote between environments (Dev -> Test -> Prod) Each of these tasks is easier if user content is in known filesystem location(s). Administrators should constrain their users to allow them to put their content only in those location(s), by configuring SAS Studio, and also through a well-designed filesystem security model. But you should NOT edit the config.properties file mentioned above to change this setting - or any of the other settings in it. If you did, the next time an administrator runs yum update, either directly or by re-running the SAS Viya deployment playbook, this file is liable to be overwritten with a new default version, and any custom changes you made would be lost. Instead, to override the value for any of SAS Studio's configuration properties, you should do one of the following three things: Add a line to the vars.yml file in your sas_viya_playbook directory, like the line in bold below, and then re-run your ansible deployment playbook so that ansible makes sure your Viya deployment is in the new desired state:   When you have added the line above to vars.yml, and re-run the ansible deployment playbook, you will see a new line in /opt/sas/viya/config/etc/sasstudio/default/init_usermods.properties, like this:  When the SAS Studio service starts up, it reads the config.properties file described above first, then this init_deployment.properties file, and then init_usermods.properties in the same directory. So, because they are read in that sequence, the order of precedence between these files is effectively: init_usermods.properties (read last, so always wins)  > init_deployment.properties (read second-last) > config.properties (in the home directory structure, read before the other two, values set can be overridden in either of the other two) Values specified in vars.yml would be re-configured in the init_deployment.properties file even if you undeployed and redeployed your Viya software.  Manually add a line to the file /opt/sas/viya/config/etc/sasstudio/default/init_usermods.properties, like this: webdms.customPathRoot=/demo Here's what the modified copy of the init_usermods.properties file could look like:   Restart SAS Studio on the Viya server to make it read its changed configuration properties, e.g.: [user@viya-host ~] sudo service sas-viya-sasstudio-default restart  Changes made to the init_usermods.properties file are preserved unless you completely uninstall and reinstall your SAS Viya deployment. They override changes made in the init_deployment.properties file in the same directory. Add an additional task (or role) to your SAS Viya deployment playbook, which modifies the custom init_usermods.properties file as described above. This is considerably more effort, but would apply a configuration change which survives both updating SAS Viya, and uninstalling and reinstalling, and even deploying again (with the your modified playbook or a new playbook modified similarly) on another environment. For such a simple change which can easily be made by modifying vars.yml, there is little point going to all this trouble. But, if you wanted to make more significant post-deployment configuration changes to your SAS Viya deployment, you may choose to include this along with all the others in a custom ansible role, so that you could manage the ansible tasks which make all your custom configuration changes together, in the same place.     However you make your configuration change to the webdms.customPathRoot configuration setting, here is what the Files structure in SAS Studio should now look like, when it has restarted: Now, SAS Studio users cannot so easily save files anywhere else on the filesystem, through the visual interface. Making this configuration change does not otherwise prevent users from saving files elsewhere using program statements, which is why managing end user's permissions at the filesystem level is also important.   ... View more

About these papers: This is a series of five papers which together present a set of recommended practices for security model design in SAS 9.4.   In part 1 of 2, you can find the overview and the main core principles and practices paper. In this part 2 of 2, you will find papers on core artefacts, and artefacts for deployments which include SAS Data Integration Studio or SAS Visual Analytics.   About the author: David Stern is a Principal Technical Architect in SAS’s Global Enablement and Learning (GEL) team. He focuses on platform administration, especially security model design, and promotion and migration between SAS deployments.   About the GEL Recommended SAS 9.4 Security Model Design series of papers: This and the other papers in the series are a collection of principles and practical design recommendations which were developed over several years. Considerable portions of content were developed by SAS consultants in Denmark and the wider Nordic region, with contributions from the UK, Australia, the US and Germany. These papers have been widely reviewed and distributed within SAS, and we are delighted to share them with our community of users.   Note added on 26 July 2023: In several places, these papers refer to the GEL Turbo (or to give its full name, the 'SAS Global Enablement and Learning metadata security turbo-charge scripts'). For example in the 'Core Principles and Practices' paper, the Turbo is discussed in section '3.5 Consider using the GEL Turbo'. The URL for the Turbo points to an internal-only SAS URL, and one or two readers outside SAS have asked where they can get the Turbo scripts and assets. We have not released the GEL Turbo to the general public, and have no plans to do so. I should have made that clearer wherever we refer to the Turbo tools, and especially in section '1.4 Intended Audience' of the 'Core Principles and Practices' paper, where I wrote 'Some of the documents and pages referenced within this series of papers are held on SAS internal systems (such as ToolPool), and will not be accessible to readers outside SAS.' The GEL Turbo is one such 'document' but in hindsight I should have called out the GEL Turbo in that paragraph specifically as something not accessible to readers outside SAS, as it is referenced and advocated in several places throughout the rest of the series of papers. If you are working with a SAS consultant (one who works for SAS) on your SAS 9 environment, you could discuss it with them and see what they think. ... View more

About these papers: This is a series of five papers which together present a set of recommended practices for security model design in SAS 9.4.   In this part 1 of 2, you can find the overview and the main core principles and practices paper. In part 2 of 2, you will find papers on core artefacts, and artefacts for deployments which include SAS Data Integration Studio and SAS Visual Analytics.   The central core principles and practices paper describes concepts which are fundamental to good security model design, such as: What a security model is How to plan your security model design work The Golden Rules of security model design How to design your security model Testing your security model Security and SAS Environment Manager Maintaining your security model Additional considerations The other papers in the series provide a brief overview, and describe artefacts that should be included in a SAS 9.4 implementation which includes SAS Data Integration Studio or SAS Visual Analytics.   About the author: David Stern is a Principal Technical Architect in SAS’s Global Enablement and Learning (GEL) team. He focuses on platform administration, especially security model design, and promotion and migration between SAS deployments.   About the GEL Recommended SAS 9.4 Security Model Design series of papers: This and the other papers in the series are a collection of principles and practical design recommendations which were developed over several years. Considerable portions of content were developed by SAS consultants in Denmark and the wider Nordic region, with contributions from the UK, Australia, the US and Germany. These papers have been widely reviewed and distributed within SAS, and we are delighted to share them with our community of users.   Note added on 26 July 2023: In several places, these papers refer to the GEL Turbo (or to give its full name, the 'SAS Global Enablement and Learning metadata security turbo-charge scripts'). For example in the 'Core Principles and Practices' paper, the Turbo is discussed in section '3.5 Consider using the GEL Turbo'. The URL for the Turbo points to an internal-only SAS URL, and one or two readers outside SAS have asked where they can get the Turbo scripts and assets. We have not released the GEL Turbo to the general public, and have no plans to do so. I should have made that clearer wherever we refer to the Turbo tools, and especially in section '1.4 Intended Audience' of the 'Core Principles and Practices' paper, where I wrote 'Some of the documents and pages referenced within this series of papers are held on SAS internal systems (such as ToolPool), and will not be accessible to readers outside SAS.' The GEL Turbo is one such 'document' but in hindsight I should have called out the GEL Turbo in that paragraph specifically as something not accessible to readers outside SAS, as it is referenced and advocated in several places throughout the rest of the series of papers. If you are working with a SAS consultant (one who works for SAS) on your SAS 9 environment, you could discuss it with them and see what they think. ... View more

Have you ever wanted a sample list of the tasks you should consider performing as a SAS Platform Administrator? This Checklist of SAS® Platform Administration Tasks for SAS 9 (and it's equivalent for SAS Viya) was produced as the result of extensive collaboration with many experienced consultants in SAS UK, EMEA and North America. It contains two checklists. The first lists one-time tasks that you should consider performing when you first deploy your SAS software. The second describes tasks you should consider scheduling as a regular, recurring activity to keep your environment running in good condition. Take a look, and I'd love to know what you think about it! ... View more