Skip to main content

How SAS application gets connected to Metadata Server?

You have already learned that SAS applications connect to Metadata Server. Here you can get to know about how actually this happens. As a user we know that we give our credentials and then boom we get connected. But admin should be aware how it happens behind the scene, so that he/she can diagonise in case of connectivity issue.

Connection to SAS Metadata Server


The above diagram shows the flow of how SAS client applications connect to Metadata Server. I will describe each step below.

1. Say, you are now login to SAS Management Console, you give user ID and the password. This happens in the first step.

2. The username and password is passed to Metadata Server. Metadata Server then passes it to Authentication Provider. The authentication provider may be the host machine or LDAP or Microsoft Active Directory. So the authentication is not done by Metadata Server. It just acts as a intermediate to SAS and authentication provider.
Note: SAS doesn't know about authentication provider. It every time passes the credentials to its host. If authentication provider such as LDAP or MS Active Directory is configured in host then authentication happens there, which is handled by OS.

3. Authentication provider checks whether the received username and password pair is correct. If it is correct then it will pass the username to Metadata Server, else authentication fails. Authentication provider won't send the password to Metadata Server.

4. With the received user id from Authentication provider, Metadata Server searches for that user id in Metadata Repository. The user id will be there if you (or admins) have added the user to metadata (using SAS Management Console). If the user id is present then he/she will be considered as sasuser or else he/she is  a PUBLIC user. This step is called inbound login.

5. ACT (access control template) of the userid is passed to Metadata Server. From ACT, Metadata server will determine what access does that user has. It first checks the repository ACT, you can find it with the name default ACT in SAS Management Console. If the user id has ReadMetadata and WriteMetadata permission then connection gets established. User id must have WriteMetadata permission to connect to Metadata Server.

6. Metadata server then sends a unique id to client application. The client application will then passes that unique id whenever it requires information from metadata. In SAS the unique is called as credential handle. Whenever Metadata Server receives credential handle, it understands that the user id is already authenticated.

I know that the authentication provider part is bit tricky. Because that part is not uniform in all environment. Each organization use their own form of authentication depending on user base. You will eventually learn how the authentication provider works in your environment. But make sure that you learn the difference between authentication and authorization. In this article, what happens in second step is authentication and the fourth step is authorization.

See the flow 4 to 5 times and make sure you understand the process that happens in each steps. Sure you will be able troubleshoot the issues related to connectivity.

Comments

Popular posts from this blog

Insufficient authorization to access PIPE error in SAS EG

Issue: When I tried to run SAS code in SAS Enterprise Guide it throws following errors: ERROR: Insufficient authorization to access PIPE. ERROR: Error in the FILENAME statement. Screenshot of error: Solution: This error occurs when you try to run OS commands in SAS code. To run the OS commands in SAS code you need to enable XCMD option. You check it in SAS Management Console by following below steps.   Open SMC -> Expand Servers -> Expand   In SASApp , expand Logical Workspace Server -> right click on Workspace Server. Click properties -> option tab -> advanced options -> launch properties. Check whether Allow XCMD is checked. The issue arises if the Allow XCMD is not checked. In above image, Allow XCMD option is not checked. It should be checked to run OS commands from SAS code. In Unix /Linux machines, this XCMD option can be enabled by using system option XCMD in sasv9 config file or workspaceserver.sh script f...

The authentication server is not SETUID ROOT error in SAS

Question: When validating the SAS Server from SAS Management Console, I received the following error: The authentication server is not SETUID ROOT.  So, I ran the setuid.sh utility and restarted the services many times. I just checked the elssrv sasauth sasperm setuid bit. There were no error in sasauth-debug.log, sasauth-access.log, sasauth-error.log.  Any suggestions? Answer: Please do the following:    1) Run /<SASConfig>/Lev<X>/ObjectSpawner/ObjectSpawner.sh stop  2) Edit /<SASConfig>/Lev<X>/ObjectSpawner/ObjectSpawner.sh and add the code shown below right after SCRIPT=`basename $0`:  if [ -n ""$TKPATH"" ]; then  unset TKPATH  fi   if [ -n ""$TK_PATHLIST"" ]; then  unset TK_PATHLIST  fi    3) Run /<SASConfig>/Lev<X>/ObjectSpawner/ObjectSpawner.sh start  The above code change in ObjectSpawner.sh should fix the issue.

SAS - CLI error trying to establish connection

Issue: User asked me to make a database connectivity to SQL Server. They provided following details SQL server hostname and ip address Database/DSN name Username Password I made entry in ODBC.ini file. You know, SQL Server entries were made in ODBC.ini and Oracle entries were made in TNS.ora file. Everything went fine, took back up of odbc.ini, made entry and saved the file. So to test this connection I ran the libname statement in SAS Enterprise Guide 6.1. It throwed following error. Error Message: My DB team showed that they are able to login   14 GOPTIONS ACCESSIBLE; 15 LIBNAME test ODBC DATASRC=SGE_DS SCHEMA=VST USER=sales PASSWORD=XXXXXXXXX; ERROR: CLI error trying to establish connection: [SAS/ACCESS to SQL Server][ODBC SQL Server Legacy Driver][SQL Server]Login failed for user 'sales'. Solution: First I suspected that Login failed for user 'sales' meant the password provided by DB team was wrong. They responded that they were able to login wi...