Este contenido no está disponible en el idioma seleccionado.
Chapter 1. Overview of General Security Concepts
Before digging into how JBoss EAP 6 handles security, it is important to understand a few basic security concepts.
1.1. Authentication
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.
1.2. Authorization
Authorization refers to a way of specifying access rights or defining access policies. A system can then implement a mechanism to utilize those policies to permit or deny access to resources for the requestor. In many cases, this is implemented by matching a principal with a set of actions or places they are or are not allowed to access, sometimes referred to as a role.
1.3. Authentication and Authorization in Practice
Though Authentication and Authorization are distinct concepts, they are very often linked. Many modules written to handle authentication also handle authorization and vice-versa.
Example
The application MyPersonalSoapbox provides the ability to post and view messages. Principals with the Talk role are allowed to post messages and view other posted messages. Users who have not logged in have the Listen role and are allowed to view posted messages. Suzy, Adam, and Bob use the application. Suzy and Bob can authenticate with their username and password, but Adam does not have a username and password yet. Suzy has the Talk role, but Bob has no roles (neither Talk nor Listen). When Suzy authenticates, she may post and view messages. When Adam uses MyPersonalSoapbox, he cannot log in, but he can still see posted messages. When Bob logs in, he cannot post any messages nor can he view any other posted messages.
Suzy is both authenticated and authorized. Adam has not authenticated, but he is authorized (with the Listen role) to view messages. Bob is authenticated, but has no authorization (no roles).
1.4. Encryption
Encryption refers to encoding sensitive information by applying mathematical algorithms to it. Data is secured by converting (or encrypting) it to an encoded format. In order to read the data again, the encoded format must be converted back (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:
- LUKS can be used to encrypt Linux filesystem disks.
- The blowfish or AES algorithms can be used to encrypt data stored in Postgres databases.
- The HTTPS protocol encrypts all data via SSL/TLS before transferring it from one party to another.
- When a users 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
Secure Sockets Layer (SSL)/Transport Layer Security(TLS) encrypts network traffic between two systems. This occurs by using a symmetric key which is exchanged between and only known by those two systems. To ensure a secure exchange of the symmetric key, SSL/TLS makes use of Public Key Infrastructure (PKI), a method of encryption that utilizes 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, and 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 takes place 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 then validates the certificate and makes a decision about whether the certificate is trusted or not. 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 decrypts the symmetric key, using its private key, and further communication between the two machines over this connection is encrypted using the symmetric key.
There are two basic kinds of certificates: Self-Signed Certificates and Authority-Signed Certificates. A self-signed certificate uses its own private key to sign itself, and that signature is unverified (not connected to any chain of trust). An authority-signed certificate is a certificate that is issued to a party by a certificate authority and is signed by that certificate authority (e.g. Verisign, CAcert, RSA and many others). The certificate authority is essentially verifying the authenticity of the holder of the certificate.
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 since no third party has confirmed their authenticity. This inherently makes the less secure. Authority-signed certificates can take more effort to setup initially, but are far easier for clients to verify their authenticity (i.e. a chain of trust has been created since a third party has confirmed the authenticity of the holder of the certificate).
1.6. Single Sign On (SSO)
Single Sign On (SSO) allows principals authenticated to one resource to implicitly authorize access to other resources. If a set of distinct resources are 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 both web applications as well as on desktop applications. In some cases, an single 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
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 Indentity and Access Management (IAM) is sometimes used to describe this same concept.
Identity Provider
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.
Identity Store
An identity provider needs an identity store to retrieve users' information. This information will be used during the authentication and authorization process. Identity stores can be any type of repository: a database, LDAP, properties file, etc.
Service Provider
A service provider 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. In addition, there is no resiliency in the event of a host failure. In a clustered SSO scenario, data can be shared between applications in multiple virtual hosts, and is therefore resilient to failover. In addition, clustered SSO is able to receive requests from a load balancer.
1.6.1. Third-Party SSO Implementations
Kerberos
Kerberos is a network authentication protocol for client/server applications. It allows authentication across a non-secure network in a secure way, using secret-key symmetric cryptography.
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 running on a server on their network. After obtaining the ticket, users request a Service Ticket (ST) from an Authentication Service (AS), which is another service running on the same network. Users then use the ST to authenticate to the desired service. The TGS and the AS both 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 already 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 Active Directory, and is also used in many Red Hat Enterprise Linux environments.
SPNEGO
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 a service ticket from the Kerberos Key Distribution Center (KDC). After the ticket is obtained, the application wraps it 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. Upon successful authentication, access is granted.
SPNEGO works with all types of Kerberos providers, including the Kerberos service included in Red Hat Enterprise Linux and the Kerberos server which is an integral part of Microsoft Active Directory.
Microsoft Active Directory
Microsoft Active Directory (AD) is a directory service developed by Microsoft to authenticate users and computers in a Microsoft Windows domain. It is included as part of Microsoft Windows Server. The computer running Microsoft 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 which work together:
- Lightweight Directory Access Protocol (LDAP), for storing information about users, computers, passwords, and other resources.
- Kerberos, for providing secure authentication over the network.
- Domain Name Service (DNS) for providing mappings between IP addresses and host names of computers and other devices on the network.
1.6.2. Claims-Based Identity
One way of implementing SSO is by using a claims-based identity system. A claims-based identity system allows systems to pass around identity information, but abstracts that information into two components: a claim and an issuer (or authority). A claim is statement that one subject (e.g. user, group, application, organization) makes about another. That claim (or set of claims) is then 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 (STS)
A Security Token Service (STS) is an authentication service that issues security tokens to clients for use in authenticating and authorizing users for secured applications (web services or EJBs). A client attempting to authenticate against an application (service provider) secured with STS will be redirect to a centralized STS authenticate and issued a token. If successful, that client will reattempt to access the service provider, providing their token in 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 WS-Trust.
Browser-Based SSO
In browser-based SSO, one or more web applications, known as service providers, are connected to a centralized identity provider in a hub and spoke architecture. The identity provider (IDP) acts as the central source (hub) for identity and role information by issuing claim statements (via SAML) to service providers (spokes). Requests may be issued when a user attempts to access a service provider or if a user attempt 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.
SAML
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 a STS or IDP and can be used to enable SSO. A resource secured by SAML (SAML service provider) will redirect 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
Desktop-Based SSO enables service providers and desktop domains (e.g. Active Directory or Kerberos) to share a principal. In practice, this allows users to login on their computer using their domain credentials and then have service providers re-use that principal during authentication (without having to re-authenticate), thus providing SSO.
1.7. LDAP
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 Lightweight Directory Access Protocol (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, organization unit, among others. 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, Microsoft Active Directory, IBM Tivoli Directory Server, Oracle Internet Directory, 389 Directory Server, and others.
