Understanding Alternative Methods of Authentication

Overview

An enterprise computing environment usually contains a collection of business software solutions that are sold as a platform, applied across an organization, and further customized to specific areas. Platform services come with their own authentication processes and password management systems. When SPD Server is added to such an environment, it brings its own authentication process and password management system. This means that the administrator has to maintain two sets of user IDs: one for SPD Server and another for the platform services. In addition, disparate user ID and password management tools can have incongruous requirements. For example, SPD Server password lengths must be 6–8 characters. But the password length requirements for a given enterprise platform can range anywhere from 6 characters to 64 or more characters, allowing for stronger passwords.
One solution is to leave all SPD Server authentication to the enterprise platform. By integrating SPD Server user IDs and passwords with the framework of the platform's authenticator, the SPD Server administrator can maintain only one set of user IDs and passwords.
Configuring an alternative form of authentication involves adding appropriate options to the spdsserv.parm parameter file.

How SPD Server Performs Alternative Authentication

SPD Server performs alternative authentication in the following way:
  1. The SPD Server user issues a SASSPDS LIBNAME statement from SAS.
  2. The SPD Server client passes the request to the SPD Server host, including user name and password information provided in the body of the LIBNAME statement.
  3. SPD Server forwards the request to the alternative authenticator. The alternative authenticator (for example, LDAP or SAS Metadata Server) verifies whether the user account is in good standing. It also ensures that all authentication policies (such as a password expiration date) are in force.
  4. If the alternative authenticator finds the user account is in good standing, the SPD Server host is signaled. The SPD Server host then looks up the user in the SPD Server password database to apply attributes specific to SPD Server (such as access rights, groups, and group memberships) to the user’s permissions.
  5. Following authentication, SPD Server allows the user access and rights as indicated by the information contained in the password database.

Understanding LDAP Authentication

To use direct LDAP authentication, an LDAP server that performs LDAP authentication must be running on the SPD Server host. When you use this direct LDAP authentication, the operating system handles password maintenance. LDAP authentication has the added benefit of operating-system-level security and convenience.
On SPD Server startup, an LDAP configuration in the spdsserv.parm parameter file signals the SPD Server host to use LDAP authentication. SPD Server sends the LDAP server a DN (Distinguished Name), which consists of the user ID. LDAP begins the process of validation and setting access accordingly. LDAP authentication levels can range from anonymous authentication, which gives the least amount of access to information, to administrator authentication, which gives a user complete access. After LDAP settings are accessed, SPD Server grants user access according to the protocols set in the password database.
When you use an LDAP server to perform SPD Server user authentication, keep the following facts in mind:
  • You still need to register users with the psmgr utility. A password database record is required for each SPD Server user. SPD Server uses the password database to perform user access control tasks and other tasks that are not related to user password authentication.
  • Users that connect to SPD Server must have corresponding logon information in the LDAP server. The LDAP server user ID and the SPD Server user ID formats are the same. The logon password format is the host-operating-system format.
  • You must enter an initial password in the psmgr utility when you are adding a new user. This password is never used. It simply enables you to add the new user. The user will connect with his LDAP password. The user is not required to use the NEWPASSWD= or CHANGEPASS=YES LIBNAME option to use the LDAP password.
  • Some LDAP server products might require users to enter host logon information. In these cases, confirm with your LDAP server administrator that the host logon information exists in the LDAP database.
  • If you are using LDAP user authentication and a user connection specifies the NEWPASSWORD= LIBNAME option, the user password is not changed. Follow the operating system procedures to change a user password. Be sure to check with your LDAP server administrator to ensure that the LDAP database records the password changes. The same process information applies to other nonnative authenticators as well.

Understanding SAS Metadata Server Authentication

In order to use SAS Metadata Server Authentication, you must create metadata definitions for each SPD Server user on the SAS Metadata Server, if they do not already exist. You create user definitions in SAS Management Console. Once stored on the SAS Metadata Server, the user definitions can be used by other enterprise applications. SAS Metadata Server uses the authentication provider that is specified in its configuration to perform the authentication. In this case, SPD Server passes the authentication request to the back-end authenticator via the SAS Metadata Server.
On SPD Server start-up, SAS Metadata Server configuration options in the spdsserv.parm parameter file signal the SPD Server host to authenticate users through SAS Metadata Server. SPD Server passes the user name and password from the SASSPDS LIBNAME statement to the SAS Metadata Server for validation. After the SAS Metadata Server validates the user account, SPD Server then accesses its internal password database file to determine other attributes belonging to the user.
When you use SAS Metadata Server to perform SPD Server user authentication, an entry is still required for each server user in the password database. The SPD Server password database is managed by the psmgr utility. Each user entry in the database provides non-authentication information, such as SPD Server group memberships, user performance levels, ACL privileges, and so on.
The benefits of using SAS Metadata Server authentication include the ability to use longer passwords than supported by the native SPD Server authentication. SPD Server has a native password length limit of 8 characters. The password length limit when using a non-native authentication via SAS Metadata Server is defined by the back-end authenticator. This often provides access to longer and more secure passwords. SAS Metadata Server also provides better support for using LDAP as a back-end authentication provider than direct LDAP authentication. The newer SAS Metadata Server versions provide higher levels of encryption, better integration, support, and documentation.
Last updated: February 3, 2017