Set up Google IDP

1. Authenticate as admin. Register a new Identity Provider using the Google template (provide dummy client id and secret, is active: true, is public: true). After the registration, save the IDP hash which should be similar to: cblfhdje2cekov09vjpp.

2. As a Google developer go to the Google console to register a new OAuth client (application type: web application).

   

3. Add authorized redirect URIs using the following syntax: LOGIN_PAGE_URL/federation/callback?client_name=IDP_HASH

   Example

   https://login.example.cloudentity.com/federation/callback?client_name=jkh406jkd4l2n1m11m27.

4. Copy the client ID and secret and select Save.

   

5. Go back to the CIP admin page and update the Google IDP by providing the client ID and secret from Google developer console. Log out.

Verify your setup

1. Go to the login page and select the Google IDP icon.

   

2. Authenticate with Google account when prompted.

   

   

3. Once authenticated, you are redirected to the user self service.

   

Mapping and provisioning

There are two kinds of mapping available in IDP configuration in CIP.

customMapping - defines which Google IDP attributes should be mapped to CIP attributes while provisioning users, as shown in the sample below.

"customMapping": {
    "sub": [
      "uid"
    ],
    "given_name": [
      "firstName"
    ],
    "family_name": [
      "lastName"
    ],
    "email": [
      "emails"
    ]
}

CIP federation-service requests the following scopes: openid, profile, email when authorizing to Google IDP. A sample id_token payload is presented below.

{
  "azp": "1052752793169-vl42l884dc0d4478b97hbf8ipo6ntr0n.apps.googleusercontent.com",
  "aud": "1052752793169-vl42l884dc0d4478b97hbf8ipo6ntr0n.apps.googleusercontent.com",
  "sub": "115568505788082945315",
  "email": "john.doe.test@email.com",
  "email_verified": true,
  "at_hash": "ZLAOiBmI0jxq8Pr4dn2z6A",
  "exp": 1518431954,
  "iss": "https://accounts.google.com",
  "iat": 1518428354,
  "name": "John Doe",
  "picture": "https://lh4.googleusercontent.com/-bUf-m7VbYNk/AAAAAAAAAAI/AAAAAAAAAAA/ACSILjVyAULbWY56_7D5tBr5X65qYxGhdw/s96-c/photo.jpg",
  "given_name": "John",
  "family_name": "Doe",
  "locale": "en-GB"
}

entitlementMapping - an optional mapping which allows to grant entitlements and entitlement groups to specific users. In the example below we’re mapping specific entitlements to a user identified by e-mail (in this case john.doe.test@email.com). Upon creation, the specified entitlements (TEST_ENTITLEMENT_1, TEST_ENTITLEMENT_2) and entitlementGroups (TEST_ENTITLEMENT_GROUP_1) are mapped to this user.

"entitlementMapping": {
    "emails": {
      "john.doe.test@email.com": {
        "entitlements": [
          "TEST_ENTITLEMENT_1",
          "TEST_ENTITLEMENT_2"
        ],
        "entitlementGroups": [
          "TEST_ENTITLEMENT_GROUP_1"
        ]
      }
    }
}

Additionally, while provisioning a new user in the SLA, you can find entitlements in the entitlements.newFederatedUser list in the application.conf file. These entitlements are granted to new users by default.

entitlements {
  newFederatedUser = ["SELF_GET_USER", "SELF_UPDATE_USER", "SELF_GET_CUSTOMER", "SELF_LIST_USER_CUSTOMERS"]
}

If you would like to use entitlementMapping, you can adapt the cURL below (replace IDP_UUID and ADMIN_SESSION_TOKEN accordingly).

curl 'DEPLOYMENT_URL/ui/sla/federation/idps/IDP_UUID' -X PUT -H 'Content-Type: application/json' -H 'Accept: application/json, text/plain, */*' -H 'Cookie: token=ADMIN_SESSION_TOKEN' --data-binary '{

"entitlementMapping": {
    "emails": {
      "john.doe.test@email.com": {
        "entitlements": [
          "TEST_ENTITLEMENT_1",
          "TEST_ENTITLEMENT_2"
        ]
      }
    }
  }
}'