{"id":30820,"date":"2015-12-17T15:37:49","date_gmt":"2015-12-17T10:07:49","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=30820"},"modified":"2015-12-18T11:54:10","modified_gmt":"2015-12-18T06:24:10","slug":"cross-domain-sso-with-google-into-aws-console-using-saml","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/cross-domain-sso-with-google-into-aws-console-using-saml\/","title":{"rendered":"Cross-domain SSO with Google into AWS Console using SAML"},"content":{"rendered":"

Recently, I worked on a task wherein the users had to be authenticated based on existing Google credentials to get access of AWS Management<\/a> Console. It took more time than expected to make it work as the documentation provided by Google is not complete. Let\u2019s start by setting this up step by step.<\/p>\n

\"finl\"<\/p>\n

Scenario:<\/strong><\/h3>\n

Provide access of AWS Management console to already existing Google users. Let\u2019s say the users belong to “singhnavjot.com” domain.<\/p>\n

We will use SAML 2.0 protocol to pass information of Google user to Amazon’s AWS. Here, Google is our SAML Authority or Identity Provider and Amazon\u2019s AWS is SAML consumer or Service Provider.<\/p>\n

Let’s configure it to provide access to a user whose email id is \u201cnavjot@singhnavjot.com\u201d.<\/p>\n

    \n
  1. Login into the Google\u2019s admin console with the admin user. Once the below screen appears, click on \u201cApps\u201d:\"AdminConsole1\"<\/li>\n
  2. Click on \u201cSAML apps\u201d:
    \n\"appstab\"<\/li>\n
  3. Click on \u201cAdd a service\/App to your domain\u201d:
    \n\"1\"<\/li>\n
  4. Select \u201cAmazon Web Services\u201d from the list and click next:
    \n\"2\"<\/li>\n
  5. Download the “IDP metadata” file. We need to upload this file in AWS console while creating Identity provider. Click next:
    \n\"3\"<\/li>\n
  6. AWS Management console’s\u00a0settings<\/strong>: Login into AWS management console, go to IAM console and click \u201cIdentity Providers\u201d present on the left pane:
    \n\"AWS1\"<\/li>\n
  7. Click on \u201cCreate Provider\u201d and choose provider type as \u201cSAML\u201d from the drop down list:
    \n\"AWS2\"<\/li>\n
  8. Two fields will appear on the screen upon selecting \u201cSAML\u201d: \u201cProvider Name\u201d and \u201cMetadata Document\u201d:
    \nProvide any name in the \u201cProvider Name\u201d field (say GoogleApp).
    \nUpload the document downloaded in step 5 in the \u201cMetadata Document\u201d
    \n\"AWS3\"<\/li>\n
  9. Click \u201cNext Step\u201d present at the bottom right corner. Details verification page will appear. Save the \u201cProvider ARN\u201d as we will use it later. Save the Verify the information and click \u201cCreate\u201d present at the bottom right corner:
    \n\"AWS4\"<\/li>\n
  10. We have created the Identity provider successfully. Now, we need to a define access permission for this Identity provider. This can be done creating \u201cRole\u201d in AWS.<\/li>\n
  11. Go to \u201cRoles\u201d in IAM console and click \u201cCreate Role\u201d:
    \n\"AWS5\"<\/li>\n
  12. Provide any name to the role (say GoogleAppRole) and click \u201cNext Step\u201d at the bottom right corner:
    \n\"AWS6\"<\/li>\n
  13. Select \u201cRole for Identity Provider Access\u201d and then click \u201cSelect against \u201cGrant Web Single Sign-On (WebSSO) access to SAML providers\u201d:
    \n\"AWS7\"<\/li>\n
  14. Select \u201cSAML Provider\u201d which we have created in step 9 from the drop-down list and click \u201cNext Step\u201d:
    \n\"AWS8\"<\/li>\n
  15. \u201cPolicy Document\u201d will appear. Change it as per the requirement\u00a0otherwise, this would work for us. Click \u201cNext Step\u201d.<\/li>\n
  16. Select the policy from the list. We are selecting \u201cReadOnlyAccess\u201d to provide our users who will use google credentials to login into AWS console a read-only access. Click \u201cNext Step\u201d to move to the verification page. Save the \u201cRole ARN\u201d as we will use it later.<\/li>\n
  17. Click \u201cCreate Role\u201d at the bottom right corner.
    \nWe have completed our AWS configuration.<\/li>\n
  18. We will now move back to the Google Admin Console which we have left in step 5 where we have downloaded the IDP metadata. Click next.<\/li>\n
  19. Provide any name to your SAML application (say AWS) and any description in the description box. A logo can be uploaded. It is optional. Click next:
    \n\"4\"<\/li>\n
  20. Keep the ACS URL and Entity URL field intact. Keep the \u201cStart URL\u201d empty and \u201cSigned Response\u201d check box unchecked. In the \u201cName ID\u201d field, select \u201cBasic Information\u201d and \u201cPrimary email\u201d from the drop down list and click next:
    \n\"5\"<\/li>\n
  21. In next step, we have two fields: \u201chttps:\/\/aws.amazon.com\/SAML\/Attributes\/RoleSessionName\u201d and \u201chttps:\/\/aws.amazon.com\/SAML\/Attributes\/Role\u201d. Choose anything against the fields present against them as we have to update it later. Click finish:
    \n\"6\"<\/li>\n
  22. We have not told google about the role and Identity provider ARN that it will use. For this, we need to add a custom field using google SDK API and API explorer in the Google App which would take Role and Identity Provider ARN. Google App will use these details to communicate with AWS.<\/li>\n
  23. We will add one user into the app and provide it the access to use the AWS console using the provided AWS role.<\/li>\n
  24. First we need to get the customer id using directory.users.get API.<\/li>\n
  25. Go to API explorer and click on the “directory.users.get” API in API explorer and fill your email id in the field \u201cuserKey\u201d as shown below. Keep the other fields empty and click authorize and execute. Make sure we have admin permission:
    \n\"7\"<\/li>\n
  26. We will get 200 OK response with some information in the response. We can get \u201ccustomerId\u201d from the response.<\/li>\n
  27. Now, go to API \u201cdirectory.schemas.insert and fill the customerId against the \u201ccustomerId\u201d field. Add the request body as shown below and hit execute and we will get 200 OK response. We have added a custom schema in our google app so that app can interpret the information that we will provide in the next step:
    \n\"8\"
    \n\"9\"<\/li>\n
  28. Now, we are adding the AWS-related information in the fields using API directory.users.update.<\/li>\n
  29. Go to the API and fill your email id again \u201cuserKey\u201d filed and role ARN and identity provider ARN as shown below and hit execute which should return 200 OK response. We are adding user and specifying Provider and Role ARNs which we have saved while working on AWS console. So, for every user, we can use either same or different Provider and Role ARN. The ARN specified below are comma separated:
    \n\"10\"<\/li>\n
  30. Now, we have added new custom schema and populated the fields. If we have only a few users then these steps can be repeated for all users.<\/li>\n
  31. Now, go back to the google samSAMLl app and edit attribute mapping as follows and hit save: \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\"AWS10\"<\/li>\n
  32. Now, we need to enable this app for users as follows:<\/li>\n
  33. That’s all we need to do configure in the Google admin console.<\/li>\n
  34. We can launch the app from the highlighted icons present at the top right side of the screen:
    \n\"14\"<\/li>\n<\/ol>\n

    Upon launching the App we will be redirected to the AWS management console having ReadOnlyAccess. Similarly, different access permission can to granted to different users by assigning separate to the users.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Recently, I worked on a task wherein the users had to be authenticated based on existing Google credentials to get access of AWS Management Console. It took more time than expected to make it work as the documentation provided by Google is not complete. Let\u2019s start by setting this up step by step. Scenario: Provide […]<\/p>\n","protected":false},"author":154,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":14},"categories":[1],"tags":[1221,2847,248,2902,2903,2897,2898,2899,2900,2895,2896,2904,1338,2901],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/30820"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/154"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=30820"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/30820\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=30820"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=30820"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=30820"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}