Since time immemorial, people have stood upon their soapboxes and declared, “I am me.” Predictably, others countered with, “Okay, well how do I know that?” This was once a relatively straightforward question to answer because the users, devices, and resources were generally housed in the same building or, at worst, in separate company buildings. Plus, hackers weren’t nearly as numerous and powerful as they are now. As a result, authentication requirements weren’t very strict or complicated in nature.

This is a more challenging question today because the access control landscape has to account for a greater level of benefactors and threats. Consider the following:

•   We have billions of users and devices.

•   Technology no longer augments worker tasks but rather is the center of all tasks.

•   Users are working from everywhere.

•   Users have several devices, including personal and business desktops, laptops, smartphones, and tablets.

•   These devices may have mixed OSs and applications.

•   These devices may have mixed security requirements and configurations.

•   Users are accessing on-premises and cloud-based resources.

•   Users are connecting through public and private wired and wireless networks.

•   Organizations are connecting to other organizations, including the cloud, for resource-sharing purposes.

Access control is no longer a simple thing. It must be, to say the least, surgical to accommodate all of these competing demands—not to mention that we have to account for the contrarian dynamics of access being secure and easy to use, social networking that maintains privacy, customers becoming the products, and user accounts being located at one company while the resources are at another.

Today’s challenge is to expand on the fundamental authentication and authorization pillars with the latest advances in single sign-on (SSO), federation, and authorization protocols so that only the rightful users of accounts are granted the requisite levels of access to company assets—regardless of where those assets may be. Hackers are equal parts clever and tenacious; therefore, you will have to exercise every tool at your disposal to ensure that user accounts and access are not breached.

Since an organization’s facilities, equipment, programs, and data are valuable—and oftentimes sensitive—access must be tightly controlled. It begins with businesses identifying and properly classifying their assets, determining which departments and roles are entitled to access those assets, and then placing the appropriate users into those roles. After the resources and users are properly organized, privileges are granted to the roles or the users belonging to the roles. This will help establish privilege expectations and barriers for who is supposed to have access.

Comparatively, one could argue that the fundamentals of access control aren’t that difficult. The more problematic aspect is the accurate determination that the individual who claims to be an authorized user actually is that user. How does a system truly know that the person claiming a certain identity really is that person? Is a correct password all an attacker needs to impersonate an authorized user? The first section will warm us up with coverage of authentication fundamentals, and subsequent sections will tackle the more advanced topics.

Authentication

Identification and authentication are often mistakenly used as interchangeable terms. The reality is these are two different steps of the same process. Here’s a breakdown of these two important components:

•   Identity   The account entity that a user, device, or service is claiming to be. For example, “jsmith” is the identity for John Smith. It is what makes one user, device, or service account different from others. Identities and accounts are terms often used interchangeably. For the purposes of this discussion, we’ll focus on user identities.

•   Identification   The process of a user, device, or service claiming an identity. As a common example, when a user wishes to log in to a server, they supply their username to the server in the form of “jsmith”. The user’s action of stating or claiming to be “jsmith” is known as identification. To be clear, identification only covers the “claiming” of an identity. However, anyone can claim to be someone; therefore, verification of the claim is an important next step.

•   Authentication   The process of verifying the legitimacy of a claimed identity. If users claim to have a certain identity, authentication is how a system determines if the claimed identity really belongs to the individual making the claim. For example, John Smith supplements the “jsmith” identity with the password of “P@ssw0rd” to the server. The server then verifies that the “jsmith” username and “P@ssw0rd” password are a valid match. If username/password is the only authentication client, the server will be satisfied that the “jsmith” user account is being used by a legitimate and authorized user. This process is obviously flawed because if someone else has the “jsmith” password, the server will still consider the identification and authentication process successful.

Authentication Factors

Authentication factors are unique categories of credentials that allow the determination that a user is who they claim to be. The strength of an authentication system can be equally attributed to its variety as well as complexity. Although it’s important to have longer and more complex passwords, pairing up passwords with smart cards is a more significant upgrade than merely converting a weak password into a stronger one. Passwords and smart cards are examples of authentication factors, and two different ones at that. This section will cover the different types of authentication factors. Although authentication covers user accounts, device accounts, and service accounts, we’ll primarily focus on user accounts for the purpose of these discussions.

Knowledge Factors

Knowledge factors authenticate users based on something the user knows that no one else is likely to know. For example, passwords, personal identification numbers (PINs), passphrases, and challenge responses (mother’s maiden name) are all examples of knowledge factors. Passwords are, by far, the most common knowledge factor; therefore, this section will focus on it. When the user’s account is created, or their password needs to be changed, the user is given a unique opportunity to choose the password. Since the user is expected to craft this password in secret—while utilizing various complexity, length, and nondisclosure practices—no one else but the user should know the password. A common example of a user being authenticated based on a knowledge factor is when the user correctly logs in to a smartphone using a PIN.

Despite the popularity of knowledge factors, they are also considered the weakest form of authentication due to the relative ease of hackers cracking or stealing passwords. To mitigate this risk, the following password recommendations should be observed:

•   Password length   Just adding one extra character to a password makes it exponentially more difficult to crack. Strive for a comfortable minimum password length, typically between 8 and 12 characters. Upper limits of 16 characters are common, but anything substantially longer will likely be counterproductive. Keep in mind that longer passwords may result in more account lockouts, password resets, and passwords being written down. This reduces security rather than improving it.

•   Password complexity   A password that utilizes at least three of the four unique character sets (uppercase, lowercase, numbers, and special characters) is typically said to be complex. Complexity requirements typically bake in minimum password lengths as well, but that is generally handled by a separate password-length policy requirement.

•   Passphrases   Rather than creating passwords that are too complicated to remember, you might create passwords that are easier to remember while also being longer. These passwords are generally a collection of words as opposed to random strings of characters. For instance, “ThisIsAReallyReallyL0ngP@ssw0rd” is an example of a passphrase. If done correctly, these can be nearly impossible to crack while being relatively easy for users to remember.

•   Password frequency   Passwords should be changed every one to three months, or less, to outpace hacker cracking efforts. There are some branches of the military that change their passwords as frequently as every 10 days. The frequency of password changes should be balanced with the difficulty of remembering passwords, increased account lockouts, and calls to the help desk.

