SSL, certificates and security with Shibboleth: Difference between revisions
No edit summary |
(Intro, and SP to IdP done) |
||
| Line 1: | Line 1: | ||
Basic network connections are insecure, in that the 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. Shibboleth makes extensive use of public key cryptography to address this where necessary. Doing this typically requires some software, some configuration, and one or more pairs of keys and corresponding digital certificates. Two different approaches are used: sometimes data is signed, which provides a strong assurance of its integrity and where it cam from; sometimes http traffic is layered over SSL (a.k.a. TLS for the purposes of this document) which protects it in transit allows at least the client, and optionally the client and the server, to positively identify the other end of the connection. | |||
Public key cryptography is used in for several different purposes, each of which may (but need not) use a different key pair: | |||
==SP to IdP communication== | ==Internal SP to IdP communication== | ||
Under Shibboleth the SPs and IdPs | Under Shibboleth, IdPs and SPs exchange information either directly via network connections established for the purpose or via messages passed through the user's browser using HTTP redirects. In the former case an SSL protected connection is used with both ends of the connection using their keys to authenticate to the other; in the latter case the sender provides a signature made with its private key which can be verified by the receiver using the sender's certificate. | ||
The software needed to do all this is included with the Internet2 Shibboleth implementation and the configuration appears in the shibboleth2.xml file. | |||
In each case, SPs and IdPs need some way to verify the certificate offered by the other. Certificates signed by 'Global' CAs can be used for this purpose and these are required by some federations (including the UK federation). An alternative is to use 'self signed' certificates and to include each entity's certificate in its metadata (which is needed for other reasons) and this is the currently preferred approach and supported by the Ucam federation. The standard install creates a key and self-signed certificate (in the same directory as shibboleth2.xml) called sp-key.pem and sp-cert.pem and configures shibboleth2.xml to use them. | |||
The Raven IdP's certificate is included in the federation metadata (UK or Ucam federations) that the SP is configured to download automatically. The SPs certificate is included in supplied to IdPs in the metadata it provides on registration. It is (mainly) the lack of a SP certificate that forces IdPs to describe an unregistered SP as an 'Unknown Service Provider' when asking people for permission to release information to it. | |||
==SP protocol endpoints== | ==SP protocol endpoints== | ||
Revision as of 13:55, 13 March 2009
Basic network connections are insecure, in that the 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. Shibboleth makes extensive use of public key cryptography to address this where necessary. Doing this typically requires some software, some configuration, and one or more pairs of keys and corresponding digital certificates. Two different approaches are used: sometimes data is signed, which provides a strong assurance of its integrity and where it cam from; sometimes http traffic is layered over SSL (a.k.a. TLS for the purposes of this document) which protects it in transit allows at least the client, and optionally the client and the server, to positively identify the other end of the connection.
Public key cryptography is used in for several different purposes, each of which may (but need not) use a different key pair:
Internal SP to IdP communication
Under Shibboleth, IdPs and SPs exchange information either directly via network connections established for the purpose or via messages passed through the user's browser using HTTP redirects. In the former case an SSL protected connection is used with both ends of the connection using their keys to authenticate to the other; in the latter case the sender provides a signature made with its private key which can be verified by the receiver using the sender's certificate.
The software needed to do all this is included with the Internet2 Shibboleth implementation and the configuration appears in the shibboleth2.xml file.
In each case, SPs and IdPs need some way to verify the certificate offered by the other. Certificates signed by 'Global' CAs can be used for this purpose and these are required by some federations (including the UK federation). An alternative is to use 'self signed' certificates and to include each entity's certificate in its metadata (which is needed for other reasons) and this is the currently preferred approach and supported by the Ucam federation. The standard install creates a key and self-signed certificate (in the same directory as shibboleth2.xml) called sp-key.pem and sp-cert.pem and configures shibboleth2.xml to use them.
The Raven IdP's certificate is included in the federation metadata (UK or Ucam federations) that the SP is configured to download automatically. The SPs certificate is included in supplied to IdPs in the metadata it provides on registration. It is (mainly) the lack of a SP certificate that forces IdPs to describe an unregistered SP as an 'Unknown Service Provider' when asking people for permission to release information to it.
SP protocol endpoints
General site traffic
https://spaces.internet2.edu/display/SHIB/KeysAndCertificates
