Security in the Liberty Framework is layered. Liberty protocols are constructed with extensive security mechanisms. Furthermore they build upon various Internet protocols that themselves have embedded security mechanisms. Table 1 generally summarizes the security mechanisms incorporated in the Liberty specifications, and thus in Liberty enabled implementations, across two axis: channel security and message security. It also generally summarizes the security-oriented processing requirements placed on Liberty implementations.
Table 1. Liberty security mechanisms
Channel security addresses how communication between identity providers, service providers, and user agents is protected. Liberty implementations must use TLS1.0 or SSL3.0 for channel security, although other communication security protocols may also be employed (for example, IPSec) if their security characteristics are equivalent to TLS or SSL. Note: TLS, SSL, and equivalent protocols provide confidentiality and integrity protection to communications between parties as well as authentication.
Critical points of channel security include the following:
- In terms of authentication, service providers are required to authenticate identity providers using identity provider server-side certificates. Identity providers have the option to require authentication of service providers using service provider client-side certificates.
- The authenticated identity of an identity provider must be presented to a user before the user presents personal authentication data to that identity provider.
Message security addresses security mechanisms applied to the discrete Liberty protocol messages passed between identity providers, service providers, and user agents. These messages are exchanged across the communication channels whose security characteristics were just discussed.
Critical points of message security include the following:
- Liberty protocol messages and some of their components are generally required to be digitally signed and verified. Signing and verifying messages provide data integrity, data origin authentication, and a basis for nonrepudiation. Therefore, identity providers and service providers are required to use key pairs that are distinct from the key pairs applied for TLS and SSL channel protection and that are suitable for long-term signatures.
- In transactions between service providers and identity providers, requests are required to be protected against replay, and received responses are required to be checked for correct correspondence with issued requests. Time based assurance of freshness may be employed. These techniques provide transaction integrity.
To federate, providers are required to join communities of trust such as PKI or Kerberos frameworks, or to establish bilateral agreements. These should include obtaining X.509 credentials, establishing and managing trusted public keys, and managing life cycles of corresponding credentials.
Many of the security mechanisms mentioned above, for example, SSL and TLS, have dependencies upon, or interact with, other network services and/or facilities such as the DNS, time services, firewalls, etc. These latter services and/or facilities have their own security considerations upon which Liberty-enabled systems are thus dependent