Setting Up SAS Application Server for iPhone

An application “server” in this context is essentially a SAS session waiting to receive requests from the user. Once a request is received, it would execute the specified SAS scripts and then deliver its output back to the user. One application server can serve many users at once. The server is able to do this when queuing up multiple requests and then executes it one at a time.

Each application server is assigned a set of SAS libraries to easily access predefined data and related programs.The SAS program that is requested by the user also resides on the server as defined to a library. This can be pre-assigned similar to how you can assign a LIBNAME or FILENAME in an AUTOEXEC file used during an execution of a SAS program. The assignment of these libraries is established when the application server is setup.
Each application server communicates to its corresponding iPhone application through its own assigned TCP Socket port. This ensures that there is no collision between multiple applications for optimal performance. If needed, it is optional to increase the number of ports to handle many requests. In this case, a separate SAS session is started on the server running simultaneously to enable greater bandwidth.

Secure Users
There are two distinct roles that users play to enable the delivery of SAS data and programs to the iPhone including an administrator and the iPhone user. The administrator is usually the SAS analyst or statistician that developed and manages the data and SAS program on the server. The iPhone user receives the reports and data onto their iPhone. Before a user can access SAS programs and data, the following steps are taken to ensure proper security.
Step 1 – Account Setup
An account is set up on the server with the proper credentials in order to identify and authorize the user. The key attributes needed to authenticate the user include a unique user ID and user defined password.
Step 2 – User Privileges
By default, the user only has access to a set of sample SAS macro programs and datasets that come with the system. In order to deliver real information, additional SAS macros and data need to be registered and have read and execute permissions granted.

.

The permissions model is rather simplified compared to an operating system since the only two types of privileges needed include “read” permission for SAS data and “execute” permissions for SAS macros. It is implied that if the user can execute a macro that they also have read permission to the macro and its related output.

Step 3 – Login and View
Once the administrator applies the correct permissions, the iPhone user can see the programs appear on their selection lists. They can then view the data in a viewer or execute the macro and view its results.

It is useful to have users access the data to which they have been granted access. The management of each program and data however adds administrative overhead. In this example, the effort is kept to a minimal so that both the administrator and iPhone user can get to the information that is needed efficiently.

Variable	Type	Label
Objid	Num	Object ID
libname	Char	Library Name
Items	Char	Items
Type	Char	Object Type
userinter	Char	User Interaction Name
datetime	Num	Date Time of User Interaction
privileges	Char	Privileges

All the user permission is handled on the server and stored centrally within a SAS dataset. Each dataset and SAS macro metadata is managed centrally on the server within a dataset with each object assigned a unique identifier. The dataset structure that stores this is shown here.
In this case the privileges variable stores a simply value “read” or “write”. This dataset and set of functions to manage privileges have been intentionally simplified for this specific purpose to optimally manage the access control list for the iPhone application.