While researching and testing the default Web Report Studio metadata security I noticed this little trick for young players, which means changes to WRS/WRV Metadata Security for a user are not instantly applied/recognised in WRS/WRV.
Words from the SAS tech support note “Changes to SAS® Web Report Studio role memberships might not immediately be enforced“:
“SAS Web Report Studio analyzes role memberships every 30 minutes. So, for example, if you move a user from the WRS Report Author role to the WRS Report Consumer role, the user will continue to have author privileges until the next time that he logs in after the next role membership analysis is performed. ”
So effectively the WRS/WRV applications are caching the Metadata security to remove the need for the web server to query the Metadata Server each time a user logins.
So try not to be fast when testing your WRS Metadata security changes, else you will think you have done something wrong. And remember to logout and log back in after the cache has been updated.
You can update the LocalProperties.xml file to change the refresh time, and therefore make the changes appear sooner. Details on how to do this are in the SAS Tech Support note.
Researching definitions for each of the WRS default roles as part of the Advanced Metadata Security course.
The roles are documented in the SAS 9.1.3 Intelligence Platform: Web Application Administration Guide, Second Edition on page 130. What it says is:
“By default, everyone who can log on to SAS Web Report Studio can view, edit, and create new reports.
To implement security, each user of SAS Web Report Studio can be assigned to one or more standard roles. A user’s role assignments determine which SAS Web Report Studio menu items are available to that user.
-
By default, all SAS Web Report Studio users implicitly have the role. However, if you explicitly assign any members to the role, then only the explicitly-assigned members will have the role. This enables you to start using SAS Web Report Studio immediately after installation, yet still have the ability to restrict user access when locking down your deployment.
-
Each role is a superset of the preceding role. For example, members of the “WRS Report Author” role have all the permissions that apply to the “WRS Report Consumer”.
-
Once you explicitly assign members to a role, you must explicitly assign membersto each superset role. For example, if you assign members to the “WRS ReportAuthor” role, then all of the subsequent superset roles (in this example, “WRSAdvanced User”) also become explicitly-assigned roles. The reason is that WRSAdvanced User is a superset of WRS Report Author.
-
Once you explicitly assign members to a role, then any user who is not assigned to a role, or who has no metadata identity, can only view reports and manipulate reports (for example, select new data items to view in report objects).
| WRS Report Consumer |
Users who have this role can view reports and manipulate report data in the View Report view. Users can copy, move, save, rename, or delete reports. Users cannot create new reports with the report builder or report wizard.
|
| WRS Report Author * |
In addition to the abilities assigned to WRS Report Consumers, users who have this role can create reports with the report builder or report wizard. Users can also schedule reports.
|
| WRS Advanced User |
In addition to the abilities assigned to WRS Report Authors, users who have this role can distribute reports. Users cannot create or delete recipient lists that are used for report distribution.
|
| WRS Administrator |
Users who have this role can perform all tasks that are associated with SAS Web Report Studio, including the ability to create and delete recipient lists that are used for report distribution.
This role provides full permissions to SAS Web Report Studio and should be safeguarded accordingly. This role provides application level administrator functionality. However, this role has no effect on metadata access (authorization) rights to report data.
|
| WRS Prohibited |
Users who have this role cannot log on to SAS Web Report Studio. Regardless of the user’s membership in any of the previous roles, if the user attempts to log on, the logon page displays the following error message: “This user is not allowed to access SAS Web Report Studio. Please contact your administrator.”
Some organizations might apply this role for users who are allowed to access some SAS applications but not SAS Web Report Studio. Alternatively, if an organization has multiple Web Report Studio installations, this role can be used to restrict some users from specific instances.
The corresponding metadata group entity is not created during installation. You must manually create the group in metadata if you want to use this user role.
|
*By default, WRS Report Authors can schedule reports, though you can change the default behavior and limit the scheduling feature to WRS Advanced Users. To do this, in your LocalProperties.xml file, specify true for the schedulingRequiresAdvancedUserRole property.
|
If you ever need to deploy WRS to the Web Server after an install (or wondered how SAS did it for you) there is a great SAS Support Tech Note that explains the process.
It covers deploying to Web Logic, Websphere and Tomcat.
Find it on the SAS Support site here:
Configuring and Deploying SAS® Web Report Studio
So looking for some help from the SAS community.
On a project we have focused on delivering content via Web Report Studio and Infomaps.
We now want to allow users to access the content via Office Addin and Enterprise Guide.
But (there is always a butt 
we only want users to access data via Information Map, we don’t want them to access the base libnames or tables.
Why you ask, because we have all the business rules embedded in the Information Maps so we don’t want users bypassing these and defining there own business rules on the base data.
Of course if we deny access to the libname then the Infomaps will fail. We can’t restrict access to all data types (i.e tables) in AMO or EG.
So any ideas out there?
Things we are going to try:
- Implement workspace server pooling (grant access to tables trusted user, but not actual use)
- Create a workspace server for WRS reports with full rights inherited and a workspace server for AMO/EG users with linbame rights restricted
But we are pretty sure that neither of these will work.
As the title says, Help!
If you want to change the default number of rows in a WRS table from 40 to something else, this SAS support note will tell you how:
Changing the default number of rows displayed and scrolled in a table in a Web Report Studio report
The current release of SAS Web report Studio (3.1/SAS 9.1) doesn’t allow you to define cascading prompts, by this I mean allowing a user to select a country and then based on the country selected allow them to select a state within that country.
However in a paper presented at SAS Forum 2008 titled SAS Web Report Studio Tips and Techniques (Paper 064-2008 ) there is an innovative way outlined on how you can provide this capability by using linked reports.
The approach they have worked out is to create a report for each level of prompt and link the reports, enabling the user to select the appropriate value on each report (i.e first report they click on country from a list, then second report shows states etc) and then be linked to the next report where they can select the next parameter value, and so on and so on.
Great thinking outside the box!
If you are aiming to deliver self service report creation to end users, then no doubt you are deploying SAS Web Report Studio to enable them to create and manage reports.
If you have SAS Portal installed it is possible to provide single-signon between WRS and Portal.
In the Portal you create a new Application link and use:
http://webserver:port/SASWebReportStudio/logonFromPortal.do
Once the user has added this to their collection portlet, they can click on it and it will bypass the Web Report Studio login screen, automatically using their authenticated login details.