•   Default passwords   In other words, don’t use common default passwords. Many websites catalog the most popular common passwords (much like baby name books), so you must ensure that your default passwords are globally unique and quickly changed. Hackers use these websites; therefore, you might counter with blacklisting the default passwords on these sites.

•   Encryption   Passwords should be encrypted in storage and in transmission; otherwise, hackers will have an easier time obtaining them.

•   Multiple factors   When combined, two or more factors of average strength offer more security than a single factor of greater strength. At minimum, combine passwords with smart cards or use PINs with fingerprint scans.

•   Password vaults   These vaults store passwords in an encrypted format, not only for security’s sake, but also for SSO purposes as well. The downside is if the attacker compromises any of the passwords in the vault, they are likely to inherit the same one-password-for-all-resources access that the victim(s) enjoyed.

•   Password policy   Password policies should mandate much of the preceding recommendations while also teaching users how to avoid disclosing their passwords to others.

Possession Factors

Possession factors authenticate a user based on something only that user is likely to possess. In the non-CASP sense, think of everyday items that we keep close to the vest, like keys, ID badges, bank cards, driver’s licenses, social security cards, birth certificates, and passports. In the world of CASP+, possession factors can be broken down into objects that interface with the computer either directly (connected tokens) or indirectly (disconnected tokens).

Connected Tokens   Connected tokens are objects such as smart cards and USB tokens that must be physically connected to the computer to function. Smart cards contain memory chips that store private user data such as certificates and private keys, which allows the user to be authenticated by a server without having to input any information. To protect against smart card loss, PINs are added to provide a two-factor or multifactor solution. Although smart cards themselves are cheap, the smart card readers that plug into a computer can be expensive and are therefore avoided by some organizations. In contrast, USB tokens are more affordable and less complex because they plug directly into a USB port and don’t require extra hardware purchases.

Disconnected Tokens   Disconnected tokens are not physically connected to the computer at all. Users typically hold these tokens, which generate a pseudorandom code on their built-in screens—which is then entered into a secure login screen for authentication purposes.

Inherent Factors

Inherent factors identify human-based characteristics that are physiologically or behaviorally linked to the individuals themselves. Physiological characteristics identify “something you are,” whereas behavioral characteristics identify “something you do.” These characteristics are inherent to the users regardless of their knowledge of information or possession of objects.

Physiological Characteristics   Physiological characteristics are unique to each individual. A biometric system is needed to scan and collect a sample of a person’s hand, finger, face, eyes, DNA, or even a vein, which gets stored in a database. For example, when people place their finger on a fingerprint reader, the captured fingerprint gets compared to the known copy stored in the database. If the submitted sample matches the database copy, the system authenticates the user. Here are some examples of physiological characteristics:

•   DNA scan   Although still in its infancy and designed for ultra-secure environments, this scan method promises to be extremely accurate and relatively foolproof due to the uniqueness of the human genome. A blood test containing a subject’s genetic profile may be necessary to gain admittance to an area or access secure systems.

•   Facial scan   This scan records facial features such as the nose, chin, forehead, and the contours of eye sockets.

•   Fingerprint scan   This scan captures the impression from the ridges of a person’s finger.

•   Iris scan   This scan type identifies the colored ring-shaped portion surrounding the pupil of the eye. This is widely considered the most preferred biometric method due to the iris being internal, being randomly generated during early human development, producing minimal false-positive and false-negative outcomes, and being compatible with certain eyewear like contacts and glasses.

•   Palm scan   This scan is designed to capture the palm and all fingers, including all lines, wrinkles, and ridges in the palm.

•   Retina scan   Unlike an iris scan, a retina scan captures the unique patterns of blood vessels in the retina. Although common, this method measures up poorly to other biometric methods, especially in comparison to iris scans, due to issues with accuracy and user friendliness.

•   Vascular scan   Somewhat similar to a retina scan, vascular pattern recognition is a type of scan that typically involves scanning the blood vessels from a person’s fingers, palm, or face.

Behavioral Characteristics   Behavioral characteristics use biometric systems to scan and collect samples of what the person does. Although not as plentiful as behavioral characteristics, the following are some behavioral samples:

•   Keystroke biometrics   Describes the unique typing pattern of an individual. This includes speed, pattern of keys used, pace, pauses, and transitions between keys. Even if the user types the password correctly, they may be denied access if the keystrokes don’t match the stored keystroke pattern.

•   Voice recognition   Also known as speaker recognition, this scan type identifies the speaker through the acoustic features of speech that are uniquely shaped by an individual’s throat and mouth, plus the behavior patterns of speaking inherent in pitch and speaking style.

•   Mouse dynamics   People use computer pointing devices differently. Some favor the left button versus right button for single- and double-clicking. Other behaviors captured and examined are time of day usage, length of usage, pointer sensitivities, cursor types, middle wheel usage, and more. These are all factored into an individual’s mouse movement profile.

•   Signature dynamics   Captures a person’s writing pattern, which includes usage of X and Y spatial coordinates, pen/pencil pressure, as well as acceleration and deceleration patterns.

•   Cognitive biometrics   Rather than “non-reactive” biometric methods such as fingerprints and iris scans, cognitive biometrics measures a person’s cognitive (state of mind) response to external stimuli such as a photograph of a family member, music, or other object. It’s like a lie detector test since a person’s brain will react to a song they like in a consistently positive and predictable way regardless of intention.

Certificate-Based Authentication

Digital certificates are standard digital containers used to pass information between parties. A digital certificate contains at a minimum a Distinguished Name (DN) and an associated public key—with the entire certificate being signed by a trusted third party. Certificates are used to pass public keys between parties, and through the application of public key cryptography, identity can be established. Assume Alice wishes to verify her identity to Bob. She can pass her certificate with her public key to Bob, and he can do the same in return. Using the public keys, the two entities can pass a secret to each other that only they can read. Using a handshake, the two parties not only can determine the veracity of the other’s identity, but can also generate a session key used to secure the communication channel.

Certificate-based authentication systems require a fairly extensive infrastructure in the form of public key infrastructures (PKIs). They are also subject to various threats, including certificate theft and man-in-the-middle-type attacks. In spite of some of these difficulties, certificate-based authentication is still the most widely used method of authentication on the Web. HTTPS connections are examples of certificate-based authentications.

Certificate-based authentication can address the authentication issues via hierarchies of trust. The use of a PKI establishes a trust relationship between an entity and the certificate authorities it chooses to trust. If a trust relationship can be established between a trusted Certificate Authority (CA) and the CA issuing the certificate of the user in question, then the certificate can be assumed to be valid.

