Google no longer supports OpenID protocol for login. Instead, Google now supports OAuth2. This means, it was no longer possible to authenticate for Portal logins via Goolge. Now the Application server ships a new TAI which allows to authenticate with Google. You can configure this TAI so that a Portal login with Google authentication is possible.
- Upgrade Application Server to the latest fixpack 22.214.171.124. Please see this link for more information: http://www-01.ibm.com/support/docview.wss?uid=swg24040035
- In addition, a fix is required to add Google support to RelyingParty TAI in Application server. Currently this fix is not officially available. This fix is still in development.
Required configuration steps
Configuration is required in both Google and Application server
- Register RelyingParty TAI as an OAuth client in Google OpenID Connect Provider
- Access Google’s developers console, https://console.developers.google.com
- Create new project, and enter your project name.
- Open your Google project, go to “APIs & auth”, then “Credentials”
- Go to “Create new Client ID”, and you may need create “Consent Form” if you have not created one before.
- Write down both “CLIENT ID” and “CLIENT SECRET”. These values are required in the RelyingParty TAI custom properties
- Edit “REDIRECT URIS” to add Liberty profile’s redirect URL. In example, I used both http and https protocol with the corresponding ports configured for Portal:
8. Save your Google project and configuration, and your Google setup is completed.
2. Application server
1. In Application Server, enable the RelyingParty TAI as documented at this link: http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/tsec_oidconfigure.html?cp=SSEQTP_8.5.5%2F1-8-2-31-2-6
2. Add following custom properties to the RelyingParty TAI via the Application Server admin console. To do this access admin console and select Security -> Global security -> Web and SIP security -> Trust association -> Interceptors -> com.ibm.ws.security.oidc.client.RelyingParty
name="provider_1.scope" value="openid email profile"
name="provider_1.rpScope" value="openid email profile"
Save the custom properties
3. Add "accounts.google.com" as trusted realm in the user repository
4.1 In the admin console select Security -> Global Security
4.2 Under "User account repository" select "Configure..."
4.3 Select "Trusted authentication realms - inbound" -> "Add External Realm..."
4.3 Add "accounts.google.com"
4.4 Save your changes
4. Import SSL certificate from Google
4.1 In the admin console select Security -> SSL certificate and key management ->Key stores and certificates -> NodeDefaultTrustStore -> Signer certificates -> Retreive from port
4.2 Enter following properties
4.3 Select "Retrieve signer information", then "Apply" and save your changes
5. Restart the server
Logging into Portal via Google account
In order to access Portal via an Google account, a user with the ID of your Google account has to exist in your user repository. This is a current limitation until "transient users" are supported with this configuration.
This means, before a user can log into portal, you have to manually create a user in your user repository with the ID of your Google account. For example, if your Google account is firstname.lastname@example.org, you have to create a user with ID "email@example.com" in your user repository (either via the Portal UI, or directly via the Application server admin console).
This means, currently a successful login to portal is only possible if the corresponding user is a existing user in the user repository.
In the example above, the RelyingParty TAI was configured to interact, if the URI contains "goolgeAuth". In order to log in to portal, you now have to open a browser and issue an URL to a protected portal page containing "googleAuth". For example "http://localhost:10039/wps/myportal/googleAuth".
This will invoke the TAI which redirects to Google for authentication. After successful authentication with Google, you will get redirected to portal and can access protected portal resources.
The URL to activate the TAI could get generated by a custom login portlet. E.g. the portlet displays a button "Google" which issues URL "http://localhost:10039/wps/myportal/googleAuth" in order to call the TAI. This is similar to the setup for the SAML configuration.
A custom JAAS login module can get plugged in order to modify the user DN so that transient user support is possible. For example, the JAAS login module can change the DN of the Google user to "o=transparent". If portal is configured for transient users, this would allow to log in with users that are not available in the user registry for Portal.