Google Apps offers the Single Sign-On (SSO) service to customers using Google Apps for Business, Education, or ISPs. We have a SAML-based SSO API that you can use to integrate into your LDAP, or other SSO system. LDAP (Lightweight Directory Access Protocol) is a networking protocol for querying and modifying directory services running over TCP/IP.
SSO accepts public keys and certificates generated with either the RSA or DSA algorithm. To use the service, you need to generate the set of public and private keys and an X.509 certificate that contains the public key. Once you have a public key or certificate, you would then need to register it with Google. You can do this by simply uploading the key or certificate via your Google Admin console.
How do I upload keys and certificates with my Google Admin console?
How do I generate keys and certificates for the Google Apps Single Sign-On service?
The way you generate keys and certificates often depends on your development platform and programming language preference. You can use OpenSSL, Certificate Creation tool and Pvk2pfx tool in .NET, Keytool in Java, and Java Cryptography Architecture for creating public and private key pairs. More information
How does the verification certificate work?
The certificate file will be an X.509 formatted certificate with an embedded public key. The public key can use either the DSA or RSA algorithms. Google uses this key to verify the origination (i.e. Did the SSO assertion come from you?) and integrity (i.e. Was the assertion modified during transmission?) of the SAML response you send to us.
It is important to match the embedded public key in the X.509 certificate with the private key you use to sign the SAML Response.
While we don't currently support a best practice for admins without existing certificates, X509 certificates generation can be accomplished using the openssl command. More information
How does the 'Issuer' (i.e., the entity ID) element in the SAML request work?
The issuer is included in the SAML request to the IdP (Identity Provider). You can choose whether to included a standard or domain specific issuer. When multiple domains are using SSO with the same IdP aggregator, a specific issuer can be parsed by the IdP aggregator to identify the correct domain name for the SAML request. If you don't check the box to enable a domain specific issuer, Google will send the standard issuer (google.com) in the SAML request. If you check the box to enable this feature, Google will send an issuer specific to your domain (google.com/a/your_domain.com), where 'your_domain.com' is replaced with your actual domain name.
How do network masks work?
Network masks are IP addresses represented using Classless Inter-Domain Routing (CIDR) notation. The CIDR is a specification of how many bits of the IP address should be included. Google uses network masks to determine which IPs or ranges of IPs to present with the SSO feature.
It is important for each network mask to use the correct format. Here is an IPv6 example:
2001:db8::/32 (where the slash and the number after it represent the CIDR)
In this example, the last 96 bits would not be taken into consideration, and all of the IPs in that network range would be affected.
Here is an IPv4 example:
In this example, the last 8 bits (i.e. the zero) would not be taken into consideration, and all of the IPs that were in the range of 64.233.187.0 - 64.233.187.255 would be affected.
I have a question that is not covered above.
You can visit the Single Sign-On FAQs to find answers to common questions or read Single Sign-On articles. Alternatively, there are a number of commercial products and system integrators that provide SSO products and professional services. Please search the Professional Services in our Google Apps Marketplace for Google Enterprise Partners and other third parties that provide SSO assistance.
Read Troubleshooting Single Sign-On to resolve common issues encountered when integrating Google Apps with SSO.
Apps Documentation & Support
