Auditing user sessions in Viya 3.5 (update)
The event-driven architecture in SAS Viya 3.5 (and 3.4) offers the capability for effective auditing of system resources, report activity, data access, and more. In this post, we’ll revisit the options available for auditing user access and highlight important caveats and considerations. This revised version of an earlier article has been updated to account for some changes in the underlying processes to provide a clearer picture.
CAUTION: Important considerations
Before adopting the approach to auditing user sessions documented in this post, beware these important cautions about using the EV Datamart data captured by the SAS Operations Infrastructure for this purpose:
- The data is not originally intended as 'audit' and it does not contain data integrity and security features that true audit data should.
- The data is derived from different data sources in which information is recorded differently, and matching user sessions with this data can be imprecise.
- It is not suitable for real-time or near-real-time purposes due to (potentially significant) latency in data being written to disk.
- Matching session activity like logons and logoffs using the session ID may not always work as expected. While the session ID is generally unique, it is not guaranteed to be unique. There are a small number of situations and edge-cases where a given session ID might be reused.
- SAS Viya 3.5 versions released in December 2023 (and later) address an issue where the session signature was not recorded for a login event, resulting in errors with the AUTHENTICATIONS table data.
The information outlined in this post is a potential workaround for simplifying the process for auditing user session, but the caveats listed above must be noted as they present some potential challenges with this approach. Proceed with caution.
Information about logins and user sessions is captured by the Audit service in the AUDIT.security_audit tables in the SAS Infrastructure Data Server. The default behaviour, as defined in the security type properties in the sas.audit.record configuration instance, is to capture read failures only on security actions.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
When trying to audit user login attempts, the login event provides information about (successful and failed) login attempts coming from the SASLogon application.
Let’s look at an example. Below, we use the sas-admin CLI’s audit plugin to see that user Ahmed logged in at 07:31 AM on the 25th of October (note that the timestamp is in UTC in PostgreSQL, but is converted to local time when a SAS Operations Infrastructure ETL job loads it to the AUDIT table in CAS).
/opt/sas/viya/home/bin/sas-admin --output text audit list --user-id Ahmed --sort-by ~timeStamp
ID Time Stamp Action State User ID Application URI
c72c4533-886d-493b-9ef2-1dcff4ff4674 2019-10-25T07:57:54.776Z SessionDestroyed success Ahmed SASLogon
bb748c54-6cb3-4edf-adbe-fce516c5786c 2019-10-25T07:31:21.014Z update success Ahmed reportImages /reportImages/jobs/4d7a64d8-1839-4d5b-a562-b140cdfc1f22/state
caf1264d-4d37-444b-af45-4e339edc5dc6 2019-10-25T07:31:20.999Z create success Ahmed reportRenderer /reportRenderer/images
713e18ac-34db-4115-92aa-35f7662b0909 2019-10-25T07:31:20.649Z read success Ahmed reportData /reportData/commons/settings
c5df6523-eb4f-42fe-b89b-fbdcc73d1c56 2019-10-25T07:31:20.298Z create success Ahmed reportPackages /reportPackages/jobs/b7325111-3f5a-4659-84bf-d1e59bdfbc74
e8578d9f-73b1-4dea-a94e-048a9eb9a72d 2019-10-25T07:31:20.030Z create success Ahmed reportData /reportData/jobs/61c55ce8-2b0a-4989-a14f-e1a5395b3b86
5aec043f-c2f8-46b6-a758-bc040abf1f69 2019-10-25T07:31:17.990Z create success Ahmed reportData /reportData/metadataSupplements
fc7c64d8-bf75-40f5-a851-4afa5dc29beb 2019-10-25T07:31:16.141Z create success Ahmed reportImages /reportImages/jobs/4d7a64d8-1839-4d5b-a562-b140cdfc1f22
f9ad69f9-22b8-447b-82c2-45ebeb462409 2019-10-25T07:31:14.523Z read success Ahmed reportData /reportData/commons/settings
5dc96422-833c-496c-bd65-64659faf76d0 2019-10-25T07:31:08.641Z read failure Ahmed preferences /preferences/preferences/@currentUser/FormatLocale.DefaultLocale
5da5acf5-4d6b-47b3-9da5-c30ea7c3d946 2019-10-25T07:31:08.096Z read failure Ahmed preferences /preferences/preferences/@currentUser/_hc_xx_
4a4c470f-afe9-469c-af3a-3fdb6d5f951e 2019-10-25T07:31:07.082Z read failure Ahmed preferences /preferences/preferences/@currentUser/FormatLocale.DefaultLocale
b66f6eed-8ae8-47a3-8d3a-60e23df5cec9 2019-10-25T07:31:05.463Z login success Ahmed SASLogon
When a user logs off gracefully, a SessionDestroyed action is registered indicating the termination of the session as shown above.
If a user closes the browser instead of logging off, the SessionDestroyed does not get created in the audit records until the session times out. Session timeout duration is configurable.Set Time-out Interval for SAS Viya Web Applications in SAS® Viya® 3.5 Administration: Configuration ....
Some applications generate their own audit data when a user logs in. For example, SASStudio V creates a Compute server session when a user logs in, and an audit record similar to the following is captured.
/opt/sas/viya/home/bin/sas-admin audit list --user-id Ahmed --sort-by ~timeStamp --details --application compsrv
ID Time Stamp Type Action State Description User ID Application Remote Address URI
1967127d-87da-4656-922f-ed3b3bf1733d 2019-10-23T11:47:42.122Z resource start success 92ce6360-b23c-485b-94dc-48e5bd681bdd:https://intviya02.race.sas.com:38934/compute/servers/92ce6360-b23c-485b-94dc-48e5bd681bdd Ahmed compsrv
When the compute session is terminated, an audit record is captured indicating the deletion of the session (with the Description field indicating to the ID of the session).
/opt/sas/viya/home/bin/sas-admin audit list --user-id Ahmed --sort-by ~timeStamp --details --application compute
ID Time Stamp Type Action State Description User ID Application Remote Address URI
5ebd10ca-b4e1-4e7e-b71d-2874bfa672ca 2019-10-23T07:50:36.257Z resource delete success Deleted compute server 92ce6360-b23c-485b-94dc-48e5bd681bdd Ahmed compute /compute/servers/92ce6360-b23c-485b-94dc-48e5bd681bdd
c9a1fc4a-48ea-4afa-a456-45e890571e42 2019-10-23T07:50:36.132Z resource delete success Deleted compute server session 92ce6360-b23c-485b-94dc-48e5bd681bdd-ses0000 Ahmed compute /compute/sessions/92ce6360-b23c-485b-94dc-48e5bd681bdd-ses0000
User sessions are assigned a session signature when they are established. The session signature (session_sig) property links the login event with the corresponding SessionDestroyed event. However, there are some important considerations.
First, refer to the caveats listed at the beginning of this post about potential issues with relying on the session signature for this purpose.
Second, the session signature is not visible when surfacing audit records using the CLI. This information is recorded in TSV files in the EV Datamart directory (/opt/sas/viya/config/var/lib/evmsvrops/evdm/application/security) on the Viya server. When a session is started:
2 34dca2cc-fcc9-4b6d-8c72-32d2958c9320 security application/vnd.sas.event.security 2019-10-15T06:21:18.973000+00:00 sasadm sas-deployment-id:dml5YQ==,sas-event-source:U0FTTG9nb24=,session_sig:NTNlZmNlZGE= security action:bG9naW4=,actionState:U1VDQ0VTUw==
Note the session_sig value. When the session ends, another record will be generated in the same file, referring to the original signature (orig_session_sig) for that session.
2 b41e8882-192d-4657-8fee-4cb04a96abda security application/vnd.sas.event.security 2019-10-15T07:02:30.282000+00:00 sasadm orig_session_sig:NTNlZmNlZGE=,sas-deployment-id:dml5YQ==,sas-event-source:U0FTTG9nb24=,session_sig:NDk0MGZmNw== security action:U2Vzc2lvbkRlc3Ryb3llZA==,actionState:U1VDQ0VTUw==
Fortunately, the legwork for extracting this information has already been done. Session information is extrapolated from these files and stored in the authentications subject table (opt/sas/viya/config/var/lib/evmsvrops/evdm/subjects/authentications.sas7bdat). Information is captured in this table for metering purposes, a secondary effect is that it provides a really nice way (with the caveats listed above!) to audit user session information.
In the example below, several user sessions are listed, each with a datetime stamp of the login action, the session signature, and the duration of the session (in seconds).
Note that user Sasha’s session has a duration of 0.00 seconds. This points to an active user session (but there may be exceptions - listed above - due to latency), indicating that Sasha has not yet logged out (SessionDestroyed action has not occurred for the session with this signature).
A job runs every 5 minutes to update this table, and another job runs daily to clear records older than 10 days. Update: To change the number of days (e.g. from 10 to 14 days) for which to capture records, execute:
/opt/sas/viya/home/bin/ops-dm-admin set EMI_DELETE_TSVZIP_DAYS=14
We can query this table to get some more insights about user sessions. Can you use it to figure out who was logged in at a certain time, for example?
A basic SAS program can be submitted to help answer that question.
/* Specify query time below in datetime. format */
%let qrytime='15OCT19:08:39:18'dt;
libname evdm '/opt/sas/viya/config/var/lib/evmsvrops/evdm/subjects' access=readonly;
data activesessions;
set evdm.authentications;
endtime=datetime+duration;
format datetime datetime.;
format endtime datetime.;
where &qrytime between datetime and &endtime or (&qrytime >= datetime and (duration=0 and session_sig ne '');
run;
proc print data=activesessions; run;
Note that this code sample is for demonstration purposes only, and there may be more efficient or more accurate methods to extract the required user session information.
Thanks to my colleagues Greg Smith, Carl Sommer, Fred Forst and Mike Roda for their contributions to this and the original version of this article, and thank you for reading!