SSL/TLS Certificate-Based Authentication

Certificates are used to establish SSL/TLS-based connections. High-assurance SSL uses a combination of an extended-validation SSL certificate and a high-security browser. This enables a method to differentiate between levels of certificate trust, with extended validation certificates representing greater trust. This provides reasonable assurance for the end user that the entity they are connecting to is indeed the entity represented by the URL. Note that this is still single-sided authentication and is subject to man-in-the-middle attacks. Eliminating this attack vector would require a mutual authentication methodology, where both sides of the communication authenticate themselves. The issue with adopting this solution Internet-wide is one of scale. Although there is a limited number of banks and other servers one would connect to via SSL/TLS, the number of individual clients is many orders of magnitude greater, thus dramatically increasing the scale challenges of PKI for the server side of the mutual authentication chain.

Figure 14-1 illustrates an SSL/TLS handshake, showing the use of certificates to validate identity in a single-sided authentication. One of the advantages of using certificate-based authentication with systems such as SSL/TLS is the integration of the methodology into browsers and applications, making it transparent to the end user.

Figure 14-1    SSL/TLS handshake

Here’s a detailed explanation of the SSL/TLS process:

1.   The client sends to the server the client’s SSL version number, cipher settings, and session-specific data.

2.   The server sends to the client the server’s SSL version number, cipher settings, session-specific data, and its own certificate. If the resource requested requires client authentication, the server requests the client’s certificate.

3.   The client authenticates the server using the information it has received. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.

4.   The client encrypts a seed value with the server’s public key (from certificate—step 2) and sends it to the server. If the server requested client authentication, the client also sends the client certificate.

5.   If the server requested client authentication, the server attempts to authenticate the client certificate. If the client certificate cannot be authenticated, the session ends.

6.   The server uses its private key to decrypt the secret and then performs a series of steps (which the client also performs) to generate a master secret. The required steps depend on the cryptographic method used for key exchange.

7.   Both the client and the server use the master secret to generate the session key, which is a symmetric key used to encrypt and decrypt information exchanged during the SSL session.

8.   The client sends a message informing the server that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.

9.   The server sends a message informing the client that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

10.   The SSL handshake is now complete and the session can begin.

Single Sign-On

Single sign-on (SSO) is a subset of a federated identity management system where a user’s credentials are trusted across multiple distinct systems. SSO can be accomplished through a variety of mechanisms, including Kerberos-based systems, token-based systems, and separate applications. In each of these cases, the role of SSO is to connect a user to a collection of authentication tokens via a single set of credentials convenient to the user.

Kerberos is a common authentication system that is used in both Windows and Linux systems. By definition, when users log on to a Kerberos system and get a Ticket-Granting Ticket (TGT) and then use that ticket to get service tickets, they are participating in a form of SSO. The Kerberos-generated TGT acts as a set of credentials that is then manifested in other systems via the service tickets.

A token-based system is one where access to the SSO is via a token, as opposed to a password-based mechanism. Tokens, whether they are one-time password (OTP) or smartcard based, are used to increase security levels over standard password-based mechanisms. The risk of unauthorized access is reduced from threats directed at weaknesses of password systems, but the rest of the SSO security is not generally affected.

The use of third-party applications ranges from custom web-based solutions deployed in enterprises to act as SSO gateways, to systems such as OpenID. Facebook can even be used as an SSO.

802.1x

The IEEE 802.1x standard is a port-based network access control method that prevents users from connecting to a network until they are authenticated. Although originally designed for wired networks, the standard equally applies to wireless networks.

If left alone, Ethernet switches and wireless access points will gladly handle all authentication requirements for wired and wireless devices, respectively. However, networks have far too many of these devices to easily standardize ID verification, access control, and auditing capabilities for the enterprise. To mitigate this, Ethernet switches or wireless access points can be configured to yield these responsibilities to a central authentication point such as Remote Authentication Dial-in User Service (RADIUS) or Terminal Access Controller Access-Control System Plus (TACACS+) servers for processing. These are also known as Authentication, Authorization and Accounting (AAA) servers since they specialize in ID verification, access control, and auditing capabilities.

AAA servers don’t merely standardize security but also enhance it through the use of powerful protocols and methods like EAP-TLS, PEAP-TLS, certificates, PKI, and hardware-based authentication methods.

The 802.1x authentication involves three components:

•   Supplicant   The wired or wireless device attempting a network connection.

•   Authenticator   The Ethernet switch or wireless access point that initially receives the supplicant’s connection attempt, which then gets redirected to an authentication server.

•   Authentication server   The RADIUS or TACACS+ centralized authentication point that receives the authentication attempt from the authenticator and processes any AAA policies.

Context-Aware Authentication

Imagine a situation where a hacker correctly types a victim’s password but is denied authentication anyway. Context-aware authentication builds on conventional authentication methods by also considering the user’s technological and environmental characteristics (patterns)—all of which are known to the context-aware authentication system.

Although there are variations in context-aware authentication requirements, passwords will be buffered by additional authentication criteria such as the following:

•   Trusted device

•   Time of day

•   Geographical position

•   Time zone

•   Installed OS

•   Installed apps

•   Running processes

Since it would be difficult for the hacker to impersonate all of the user’s patterns, authentication is more persuasively assured.

Push-Based Authentication

Quick, what’s an easy way to implement a possession-based authentication solution without having to buy the users anything? Simple—leverage their smartphones. Bring Your Own Device (BYOD) and Choose Your Own Device (CYOD) have one compelling attribute to them, and that is people are only too happy to spend several hundred dollars on a device that never leaves their pocket.

What does this have to do with push-based authentication? Push-based authentication takes advantage of smartphones by pushing out a special access code to the user’s device that the user must input to a form in order to authenticate to a system. Let’s say you want to create a Microsoft Office 365 E5 trial account. Microsoft will ask you for your mobile phone number so it can text you a code. Once you input the code, you are able to complete the Office 365 trial subscription process. Having the phone (possession) and the code (knowledge) will serve as a type of two-factor authentication. Any form of two- or three-factor authentication is better than one-factor authentication.

Authorization

The whole point of authentication is to help us reach a point where we can decide what, if any, resources the identified individual should be granted access to—and the level of access they be granted to said resources. Authorization spells out the “what” and the “how much” access the authenticated user should be granted. This section will cover more modern authorization topics such as OAuth, XACML, and SPML.

