Chapter 1. Overview of General Security Concepts
Before digging into how JBoss EAP handles security, it is important to understand a few basic security concepts.
Authentication refers to identifying a subject and verifying the authenticity of the identification. The most common authentication mechanism is a username and password combination, but other mechanisms, such as shared keys, smart cards or fingerprints, are also used for authentication. When in the context of Java Enterprise Edition declarative security, the result of a successful authentication is called a principal.
Encryption refers to encoding sensitive information by applying mathematical algorithms to it. Data is secured by converting, or encrypting, it to an encoded format. To read the data again, the encoded format must be converted, or decrypted, to the original format. Encryption can be applied to simple string data in files or databases or even on data sent across communications streams.
Examples of encryption include the following scenarios.
- LUKS can be used to encrypt Linux file system disks.
- The blowfish or AES algorithms can be used to encrypt data stored in Postgres databases.
- The HTTPS protocol encrypts all data via Secure Sockets Layer/Transport Layer Security, SSL/TLS, before transferring it from one party to another.
- When a user connects from one server to another using the Secure Shell, SSH protocol, all of the communication is sent in an encrypted tunnel.
1.5. SSL/TLS and Certificates
SSL/TLS encrypts network traffic between two systems by using a symmetric key that is exchanged between and only known by those two systems. To ensure a secure exchange of the symmetric key, SSL/TLS uses Public Key Infrastructure (PKI), a method of encryption that uses a key pair. A key pair consists of two separate but matching cryptographic keys: a public key and a private key. The public key is shared with any party and is used to encrypt data; the private key is kept secret and is used to decrypt data that has been encrypted using the public key.
When a client requests a secure connection to exchange symmetric keys, a handshake phase occurs before secure communication can begin. During the SSL/TLS handshake, the server passes its public key to the client in the form of a certificate. The certificate contains the identity of the server, its URL, the public key of the server, and a digital signature that validates the certificate. The client validates the certificate and decides whether the certificate is trusted. If the certificate is trusted, the client generates the symmetric key for the SSL/TLS connection, encrypts it using the public key of the server, and sends it back to the server. The server uses its private key to decrypt the symmetric key. Further communication between the two machines over this connection is encrypted using the symmetric key.
There are two kinds of certificates: self-signed certificates and authority-signed certificates. A self-signed certificate uses its private key to sign itself; that signature is unverified because it is not connected to a chain of trust. An authority-signed certificate is a certificate that is issued to a party by a certificate authority, CA, and is signed by that CA, for example, VeriSign, CAcert, RSA, et al. The CA verifies the authenticity of the certificate holder.
Self-signed certificates can be faster and easier to generate and require less infrastructure to manage, but they can be difficult for clients to verify their authenticity because a third party has not confirmed their authenticity. This inherently makes the self-signed certificate less secure. Authority-signed certificates can take more effort to set up, but they are easier for clients to verify their authenticity. A chain of trust has been created because a third party has confirmed the authenticity of the certificate holder.
Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages.
1.6. Single Sign-On
Single sign-on (SSO) allows principals authenticated to one resource to implicitly authorize access to other resources. If a set of distinct resources is secured by SSO, a user is only required to authenticate the first time they access any of the secured resources. Upon successful authentication, the roles associated with the user are stored and used for authorization of all other associated resources. This allows the user to access any additional authorized resources without re-authenticating.
If the user logs out of a resource or a resource invalidates the session programmatically, all persisted authorization data is removed and the process starts over. In the case of a resource session timeout, the SSO session is not invalidated if there are other valid resource sessions associated with that user. SSO may be used for authentication and authorization on web applications and desktop applications. In some cases, an SSO implementation can integrate with both.
Within SSO, there are a few common terms used to describe different concepts and parts of the system.
Identity Management (IDM) refers to the idea of managing principals and their associated authentication, authorization, and privileges across one or more systems or domains. The term Identity and Access Management (IAM) is sometimes used to describe this same concept.
An identity provider (IDP) is the authoritative entity responsible for authenticating an end user and asserting the identity for that user in a trusted fashion to trusted partners.
An identity provider needs an identity store to retrieve users' information to use during the authentication and authorization process. Identity stores can be any type of repository: a database, Lightweight Directory Access Protocol (LDAP), properties file, and so on.
A service provider (SP) relies on an identity provider to assert information about a user via an electronic user credential, leaving the service provider to manage access control and dissemination based on a trusted set of user credential assertions.
Clustered and Non-Clustered SSO
Non-clustered SSO limits the sharing of authorization information to applications on the same virtual host. There is also no resiliency in the event of a host failure. In a clustered SSO scenario, data can be shared between applications on multiple virtual hosts, which makes it resilient to failover. In addition, a clustered SSO is able to receive requests from a load balancer.
1.6.1. Third-Party SSO Implementations
Kerberos is a network authentication protocol for client-server applications. It uses secret-key symmetric cryptography to allow secure authentication across a non-secure network.
Kerberos uses security tokens called tickets. To use a secured service, users need to obtain a ticket from the ticket granting service (TGS) which is a service that runs on a server in their network. After obtaining the ticket, users request a Service Ticket (ST) from an authentication service (AS) which is another service running in the same network. Users then use the ST to authenticate to the desired service. The TGS and the AS run inside an enclosing service called the key distribution center (KDC).
Kerberos is designed to be used in a client-server desktop environment and is not usually used in web applications or thin client environments. However, many organizations use a Kerberos system for desktop authentication and prefer to reuse their existing system rather than create a second one for their web applications. Kerberos is an integral part of Microsoft’s Active Directory and is used in many Red Hat Enterprise Linux environments.
Simple and protected GSS_API negotiation mechanism(SPNEGO) provides a mechanism for extending a Kerberos-based SSO environment for use in web applications.
When an application on a client computer, such as a web browser, attempts to access a protected page on a web server, the server responds that authorization is required. The application then requests an ST from the KDC. The application wraps the ticket in a request formatted for SPNEGO and sends it back to the web application via the browser. The web container running the deployed web application unpacks the request and authenticates the ticket. Access is granted upon successful authentication.
SPNEGO works with all types of Kerberos providers, including the Kerberos service within Red Hat Enterprise Linux and the Kerberos server, which is an integral part of Microsoft’s Active Directory.
Microsoft’s Active Directory
Active Directory (AD) is a directory service developed by Microsoft to authenticate users and computers in a Microsoft Windows domain. It comes as part of Windows Server. The computer running Windows Server controlling the domain is referred to as the domain controller. Red Hat Enterprise Linux can integrate with Active Directory domains as can Red Hat Identity Management, Red Hat JBoss Enterprise Application Platform, and other Red Hat products.
Active Directory relies on three core technologies that work together:
- LDAP to store information about users, computers, passwords, and other resources
- Kerberos to provide secure authentication over the network
- Domain name service (DNS) to provide mappings between IP addresses and host names of computers and other devices in the network
1.6.2. Claims-Based Identity
One way to implement SSO is to use a claims-based identity system. A claims-based identity system allows systems to pass identity information but abstracts that information into two components: a claim and an issuer or authority. A claim is statement that one subject, such as a user, group, application, or organization, makes about another. That claim or set of claims is packaged into a token or set of tokens and issued by a provider. Claims-based identity allows individual secured resources to implement SSO without having to know everything about a user.
Security Token Service
A security token service (STS) is an authentication service that issues security tokens to clients for use when authenticating and authorizing users for secured applications, web services or EJBs. A client attempting to authenticate against an application secured with STS, known as a service provider, will be redirected to a centralized STS authenticator and issued a token. If successful, that client will reattempt to access the service provider, providing their token along with the original request. That service provider will validate the token from the client with the STS and proceed accordingly. This same token may be reused by the client against other web services or EJBs that are connected to the STS. The concept of a centralized STS that can issue, cancel, renew, and validate security tokens and specifies the format of security token request and response messages is known as
In browser-based SSO, one or more web applications, known as service providers, connect to a centralized identity provider in a hub and spoke architecture. The IDP acts as the central source, or hub, for identity and role information by issuing claim statements in SAML tokens to service providers, or spokes. Requests may be issued when a user attempts to access a service provider or if a user attempts to authenticate directly with the identity provider. These are known as SP-initiated and IDP-initiated flows, respectively, and will both issue the same claim statements.
Security Assertion Markup Language (SAML) is a data format that allows two parties, usually an identity provider and a service provider, to exchange authentication and authorization information. A SAML token is a type of token issued by an STS or IDP; it can be used to enable SSO. A resource secured by SAML, SAML service provider, redirects users to the SAML identity provider, a type of STS or IDP, to obtain a valid SAML token before authenticating and authorizing that user.
Desktop-based SSO enables service providers and desktop domains, for example Active Directory or Kerberos, to share a principal. In practice, this allows users to log in on their computer using their domain credentials and then have service providers reuse that principal during authentication, without having to re-authenticate, thus providing SSO.
Lightweight Directory Access Protocol (LDAP) is a protocol for storing and distributing directory information across a network. This directory information includes information about users, hardware devices, access roles and restrictions, and other information.
In LDAP, the distinguished name (DN), uniquely identifies an object in a directory. Each distinguished name must have a unique name and location from all other objects, which is achieved using a number of attribute-value pairs (AVPs). The AVPs define information such as common names and organization unit. The combination of these values results in a unique string required by the LDAP.
Some common implementations of LDAP include Red Hat Directory Server, OpenLDAP, Active Directory, IBM Tivoli Directory Server, Oracle Internet Directory, and 389 Directory Server.