Certificate management

Basic network connections are insecure – traffic between endpoints can be snooped or altered in transit, and neither end of a connection has any reason to believe anything about the other. The AAF makes extensive use of public key cryptography in the federation to address this and provide to the underpinning trust of the federation. Doing this typically requires some software, some configuration, and a number of pairs of keys and corresponding digital certificates.

Certificates and their uses

Certificates are used in a number of areas to perform various security related tasks. The type, duration and function of each certificate will vary from task to task as shown in the following table.


 Function
 Recommend Type   
 Duration
 Description
 Metadata Signing and Validation
 Certificate provided by AAF
 
The integrity of metadata files is crucial to the correct operation of Federation services, not least because they carry certificate information on which the security of the system depends. The AAF distribute their metadata with a digital signature. This is of no use unless it is actually verified, and doing this requires a copy of a certificate corresponding to the federation key used to create the signature. For more see: Validating Metadata.

 Browser to Identity Provider
 Certificate signed by a recognized and trusted certificate authority.

 The CA's root and intermediate certificate chains should be registered in most if not all common web browsers.
 1, 2 or 3 year dependent on your local site policy.
 This certificate protects your institute's log-in page ensuring that user's username and password are never sent across the Internet in clear text.

 Certificates applied to your web server infrastructure are NOT registered in the AAF Federation Registry.

 This is one of the requirements for Level of Assurance 2 and higher tokens and token and credential management assurance.

 

 Browser to Service Provider  
 Certificate signed by a recognized and trusted certificate authority.

 The CA's root and intermediate certificate chains should be registered in most if not all common web browsers.

 1, 2 or 3 year dependent on your local site policy.
 The AAF recommends that communication between the user's browser and the SP be secured. If it isn't then both initial authentication and subsequent session management are vulnerable to interception and misuse by third parties.


 SP and IdP 'protocol endpoints'
 Certificate signed by a recognized and trusted certificate authority.
 1, 2 or 3 year dependent on your local site policy.
 The AAF requires that at least the special URLs used internally by the SP and IdP software (the so-called 'protocol endpoints', typically with URL paths starting /Shibboleth.sso/.. and /idp/profile/...) be SSL protected and this therefore makes SSL support mandatory for such SPs and IdPs.



 Attribute Authority authentication
 Self signed certificate with a key length of 2048 bits    
10 or more years
 Used on the Attribute Authority end point which is generally severed on port 8443.

 See Identity Providers Certificates for details on managing this certificate.

 Trust fabric provide through
    * Signatures
    * Encryption
 Self signed certificate with a key length of 2048 bits.

 Recommend using the same certificate as the Attribute Authority authentication certificate.
 10 or more years
 The AAF provides a trust fabric that allows for message integrity protection and message confidentiality protections. The trust fabric is delivered from end to end via the AAF signed metadata that is populated with the signature and encryption certificates all participating identity providers and service providers.

 The keys and certificates used here need to be integrated into federation software as well as the AAF Metadata. The creation and management of these keys and certificates is somewhat different to standard web certificates. Detailed information on the management of these keys and certificates is available for;