OAuth

OAuth is a token-based authorization standard that permits an end user’s resources or account information to be shared with third parties without their password also being shared. This is extremely common with social media applications like Facebook, Twitter, LinkedIn, and Foursquare.

Say you’re logged in to the Salesforce website and looking to apply a signature to a form. Another party, DocuSign, sends you a dialog box requesting permission to access certain information from your Salesforce account—while also being able to perform requests on your behalf at any time. Upon clicking “Allow,” you have granted DocuSign (a third party) the necessary permissions to acquire data and perform signatures through the Salesforce website. Here’s a brief summary of OAuth technical steps:

1.   DocuSign directs the user to a Salesforce authorization page where Salesforce prompts the user to allow or deny DocuSign permission to Salesforce.com resources.

2.   User clicks Allow, which advises the Salesforce authorization page that DocuSign will be permitted to exercise certain permissions on the Salesforce website on behalf of the Salesforce user.

3.   The Salesforce authorization page generates an authorization token that is then sent to DocuSign.

4.   DocuSign connects to Salesforce.com with the authorization token and exercises its granted permissions on Salesforce (chiefly the right to collet some Salesforce data and apply DocuSign digital signatures on behalf of the Salesforce user).

XACML

Based on XML, the eXtensible Access Control Markup Language (XACML) defines an access control policy language to standardize the exchange of security policies and access privileges between web vendors. XACML has been ratified by the OASIS standards organization and is currently in draft as version 3.0.

The primary purpose of XACML is to translate simple statements—such as “Can John Doe access his own medical records at ACME Hospital?”—into a machine-readable format that can be used across multiple vendors, thus automating the access control policy process.

SPML

Service Provisioning Markup Language (SPML) permits the sharing of user, resource, and service provisioning information among a group of organizations. The objective of SPML is to enable organizations to quickly set up user interfaces for web services in an automated manner. The use of an open standard enables vendor neutrality and reduces custom provisioning interfaces.

Attestation

Attestation is the act of certifying some element to be true and doing so in a fashion that provides a form of evidence as to its authenticity. Attestation with respect to authentication involves the use of standards and messages. For instance, when using certificate-based authentication, one can attest to the validity of the certificate, and based on the trust relationship established by the PKI chain, one can attest to the authenticity of the binding of the public key to the named entity on the certificate. Then, based on the principle that the private key is indeed still private, if not revoked, the validity of signed objects is demonstrated. The use of a standards-based system to manage the delivery of credentials addresses implementation issues. If we have two cases of attestation—one performed by someone saying “Trust me, it’s true” and the other backed by standards and proven protocol exchanges designed to provide traceable trust—it is obvious which method one should trust.

Identity Proofing

At first glance, identity proofing looks a lot like authentication. After all, if authentication is the process of verifying IDs, then identity proofing is, well, proofing identities, right? Yes, but the contexts of these two topics are quite different. Let’s look a little deeper.

For authentication to happen, the user must already have credentials. For example, an employee named John Smith has a username of “jsmith” with a password of “P@ssw0rd”. As a result, John Smith can attempt to log on to a system with those credentials, which then gets authenticated by a server.

However, what happens prior to John Smith receiving these credentials? More importantly, how does he earn his credentials in the first place? That’s where identity proofing comes in. Identity proofing verifies people’s identities before an organization issues them accounts and credentials. At the beginning of John Smith’s employment, he had to go through an identity proofing process to prove to the organization that he actually is John Smith. This involves either submitting proofs in person or remotely. In more crucial scenarios, in-person identity proofing is needed for physical submission of critical documents like a social security card, birth certificate, driver’s license, passport, and proof of address. For less critical scenarios, remote online identity proofing can be performed by e-mailing some or all of the same important documents.

After John Smith has successfully completed the identity proofing process, the organization feels comfortable enough to generate a user account identity on John Smith’s behalf with a corresponding password—that John Smith changes at first login. Not only has John Smith passed the identity proofing test, but him changing the password to one that only he knows provides strong assurance that successful logins with the John Smith account must have been initiated by him.

Identity Propagation

Many organizations have applications that share information and workloads with one another while having different authentication engines. This can be a challenge when an identity from one authentication source wishes to access resources located at another authentication source. A possible solution is to distribute identities across disparate authentication systems in what is known as identity propagation. Assuming all parties support distributed identities and have a trust relationship with one another, identity propagation seeks to exchange identity information between dissimilar authentication systems while preserving the properties of such identities. Exchanging identities across different authentication systems also helps to preserve audit trails. IBM’s Customer Information Control System (CICS) supports identity propagation.

Federation

Advanced authentication tools, techniques, and concepts are important elements of an enterprise security program. All processes in IT systems operate under the context of an ID. Identity management begins with an identification step to establish an ID and then a series of management steps to utilize the ID. The management steps include the authentication, authorization, and maintenance of IDs. In simple standalone systems, all of these functions are handled by an operating system. In complex enterprises, different elements are utilized to handle different aspects of identity management.

Federated identity management involves a common set of policies, practices, standards, and protocols used to manage the processes involved in identifying users and managing trust relationships in distributed IT systems. The objective of federated identity management systems is to permit users from one domain to seamlessly use that domain’s credentials to access resources located at another domain without having to resort to a separate identity verification step involving user interaction. Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data. In a federated system, there is a need to exchange authentication and authorization information between Identity Providers and Service Providers. An Identity Provider can offer assertions that can be used by a Service Provider in the course of ensuring appropriate access control functions.

Identity management systems begin as simple password/authentication/access control mechanisms on individual systems. As the number of interconnected systems grows, a need arises for a unified, centralized management structure. A federated approach is one that provides authentication and authorization information across multiple distinct system boundaries. Identity management systems are complex sets of components, including elements that manage identities, provision/deprovision accounts, implement access control mechanisms, implement protocols, and utilize standards.

SAML

SAML is a standard for exchanging authentication and authorization information between security domains. Developed by OASIS (an international consortium that drives web service standards), the current version of SAML is 2.0. This version unites SAML 1.1, the Liberty Alliance Identity Federation Framework, and the Shibboleth 1.3 Framework under a single framework. SAML is defined in terms of assertions, protocols, bindings, and profiles (see Figure 14-2).

Figure 14-2    SAML components

SAML is built using existing industry standards. This enables widespread application and adoption with a minimum of additional foundational elements. The standards used in SAML include the following:

