You are looking at documentation for an older release. Not what you want? See the current release documentation.
In this section, you will set up a SAML2 scenario with eXo Platform as IDP and Google Apps as SP.
The integration between eXo Platform and Google Apps requires user synchronization. The premise is username in eXo Platform that matches nick in Google. For example, if your domain is example.com and your Google Apps account is john@example.com, your eXo Platform username should be john.
Export a certificate file using your own keystore, as described in Generating and using your own keystore. The command to export:
keytool -export -keystore secure-keystore.jks -alias secure-key -file test-certificate.crt
Note that if you are using default jbid_test_keystore.jks
(for testing only),
the keystore password is store123.
As the result, a file named test-certificate.crt
will be created. You will use it in next step.
Go to Google Apps Single Sign-On settings page by accessing your Admin console, then clicking → → (UI may be changed by Google). Complete this page as follows:
Upload the test-certificate.crt
file that is exported previously.
Enter http://www.idp.com:8080/portal/dologin to Sign-in, Sign-out and Change password URLs.
Check the box Setup SSO with third party identity provider.
The checkbox Use a domain specific issuer is optional. If it is checked, the SP host is signed as google.com/a/${your_domain} (google.com/a/test.com for example), otherwise it is simply google.com. Configurations at IDP side will change according to this, as you will see later.
Be careful when you are setting up Single Sign-On in your Google Apps. Make sure your settings are correct before you save.
Configurations at eXo Platform
Configure eXo Platform as described in eXo Platform as SAML2 IDP. Notice some values in $PLATFORM_IDP/standalone/configuration/gatein/exo.properties
as follows:
gatein.sso.sp.domains=google.com
gatein.sso.sp.host=www.google.com
Modify the $PLATFORM_IDP/standalone/configuration/gatein/saml2/picketlink-idp.xml
to add the following configurations:
For SP domains:
<Trust>
<Domains>${gatein.sso.sp.domains},google.com</Domains>
</Trust>
For SP hosts, the host is google.com or google.com/a/${your_domain}, depending on your Google Apps settings, as explained before:
<KeyProvider ...>
<ValidatingAlias Key="${gatein.sso.sp.host}" Value="secure-key"/>
<ValidatingAlias Key="google.com" Value="secure-key"/>
<!--<ValidatingAlias Key="google.com/a/test.com" Value="secure-key"/>-->
</KeyProvider>
"secure-key
" is the alias in your command to create the keystore file, or use "servercert
" if you use the default keystore.
Continue to add MetaDataProvider element as follows:
<PicketLinkIDP ...>
...
<MetaDataProvider ClassName="org.picketlink.identity.federation.core.saml.md.providers.FileBasedEntitiesMetadataProvider">
<Option Key="FileName" Value="/WEB-INF/conf/sso/saml/sp-metadata.xml"/>
</MetaDataProvider>
</PicketLinkIDP>
Create a file named WEB-INF/conf/sso/saml/sp-metadata.xml
inside
$PLATFORM_IDP/standalone/deployments/platform.ear/exo.portal.web.portal.war
with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntitiesDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:EntityDescriptor entityID="google.com" validUntil="2022-06-13T21:46:02.496Z">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" />
</md:EntityDescriptor>
</md:EntitiesDescriptor>
in which entityID
is either "google.com" or "google.com/a/${your_domain}" ("google.com/a/test.com" for example),
depending on your Google Apps settings as explained before. You can add many md:EntityDescriptor for many SP.
Testing the scenario
Be sure you have synchronized accounts. If not yet, create a username in eXo Platform that matches nick in Google Apps.
Logout eXo Platform and Google Apps, then access one of services of your Google Apps, for example: http://mail.google.com/a/${your_domain}. You will be redirected to the eXo Platform login page. Login using your synchronized username, after that you have your access to the Google service.
Note that said by Google, in SSO-enabled domains without network masks, the super administrator account will not be redirected to the SSO page (so that you can access Admin console in case there is something wrong with SSO settings). Refer to https://support.google.com/a/answer/60224?hl=en for more Google's instructions.