One highly effective method for querying data repositories, modifying user permissions and granting access to protected resources is to utilize an LDAP server, which uses the Lightweight Directory Access Protocol (LDAP). This TCP/IP protocol is based on a client-server model and is used in Apache Directory Server, Apple Open Directory, Fedora Directory Server, IBM Tivoli Directory Server, and Microsoft Active Directory (AD) amongst others.
The operational steps of LDAP consist of a LDAP client connecting to an LDAP server, and querying the directory tree or LDAP backend database with an authentication request along with an authorization identifier. The routed request is validated against the user information on the LDAP Server. If the user identification is successful the application will populate the user credentials along with the authorization identifier, and the user will be authenticated and identified against the user information at the LDAP store and may access the resource once the correct credentials are passed.
The benefits of the LDAP method of authentication are that it can be extended for integration with other enterprise systems such as ERP and CRM solutions. Additionally, the credentials of the end user are validated through the LDAP schema i.e. a set of rules that define what can be stored as entries in an LDAP directory. As the user information is in an encrypted format, it enhances the security of the system.
The shortcomings of LDAP authentication are the additional licensing and maintenance costs inherent to a proprietary LDAP server. LDAP authentication also needs enhanced network security to communicate with the applications, and application customization for integration with other system (Khurana, 2012).
Active Directory (AD) is the Microsoft method of using LDAP for the management of user data, security, resources, and interoperability with other directories. The structure of AD consists of servers that run AD called domain controllers (DC), which authenticate and authorize users. One or more DCs are required to create a domain, which share a directory database and trust relationship with other domain and security policies.
A “tree” is a collection of one or more domains that permit resource sharing, and may contain a single domain or multiple domains in a contiguous namespace. A “forest” consists of one or more trees, with the first domain being the “root”. The forest will share transitive trusts, a global catalog, and a schema with the domains in the forest. We may further delineate our entity's structure by the use of organizational units (OU)s and place users, groups, computers, and other OUs into managerial or geographical constructs.
The Kerberos server provides a secure, single-sign-on, trusted, third-party mutual authentication service. One of the key reasons why Kerberos is secure is because it does not transmit passwords over the network in clear text, or cache passwords on the local user's hard disk. Instead, it makes use of “tickets” which are temporally limited cryptographic messages that prove a user's identity to a given server. To use Kerberos terminology, a ticket is a temporary set of electronic credentials that verify the identity of a client for a particular service.
Furthermore, once a user has authenticated to Kerberos at the start of the login session, those credentials are passed transparently to every other resource accessed during the day. This feature allows end-users to log in once to access all network resources that support Kerberos, thus providing single sign-on functionality. Kerberos is a trusted third-party, because the service works through a centralized authentication server that all systems in the network trust and all authentication requests are routed through the centralized Kerberos server. In addition, Kerberos’ mutual authentication ensures that not only is the person behind the keyboard who she claims to be, but that the server she is communicating with is who it claims to be (Garman, 2004).
The operational steps of Kerberos consist of the user’s client, alternatively known as a principal, contacting the Key Distribution Center (KDC) to authenticate, and the KDC sending a session key to the user encrypted with the user’s secret key. A principal or principal name is the unique name of a user or service allowed to authenticate using Kerberos.
The KDC sends a Ticket Granting Ticket (TGT) encrypted with Ticket Granting Service’s (TGS) secret key. The user’s client will decrypt the session key and use it to request permission to an application from the TGS.
The TGS then verifies the user’s session key and sends the user a Client Server (C/S) session key to use to access the application. The TGS also sends a service ticket, encrypted with the applications’ private key. The client connects to the application; the application sees a valid C/S session key and knows the user has permission to access it, as well as that the user is an authentic user.
Access Control Protocols
RADIUS. The Remote Authentication Dial-In User Service places the responsibility for authenticating each user in a central RADIUS server. When a remote access server (RAS) receives a request for a network connection from a client, it passes the request, along with the credentials, to the RADIUS server. RADIUS validates the credentials and forwards the decision to the RAS.
TACACS. The Terminal Access Controller Access Control System is a client/server method of validating users via a centralized database. The original version of TACACS combines authentication and authorization functionality. A later version XTACACS allows an access server to forward a user’s credentials to an authentication server to decide whether access may be permitted for a resource. There is also TACACS+ which utilizes dynamic passwords and incorporates two-factor authentication.
Diameter. This protocol which is derived from RADIUS defines the criteria for the authentication, authorization, and accounting (AAA) services of a system, and makes use of common encryption standards such as IPsec, SSL and TLS.
The Single Sign-on (SSO) standard allows users to access resources transparently without having to re-authenticate upon each subsequent log-in. The first step in the SSO process is the end-user entering their credentials and the validation of those credentials, which is called authentication. The rest of the applications will then use this authenticated session to obtain the user name, and will thereafter log-on the user automatically. This second step of the process of obtaining the user name is called the identification.
In enterprise SSO, data resides in a secure location outside the user’s PC, primarily for user mobility, and the ability to deny or grant access remotely. To facilitate this, there are essentially three basic architectures, the SSO server, SSO appliance, and Enterprise Directory.
With the SSO server, information is stored on a server that is dedicated to this task, and the client on the PC will query the server as necessary. Whereas with the SSO appliance, software and hardware are packaged together, thus reducing deployment expenses. Utilizing an Enterprise Directory allows us to store our SSO data in encrypted form, and would not require server or appliance implementation; as such our deployment expenditures are reduced (Brown, 2006).