•   Extensible Markup Language (XML)   Base standard of SAML.

•   XML schema   SAML assertions and protocols.

•   XML signature   Used for SAML digital signatures.

•   XML encryption   Used in SAML 2.0 to provide for encryption capabilities.

•   Hypertext Transfer Protocol (HTTP)   SAML’s communications protocol.

•   SOAP   SAML uses SOAP 1.1 to move objects via HTTP.

SAML works as shown in Figure 14-3. A user requests authentication from an Identity Provider (IdP), which becomes an asserting party across a trust relationship to a Service Provider (SP), which then can use the asserted credentials in making an access control decision concerning the user.

Figure 14-3    SAML-based authentication

OpenID

OpenID provides users with a mechanism to consolidate their various digital identities. OpenID is an open standard that connects end users, OpenID providers (OPs), and relying parties (RPs), and allows end users to be authenticated in a decentralized manner. This eliminates the need for each service to provide its own authentication mechanism and for users to access multiple systems.

OpenID systems operate around the mechanism of an OpenID provider (OP) that offers a service to enable end-user communication of credentials to relying parties. An end user establishes an identity relationship with an OP. Then, when the end user wishes access to a website that allows OpenID connections, they can provide a reference to their established identity with the OP. The website (RP) uses the OpenID information provided by the end user to establish a connection to the OP. The end user then has the option of providing credentials and trust for the RP to use them. If both are positive, the authentication is considered valid.

Shibboleth

Shibboleth is an open source and web-based federated identity solution that is very popular worldwide. It facilitates an organization’s users to use only one account and authentication process to access web-based resources that are located across different organizations or divisions. Universities commonly use SSO products due to their geographical spread, complexity, and concentration of users. Shibboleth allows users to log on one time with their usual—let’s say Active Directory—user account to access resources located at different parts of the shared federation between the user’s organization and the resource’s organization. The local organization maintains and authenticates the local user and then controls the transmission of authenticated user information to the other organization, which then handles the resource authorization steps.

Shibboleth’s identity provider and service provider are implementations of the SAML protocol—which handles the exchange of authentication and authorization information between said identity and service providers.

SSO products can be confusing, so let’s take a look at the following list of Shibboleth components for simplification:

•   Home organization   The local organization that contains users who wish to access resources located at other resource organizations.

•   Resource organization   The resource organization contains the resources to be accessed by users located at the home organization.

•   Home user   A user whose account is located at the home organization and wishes to access resources located at the resource organization.

•   Web browser   Web-based software used by the home organization’s user to access resources located at the resource organization.

•   Target resource   The resource that is located at the resource organization.

•   Identity provider   The identity service that is located at the home organization and is responsible for authenticating local users who wish to access resources located at the resource organization. This service is also responsible for directing the authenticated user information to the resource provider.

•   Service provider   Located at the resource organization, this service is responsible for protecting its resources by requiring users from other home organizations to be authenticated and then redirected to the resource organization for authorization to protected resources.

•   Discovery service   Occasionally needed by service providers to locate other identity providers.

Now that we’ve covered the building blocks of Shibboleth, let’s see the process of a user requesting access to a resource. Shibboleth’s process of using SAML to grant access to federated resources is as follows:

1.   The user attempts a connection to the resource organization in order to access resources.

2.   The resource organization’s service provider generates an authentication request, which then gets sent, along with the user, to the home organization’s identity provider.

3.   The identity provider authenticates the user and generates an authentication response, which then gets sent, along with the user, to the resource organization’s service provider.

4.   The service provider validates the authentication response and then permits access to the user’s requested resource.

WAYF

Where Are You From (WAYF) is a centralized SSO implementation frequently used by university federations to anchor resource access between federated partners. Unlike some SSO methods, WAYF acts as a proxy between federated identity providers and service providers. See Figure 14-4 and the following process:

Figure 14-4    WAYF diagram

1.   A home organization user sends a communication request to the federated partner’s service provider.

2.   The federated partner’s service provider directs the user to a WAYF management service.

3.   The WAYF service then asks the user, “Where are you from?” Based on the answer, the WAYF service directs the user, along with an authentication request, to the user’s identity provider located at the home organization.

4.   The home organization’s identity provider then authenticates the user and, based on user consent, forwards the authenticated information to the federated partner’s service provider.

5.   The service provider processes the authenticated information and then authorizes the user’s resource access.

Trust Models

Before we dive into trust models, let’s warm up with a quick analogy. How can a stranger abruptly show up at a nightclub, present a driver’s license to the security guard, and gain admittance in a manner of seconds? The answer is, in a word, trust. The security guard trusts the DMV’s identity proofing and authentication requirements, and the DMV provided the customer with a driver’s license due to compliance with those requirements; therefore, the security guard trusts that the customer is who they say they are. The DMV driver’s license system allows quick ID verification and exercise of privileges with little to no hassle.

Each state government has its own group of DMV locations (hierarchical trust model), and licenses issued by one state are also valid in other states—or even in some other countries (cross-certification trust model). Imagine if state-issued IDs are taken out of the equation, and various nightclubs formed a shared ID system with each other and the customers; this would be akin to a peer-to-peer trust model. With that as the backdrop, let’s take a look at some trust models such as hierarchical, cross-certification, and peer to peer. Then we will delve into some more particular examples such as RADIUS, LDAP, and Active Directory.

Hierarchical Trust Model

Trust models define the unique relationships between issuers and recipients of digital certificates. Although unlikely, some organizations have a single live Certificate Authority (CA) server that issues all certificates within an organization. More commonly, security and scalability concerns will call for the implementation of a hierarchical trust model. This model involves a tiered or hierarchical group of servers collectively issuing certificates to subjects, while also fostering trust among them.

The hierarchical trust model begins with the root CA, which is at the center of the public key infrastructure (PKI). It generates a public/private key pair and then digitally signs its own certificate with its hidden private key. In other words, “I am the root CA because I said so.” For security reasons, the root CA is taken offline; meanwhile, one or more subordinate CAs are created to perform the daily certificate issuance, verification, and revocation duties.

Subordinate CAs can also be broken down into lower-level subordinate servers, thus forming a third layer or level in the hierarchy. The root server represents the first level, whereas the second-level CAs might be based on region, and the third-level CAs might be based on specific purpose, such as issuing certificates for smart cards, IPSec, EFS, and so on.

