1 00:00:06,460 --> 00:00:08,923 - Now, let's talk about federated users. 2 00:00:09,960 --> 00:00:14,110 Earlier, we talked about creating users 3 00:00:14,110 --> 00:00:17,360 within the identity and access management service, 4 00:00:17,360 --> 00:00:20,880 and for small teams, that works really well. 5 00:00:20,880 --> 00:00:23,950 But, for larger teams when you're in especially 6 00:00:23,950 --> 00:00:27,410 an enterprise that has perhaps hundreds 7 00:00:27,410 --> 00:00:32,410 or maybe even thousands of users that already exist 8 00:00:32,470 --> 00:00:35,370 that also need access to AWS, 9 00:00:35,370 --> 00:00:39,110 then we want to ideally leverage our existing directories. 10 00:00:39,110 --> 00:00:42,413 There are plenty of existing directories available. 11 00:00:43,440 --> 00:00:47,560 A lot of organizations already use things like LDAP 12 00:00:47,560 --> 00:00:51,220 or Microsoft Active Directory or some other type 13 00:00:51,220 --> 00:00:56,220 of directory, and we want to enable the ability 14 00:00:57,040 --> 00:00:59,480 to essentially reuse those accounts. 15 00:00:59,480 --> 00:01:02,840 We don't want to have to duplicate those accounts 16 00:01:02,840 --> 00:01:05,190 between an on-premise directory 17 00:01:05,190 --> 00:01:08,320 and within the identity and access management service 18 00:01:08,320 --> 00:01:10,090 because there's a lot of issues with that. 19 00:01:10,090 --> 00:01:12,330 One, it's kind of a pain to do. 20 00:01:12,330 --> 00:01:15,540 And two, if they leave the company, we have to remember 21 00:01:15,540 --> 00:01:17,590 to remove them from two places, 22 00:01:17,590 --> 00:01:22,080 and so by leveraging a federation, we can leverage 23 00:01:22,080 --> 00:01:25,970 that existing user base that we already have. 24 00:01:25,970 --> 00:01:27,330 Of course, the same thing applies 25 00:01:27,330 --> 00:01:30,250 to web and mobile application users. 26 00:01:30,250 --> 00:01:34,130 We have users out there that want to authenticate 27 00:01:34,130 --> 00:01:37,310 against our web or mobile application, 28 00:01:37,310 --> 00:01:39,750 but we don't want to necessarily force them 29 00:01:39,750 --> 00:01:42,340 to go through the process of account creation. 30 00:01:42,340 --> 00:01:44,210 They already have an account somewhere, 31 00:01:44,210 --> 00:01:46,550 and we can leverage that existing account 32 00:01:46,550 --> 00:01:50,460 by allowing them to log in with Facebook, 33 00:01:50,460 --> 00:01:53,960 log in with Google or Twitter 34 00:01:53,960 --> 00:01:57,360 or basically any other OpenID provider. 35 00:01:57,360 --> 00:02:00,250 And so in terms of federation, we have a lot of options 36 00:02:00,250 --> 00:02:01,990 that are available to us. 37 00:02:01,990 --> 00:02:06,990 First, we have the SAML, and SAML 2.0 allows us 38 00:02:07,670 --> 00:02:11,830 to grant access to the AWS Management Console. 39 00:02:11,830 --> 00:02:16,020 It allows us to gain access to temporary access keys 40 00:02:16,020 --> 00:02:20,595 that can be used to configure the CLI and other API access. 41 00:02:20,595 --> 00:02:25,500 With SAML, the nice benefit of SAML is that we can enable 42 00:02:25,500 --> 00:02:29,830 this kind of federation with no coding whatsoever. 43 00:02:29,830 --> 00:02:32,940 We simply configure our on-premises directories 44 00:02:33,940 --> 00:02:37,810 and the AWS Identity and Access Management Service 45 00:02:37,810 --> 00:02:40,710 to communicate to one another using SAML, 46 00:02:40,710 --> 00:02:44,560 and when our enterprise users authenticate 47 00:02:44,560 --> 00:02:46,980 against that on-premises directory, 48 00:02:46,980 --> 00:02:50,940 through the communication of SAML, they're able to retrieve 49 00:02:50,940 --> 00:02:54,327 those temporary credentials that they can use to access AWS. 50 00:02:55,620 --> 00:02:59,710 We also have the AWS Directory Service. 51 00:02:59,710 --> 00:03:03,400 This allows AWS Management Console access 52 00:03:03,400 --> 00:03:07,820 by allowing the user, the on-premises user, 53 00:03:07,820 --> 00:03:10,250 to authenticate against Active Directory using 54 00:03:10,250 --> 00:03:13,303 their Active Directory username and password. 55 00:03:14,510 --> 00:03:19,510 We also have Cognito, Amazon Cognito gives us 56 00:03:20,480 --> 00:03:24,390 a programmatic access to the API that allows our web 57 00:03:24,390 --> 00:03:28,660 and mobile applications to create user pools. 58 00:03:28,660 --> 00:03:31,490 We create a user pool within Cognito 59 00:03:31,490 --> 00:03:35,290 and using OpenID Connect, such as log in with Facebook 60 00:03:35,290 --> 00:03:39,080 or Twitter or so on, our web and mobile application users 61 00:03:39,080 --> 00:03:42,450 can authenticate against that existing account, 62 00:03:42,450 --> 00:03:44,530 and that can be correlated and stored 63 00:03:44,530 --> 00:03:48,580 within a Cognito User Identity Pool, and from there, 64 00:03:48,580 --> 00:03:52,690 we can use that to grant temporary credentials 65 00:03:52,690 --> 00:03:56,400 that can be used to communicate with other Amazon services. 66 00:03:56,400 --> 00:04:01,400 So through authenticating with Cognito, 67 00:04:01,670 --> 00:04:04,920 we can create a system that allows our web 68 00:04:04,920 --> 00:04:07,380 or mobile applications to communicate 69 00:04:07,380 --> 00:04:09,860 with Amazon services directly, 70 00:04:09,860 --> 00:04:13,093 and we'll see some examples of that later on. 71 00:04:14,130 --> 00:04:16,880 The last option that I wanna talk about here 72 00:04:16,880 --> 00:04:19,560 would be the AWS Single Sign-On. 73 00:04:19,560 --> 00:04:24,560 Single Sign-On gives us access to multiple AWS accounts 74 00:04:24,600 --> 00:04:26,680 and business applications. 75 00:04:26,680 --> 00:04:30,090 We've talked about earlier how it's common 76 00:04:30,090 --> 00:04:35,090 for organizations to leverage multiple accounts 77 00:04:36,400 --> 00:04:38,450 for their different environments, right? 78 00:04:38,450 --> 00:04:40,500 You may have an account for production, 79 00:04:40,500 --> 00:04:41,850 an account for development, 80 00:04:41,850 --> 00:04:44,100 or account for different business units, 81 00:04:44,100 --> 00:04:46,500 and so that's a very powerful pattern in order to 82 00:04:46,500 --> 00:04:49,600 create isolation between different types of resources, 83 00:04:49,600 --> 00:04:53,680 and AWS Single Sign-On allows you 84 00:04:53,680 --> 00:04:57,490 to essentially create one place for users to authenticate 85 00:04:57,490 --> 00:05:00,373 and gain access into multiple accounts. 86 00:05:01,220 --> 00:05:03,630 So, keep that in mind when you, for those of us 87 00:05:03,630 --> 00:05:06,710 who are a part of larger organizations, 88 00:05:06,710 --> 00:05:11,560 for teams that may have hundreds or even thousands of users 89 00:05:11,560 --> 00:05:15,423 that already exist, keep these federation options in mind.