If you were to connect two or more hierarchical PKIs together, you would have a cross-certification trust model. In other words, the CAs or subordinate CAs from one hierarchy trust the CAs or subordinate CAs from another hierarchy. Whether resulting from partnerships, acquisitions, or mergers, organizations often merge their PKIs in order to facilitate web-based resource access without having to rebuild the PKIs from the ground up. Despite the convenience benefits of cross-certification, it doesn’t scale well due to the complexity that results from more servers having to explicitly trust more servers.

Peer-to-Peer Trust Model

Rather than having PKIs creating a centralized hierarchy of trust relationships that begin/end with the root CA, e-mail protocols such as PGP and OpenPGP utilize a peer-to-peer trust model. This model uses a decentralized approach, where all resource form trust relationships directly with all other resources. No one server has the single responsibility of knowing everyone else; rather, each server or resource can vouch for the others in a mesh-like topology. This is achieved by each server signing all other servers’ certificates. This helps to avoid the single points of failure common with PKIs if, for example, the root or subordinate CAs should be compromised or unavailable.

RADIUS Configurations

With incarnations dating back to the early 1990s, the Remote Authentication Dial-In User Service (RADIUS) Internet protocol began as an AAA server back in the dial-up networking heyday. RADIUS servers, which generally use port 1812, served as a “big brother” to dial-up servers by centrally managing remote access policies for an organization’s (or ISP’s) group of dial-up servers. Organizations often had many dial-up servers, or the servers were geographically spread out; therefore, a centralized solution was needed to reduce complexity while easing administration. This is an example of a successful dial-up connection using RADIUS:

1.   User initiates authentication to the dial-up server.

2.   Dial-up server responds with authentication requirements dictated by the RADIUS server’s AAA policy.

3.   User replies with required authenticated information.

4.   Dial-up server delivers user’s reply to the RADIUS server for verification.

5.   RADIUS server responds with Accept, Reject, or Challenge, which gets sent back to the dial-up server.

6.   Dial-up server passes the server’s Accept, Reject, or Challenge response to the client. The client’s connection is either allowed, disallowed, or pending an additional authentication response to the RADIUS server’s challenge.

In this example, the client only deals with the dial-up server, and the RADIUS server only deals with the dial-up server. Therefore, from the perspective of the RADIUS server, the dial-up server is the “RADIUS client.”

Since dial-up networking is pretty rare today, RADIUS added AAA support for the new generation of RADIUS clients such as VPN servers, Wi-Fi access points, and even 802.1x-compliant Ethernet switches. The authentication and authorization components of RADIUS are described in RFC 2865, while accounting is covered in RFC 2866. Without RADIUS, these servers, switches, and access points would be independently responsible for managing their own policies.

RADIUS solutions often stand alone in a hierarchical-type trust model, yet the implementation of RADIUS proxy servers can be used to load-balance traffic across multiple RADIUS servers within an organization—or even across RADIUS servers located in other RADIUS realms.

LDAP

Lightweight Directory Access Protocol (LDAP) is a directory service protocol for information storage and retrieval from LDAP-based databases. LDAP typically uses port 389 and is supported by a variety of commonly used directory service products such as Microsoft’s Active Directory (AD), OpenLDAP, OpenDS, and others. Be aware that as a security professional, it is your job to research and secure your specific LDAP software. Here are some general best practices for securing LDAP software:

•   Do not use deprecated SSL encryption for LDAP; instead, use SASL or TLS.

•   Disable old account entries in a timely manner.

•   Don’t delete old accounts to prevent reusing old identifiers (disable them instead).

•   If delegation of authority is required, do not use password sharing.

•   Avoid storing passwords in a way that would allow the cleartext password to be reconstructed.

•   Passwords should be hashed with a good salt.

•   Use care when enforcing password policies to provide availability and prevent accidental account lockouts.

•   Use replication to back up data and provide availability.

•   Implement replication in different physical or logical locations.

•   Use a separate LDAP server for publicly accessible information.

•   Limit the size of search results if possible.

•   Secure the server operating system with standard security best practices.

•   Protect the LDAP data store with tight permissions and encryption.

•   Do not run LDAP or other services with unnecessary permissions.

•   Configure resource limits such as file descriptors and TCP connections to ensure availability.

AD

Microsoft Active Directory (AD) is a popular directory service product created by Microsoft for the management of Windows domains. AD is used in Windows domain networks and included with most versions of Windows Server since Windows 2000. Active Directory uses LDAP and Kerberos for authentication and authorization of users and computers within a Windows domain.

Perhaps the most important aspect to securing Active Directory lies in correct planning and delegation of administration. Delegation is usually done in order to match the organizational structure and to meet operational as well as legal requirements. Two kinds of administrative responsibilities can be delegated: service management and data management. A good plan for the delegation of authority increases security by ensuring isolation and autonomy of data and services.

For each department within the organization, determine the most suitable level of autonomy and isolation. Multiple organizational units should be used when data autonomy is desired. For domain-level service autonomy, employ multiple domains. Use separate forests for service isolation, forest-level service autonomy, and data isolation. When installing a domain controller, follow these best practices:

•   Use automated installation processes to ensure predictable, repeatable, and secure deployments.

•   Use the NTFS file system.

•   Disable all network transport protocols besides TCP/IP.

•   Install and secure DNS.

•   Do not install IIS, SMTP, or other unnecessary services.

•   Use strong passwords.

•   Disable nonessential services.

•   Test for and disable anonymous Active Directory access.

In addition to these best practices, be sure to audit your Active Directory service regularly. In addition to ensuring that your Active Directory services are not compromised, auditing will verify that isolation and autonomy are implemented as desired as well as track important security-relevant changes. You can find more extensive checklists for securing Active Directory online at Microsoft TechNet and SANS.

Chapter Review

This chapter covered the different scenarios of integrating and troubleshooting advanced authentication and authorization technologies to support enterprise security objectives. We began this section with a comprehensive overview of the fundamentals of authentication, including identity, identification, and authentication terminologies. We then went over various authentication factors, such as knowledge-based factors like passwords, PINs, passphrases, and challenge-response questions. We then included some general password recommendations given the popularity of passwords today. Next, we touched on possession factors like connected and disconnected tokens as well as inherent factors like physiological and behavioral characteristics of humans.

The next section touched on more complex examples of authentication topics, beginning with certificate-based authentication and the SSL/TLS handshaking process. The next topic, which anchors much of the topics of the chapter, was SSO. This SSO section touched on Kerberos, token-based systems, OpenID, and even Facebook as potential examples of SSO implementations. We next dove into a somewhat misunderstood protocol called 802.1x, which facilitates port-based authentication for both wireless and wired networks. Other topics like context-aware authentication revealed a seemingly strange situation in which a hacker correctly types a victim’s password and still gets denied entry due to the rest of the logon scenario lacking the appropriate context (time of day, geographical location, and so on). Push-based authentication involves sending access codes to users’ mobile devices to validate their logon attempts.

The next section temporarily switched to a discussion of authorization. Whereas authentication verifies user identities, authorization decides what privileges are granted to identities. Coverage of OAuth opened the section, which permits resource access between third parties without them sharing passwords with one another. XACML is one of many XML languages, which in this case is used for access control policies and rights between web partners. The section on SPML covered the provisioning of user interfaces for web services between web partners in an automated manner.

We then briefly discussed attestation and how popular systems like PKI make it possible for web systems to certify the veracity of identity claims.

Next was a section on identity proofing and how it focuses on the preliminary steps a user must go through to prove their identity for an organization they work for. Unlike authentication, this step takes place before a user is assigned credentials.

The next brief section focused on identity propagation and how organizations must occasionally share credentials between their various authentication engines to simplify authentication and auditing across company boundaries.

The section on federations began by focusing on users using their account from a home organization to access resources located at a different resource organization. Protocols like SAML were discussed, which permits the exchange of authentication and authorization information between these different organizations. Then we covered OpenID, which focuses on the consolidation of digital identities for decentralized authentication solutions between federated partners. Next, we discussed the Shibboleth federated identity management product and how it uses SAML to federate the various campuses of university networks. Then we discussed a Shibboleth variant called WAYF, which uses an outside federation server to federate the relationship between two different organizations.

The final section talked about trust models, which dictate the flow of relationships between the producers and consumers of digital certificates. This includes the single CA trust model, hierarchical trust model, cross-certification hierarchies, and peer-to-peer trust model. We then provided more specific examples of trust models in the cases of RADIUS, LDAP, and Microsoft’s Active Directory.

Quick Tips

The following tips should serve as a brief review of the topics covered in more detail throughout the chapter.

Authentication

•   An identity is the account entity that a user, device, or service is claiming to be.

•   Identification is the process of a user, device, or service claiming an identity.

•   Authentication is the process of verifying the legitimacy of a claimed identity.

•   Authentication factors are unique categories of credentials that allow the determination that a user is who they claim to be.

•   Knowledge factors authenticate users based on something the user knows that no one else is likely to know, such as passwords, PINs, passphrases, and challenge-response questions.

•   Possession factors authenticate users based on something only that user is likely to possess, such as connected tokens (smart cards) and disconnected tokens (RSA SecureID tokens).

•   Inherent factors identify human-based characteristics that are physiologically or behaviorally linked to the individuals themselves.

•   Physiological characteristics are unique to each individual, such as DNA, facial complexion, palms and fingerprints, eye irises and retinas, and veins.

•   Behavioral characteristics use biometric systems to scan and collect samples of what the person does, such as keystroke biometrics, voice recognition, mouse dynamics, signature dynamics, and cognitive biometrics.

•   Digital certificates are electronic documents used to provide attribution of a public key to a user, computer, or service.

•   Single sign-on (SSO) is a subset of a federated identity management system where a user’s credentials are trusted across multiple distinct systems.

•   The IEEE 802.1x standard is a port-based network access control method that prevents users from connecting to a wired or wireless network until they are authenticated.

•   Context-aware authentication builds on conventional authentication methods by also considering the user’s technological and environmental characteristics (patterns)—all of which are known to the context-aware authentication system.

•   Push-based authentication takes advantage of smartphones by pushing out a special access code to the user’s device that the user must input to a form in order to authenticate to a system.

Authorization

•   Authorization determines the access scope and permissions a user has to resources.

•   OAuth is a token-based authorization standard that permits an end user’s resources or account information to be shared with third parties without also sharing their password.

•   XACML defines an access control policy language to standardize the exchange of security policies and access privileges between web vendors.

•   SPML permits the sharing of user, resource, and service provisioning information among a group of organizations.

Attestation

•   Attestation is the act of certifying some element to be true and doing so in a fashion that provides a form of evidence as to its authenticity.

Identity Proofing

•   Identity proofing verifies people’s identities before an organization issues them accounts and credentials.

Identity Propagation

•   Identity propagation distributes identities across disparate authentication systems to preserve the properties of accounts and their audit trails.

Federation

•   Federations are groups of trusted organizational networks that permit users from one network to seamlessly use that network’s credentials to access resources located at another network without having to resort to a separate identity-verification step involving user interaction.

•   SAML is a standard for exchanging authentication and authorization information between security domains.

•   OpenID provides users with a mechanism to consolidate their various digital identities.

•   Shibboleth is an open source and web-based federated identity solution that is very popular worldwide.

•   WAYF is a centralized SSO implementation frequently used by university federations to anchor resource access between federated partners.

Trust Models

•   Trust models define the unique relationships between issuers and recipients of digital certificates.

•   Single CAs issue all certificates within an organization.

•   Hierarchical trust models involve a tiered or hierarchical group of servers collectively issuing certificates to subjects—while also fostering trust among them.

•   Cross-certification trust models involve the CAs from one hierarchical trust model trusting the CAs from another hierarchical trust model.

•   Peer-to-peer trust models use a decentralized approach where all resources form trust relationships directly with all other resources.

•   RADIUS is a protocol that centralizes authentication, authorization, and accounting services across remote access solutions.

•   LDAP is a directory service protocol for information storage and retrieval from LDAP-based directory service databases.

•   Microsoft Active Directory is a popular directory service product created by Microsoft for the management of Windows domains.

Questions

The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.

1.   ______ defines a declarative access control policy language implemented in XML and a processing model that describes how to interpret the policies.

A.   SAML

B.   XACML

C.   SOAP

D.   SSO

2.   Your firm needs to purchase a third-party application to assist in the exchange of authentication and authorization data between security domains. You want to ensure interoperability, so you insist that the vendor’s solutions are compliant with the _____ standard.

A.   SPML

B.   XML

C.   SAML

D.   SSO

3.   Which of the following uses public key cryptography to provide a secure means of authentication?

A.   Basic authentication

B.   Digest authentication

C.   Form-based authentication

D.   Certificate-based authentication

4.   To use XACML, one needs to have a defined set of which of the following?

A.   Envelope, body, and fault elements

B.   Policysets containing policies composed of rules

C.   Profiles, bindings, and protocols

D.   Identity Provider (IdP), Service Provider (SP), and asserting party

5.   The advantages of SSO include which of the following? (Choose all that apply.)

A.   Reduced help desk costs

B.   Improved security from SAML integration

C.   Reduced complexity of authentication system

D.   Improved end-user experience

6.   SPML is used for what purpose in the enterprise?

A.   As a mechanism to consolidate digital identities across federated boundaries

B.   To trust credentials across multiple distinct systems

C.   To automate the provisioning of web service requests

D.   As a declarative access control policy language

7.   Which of the following standards defines profiles, bindings, protocols, and assertions?

A.   SOAP

B.   XACML

C.   SPML

D.   SAML

8.   As part of an acquisition of a smaller firm, you now have some IT systems that have federated authentication based on the older Liberty Alliance Identity Federation Framework. You need to integrate this into your existing enterprise solution based on SAML 1.1. What is the best course of action for the enterprise as a whole? (Choose all that apply.)

A.   Upgrade all federated authentication to a SAML 2.0–compliant solution.

B.   Nothing, because the two systems are already compatible.

C.   Examine both SAML and Liberty Alliance and pick the best solution for your circumstances.

D.   Move to an SPML-based solution.

9.   Advantages of a SAML-based authentication system include which of the following? (Select all that apply.)

A.   A single, synchronized password across all systems

B.   Platform-neutral authentication

C.   Reduced costs

D.   Reduced authentication system complexity

10.   An attestation is _________________________.

A.   a statement certifying some element to be true

B.   used to explain details behind assumed facts

C.   an element of SAML

D.   an element of certificate-based authentication

11.   Certificate-based authentication systems are characterized by which of the following? (Select all that apply.)

A.   A fairly extensive infrastructure in the form of public key infrastructures (PKIs)

B.   A trust relationship between a user and a service provider

C.   A Distinguished Name and an associated public key, with the entire certificate being signed by a trusted third party

D.   XML

12.   Certificate-based authentication uses which of the following to establish proof of identity? (Select all that apply.)

A.   SAML elements

B.   Public key cryptography

C.   XML

D.   Trust relationships with third parties

13.   Your firm has a requirement to protect against man-in-the-middle attacks on SSL connections. The easiest method of doing this would be through the use of which of the following? (Select the best single answer.)

A.   Digital certificate-based authentication

B.   SAML

C.   Mutual authentication

D.   SSL/TLS handshake

14.   Examples of SSO include which of the following? (Select all that apply.)

A.   Kerberos

B.   OpenID systems

C.   SOAP

D.   WSDL

15.   A user requests authentication from an Identity Provider (IdP), which becomes an asserting party across a trust relationship to a Service Provider (SP), which then can use the asserted credentials in making an access control decision for the user. This describes which standard?

A.   SPML

B.   XACML

C.   SSO

D.   SAML

16.   OASIS is a standards group responsible for which standards? (Select all that apply.)

A.   SAML

B.   XACML

C.   SOAP

D.   SPML

17.   Which method uses a separate federated identity management system to broker resource access between service providers and identity providers?

A.   Active Directory

B.   Kerberos

C.   SOAP

D.   WAYF

18.   XML is used in which standards? (Select all that apply.)

A.   SAML

B.   SSO

C.   SMTP

D.   XACML

19.   Which of the following IEEE protocols provides port-based authentication for Wi-Fi and wired networks?

A.   802.1x

B.   802.11

C.   SPML

D.   LDAP

20.   What is the correct correlation between the OpenID and OAuth standards?

A.   OpenID and OAuth both handle authentication.

B.   OpenID handles authentication, and OAuth handles authorization.

C.   OpenID handles authorization, and OAuth handles authentication.

D.   OpenID and OAuth both handle authorization.

Answers

1.   B. XACML stands for eXtensible Access Control Markup Language. It is a declarative access control policy language implemented in XML and a processing model that describes how to interpret the policies.

2.   C. Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains.

3.   D. Certificate-based authentication is the most secure authentication scheme. A certificate-based authentication scheme uses public key cryptography and a digital certificate to authenticate a user.

4.   B. XACML consists of a hierarchy of policysets containing policies composed of rules.

5.   A, D. Single sign-on can reduce help desk costs through reduced password reset requests, and it improves the end-user experience because of the reduced number of passwords to remember.

6.   C. SPML permits the sharing of user, resource, and service provisioning information between a group of organizations. It enables organizations to quickly set up user interfaces for web services in an automated manner.

7.   D. SAML is defined in terms of assertions, protocols, bindings, and profiles.

8.   A. SAML 2.0 integrates Liberty Alliance Identity Federation Framework elements.

9.   B, C. Advantages of SAML-based authentication include a platform-neutral, improved user experience; strong commercial and open source support; and reduced costs.

10.   A. Attestation is the act of certifying some element to be true and doing so in some fashion that provides a form of evidence as to its veracity.

11.   A, C. Certificate-based authentication is based on public key cryptography and uses PKI to connect public keys to owners. It is composed of elements such as a Distinguished Name and an associated public key, with the entire certificate being signed by a trusted third party.

12.   B, D. Public key cryptography, backed by the trust relationship associated with certificate chains, establishes the proof of identity in certificate-based authentication systems.

13.   C. Mutual authentication provides a level of security against man-in-the-middle attacks during the handshake process.

14.   A, B. Kerberos is an enterprise-level SSO. OpenID is an open standard that defines the use of third parties as authentication systems and can be used to build an SSO. An example is when users employ Facebook to log in to other applications.

15.   D. Identity Providers (IdPs) and Service Providers (SPs) are elements of SAML.

16.   A, B, D. OASIS is responsible for SAML, SPML, and XACML, as well as other standards.

17.   D. Where Are You From (WAYF) is a centralized SSO implementation frequently used by university federations to anchor resource access between federated partners. Unlike some SSO methods, WAYF acts as a proxy between federated identity providers and service providers.

18.   A, D. SAML and XACML are both constructed using XML.

19.   A. 802.1x provides port-based authentication for Wi-Fi and wired networks.

20.   B. OpenID provides authentication services, whereas OAuth provides authorization services.