1 1 00:00:00,480 --> 00:00:01,860 Federation. 2 2 00:00:01,860 --> 00:00:02,850 In this lesson, 3 3 00:00:02,850 --> 00:00:05,850 we are going to talk about an identity federation. 4 4 00:00:05,850 --> 00:00:07,650 Now, a federation is a process 5 5 00:00:07,650 --> 00:00:09,690 that provides a shared login capability 6 6 00:00:09,690 --> 00:00:12,360 across multiple systems and enterprises. 7 7 00:00:12,360 --> 00:00:15,240 For example, if you wanted to log into one website 8 8 00:00:15,240 --> 00:00:17,490 but you start using your Google sign-in to do it, 9 9 00:00:17,490 --> 00:00:19,860 that's actually part of the federation. 10 10 00:00:19,860 --> 00:00:21,720 Now, a federation allows the company 11 11 00:00:21,720 --> 00:00:23,460 to trust accounts created and managed 12 12 00:00:23,460 --> 00:00:24,930 by a different network. 13 13 00:00:24,930 --> 00:00:26,730 For instance, on one of my older websites, 14 14 00:00:26,730 --> 00:00:28,890 we used to allow LinkedIn log-ons 15 15 00:00:28,890 --> 00:00:32,610 or Facebook log-ons or Google log-ons to get into our site. 16 16 00:00:32,610 --> 00:00:34,530 And that meant we had a trust relationship. 17 17 00:00:34,530 --> 00:00:37,140 If they said you were authorized, we would allow you in 18 18 00:00:37,140 --> 00:00:38,910 because that's the way our website was set up. 19 19 00:00:38,910 --> 00:00:40,410 It was a trust relationship. 20 20 00:00:40,410 --> 00:00:42,180 And these trust relationships are set up 21 21 00:00:42,180 --> 00:00:43,800 between two different networks. 22 22 00:00:43,800 --> 00:00:45,390 The identity provider, in this case, 23 23 00:00:45,390 --> 00:00:47,520 it would be Facebook or LinkedIn or Google. 24 24 00:00:47,520 --> 00:00:50,490 And the service provider, which was me, it was my website. 25 25 00:00:50,490 --> 00:00:52,830 And so that's a way that these things work. 26 26 00:00:52,830 --> 00:00:55,650 Now, as you look at this, this is what we're going to see. 27 27 00:00:55,650 --> 00:00:57,570 You have this trust boundary that goes 28 28 00:00:57,570 --> 00:00:59,280 beyond your organization now. 29 29 00:00:59,280 --> 00:01:01,860 Now the RP here is going to be your relying party 30 30 00:01:01,860 --> 00:01:02,910 or your service provider. 31 31 00:01:02,910 --> 00:01:05,340 So think about that as my website. 32 32 00:01:05,340 --> 00:01:07,890 Now, if you wanted to be able to sign into my website 33 33 00:01:07,890 --> 00:01:09,375 using your Google login, first, 34 34 00:01:09,375 --> 00:01:11,880 I'm going to make a request, a discovery request 35 35 00:01:11,880 --> 00:01:14,820 over to the ID provider on the right, which is Google. 36 36 00:01:14,820 --> 00:01:15,750 They're going to look at that 37 37 00:01:15,750 --> 00:01:17,490 and they're going to validate your credentials. 38 38 00:01:17,490 --> 00:01:19,740 You're going to send it back to my website and say, hey, 39 39 00:01:19,740 --> 00:01:21,210 I have verified John Smith. 40 40 00:01:21,210 --> 00:01:22,500 Let him into your website. 41 41 00:01:22,500 --> 00:01:25,590 Then I'm going to check what attributes they say he has. 42 42 00:01:25,590 --> 00:01:27,240 That's the registrar attributes. 43 43 00:01:27,240 --> 00:01:28,260 And then they send me back 44 44 00:01:28,260 --> 00:01:29,460 whether they were approved or not. 45 45 00:01:29,460 --> 00:01:32,820 And now I say, okay, John Smith was approved by Google. 46 46 00:01:32,820 --> 00:01:34,050 He does have a matching account 47 47 00:01:34,050 --> 00:01:36,090 on my system that has these courses 48 48 00:01:36,090 --> 00:01:38,520 so I'm going to let 'em in and let 'em see those courses. 49 49 00:01:38,520 --> 00:01:39,540 That's the way this works. 50 50 00:01:39,540 --> 00:01:42,780 So I never really do the authentication of that person. 51 51 00:01:42,780 --> 00:01:45,420 I let that all be done by the ID provider, 52 52 00:01:45,420 --> 00:01:48,030 which in this case is Google or Facebook or LinkedIn 53 53 00:01:48,030 --> 00:01:51,270 or whatever third-party SSO you want to be able to use. 54 54 00:01:51,270 --> 00:01:53,370 Now, that's the idea of how these things work. 55 55 00:01:53,370 --> 00:01:55,740 Now, I know this sounds a lot like single sign-on 56 56 00:01:55,740 --> 00:01:58,380 and I even just said single sign-on when I mentioned Google 57 57 00:01:58,380 --> 00:01:59,490 or LinkedIn or Facebook 58 58 00:01:59,490 --> 00:02:01,830 and people often use those terms interchangeably, 59 59 00:02:01,830 --> 00:02:03,600 like I just did there by mistake. 60 60 00:02:03,600 --> 00:02:05,040 They're not the same thing. 61 61 00:02:05,040 --> 00:02:06,570 When you're dealing with single sign-on, 62 62 00:02:06,570 --> 00:02:07,980 you have a cryptographic hash 63 63 00:02:07,980 --> 00:02:10,680 of the credentials being passed between the two systems. 64 64 00:02:10,680 --> 00:02:12,150 That's the way we share it when we're dealing 65 65 00:02:12,150 --> 00:02:13,410 with single sign-on. 66 66 00:02:13,410 --> 00:02:16,320 So I still have to do the ID verification 67 67 00:02:16,320 --> 00:02:18,930 as the service provider inside a single sign-on. 68 68 00:02:18,930 --> 00:02:21,600 But when you're part of a federation, the sign-on 69 69 00:02:21,600 --> 00:02:24,960 is actually provided as a service by the identity provider. 70 70 00:02:24,960 --> 00:02:27,900 And so I'm never actually verifying that person myself. 71 71 00:02:27,900 --> 00:02:31,680 I do all of that trust through that third-party ID provider. 72 72 00:02:31,680 --> 00:02:34,080 And so that's why this is a dangerous thing that you have 73 73 00:02:34,080 --> 00:02:36,480 to think about when you're setting up your federations. 74 74 00:02:36,480 --> 00:02:38,310 Now, setting it up with something like Google 75 75 00:02:38,310 --> 00:02:40,620 or Facebook is not that big of a deal. 76 76 00:02:40,620 --> 00:02:42,510 In fact, usually you'll configure it, not so much 77 77 00:02:42,510 --> 00:02:45,750 as a trust relationship, but more as a single sign-on type 78 78 00:02:45,750 --> 00:02:48,390 of relationship using them as an ID provider. 79 79 00:02:48,390 --> 00:02:50,850 But if you're going to do this with another company, 80 80 00:02:50,850 --> 00:02:52,440 for instance, my training company 81 81 00:02:52,440 --> 00:02:54,030 and another training company, 82 82 00:02:54,030 --> 00:02:55,650 I'm taking all the risk by creating 83 83 00:02:55,650 --> 00:02:57,150 that trust relationship between us. 84 84 00:02:57,150 --> 00:02:59,520 And that is something an attacker could take advantage of. 85 85 00:02:59,520 --> 00:03:00,353 So you want to keep that 86 86 00:03:00,353 --> 00:03:02,940 in mind if your organization's thinking about doing it. 87 87 00:03:02,940 --> 00:03:04,380 Now, some other problems you have to think about 88 88 00:03:04,380 --> 00:03:05,610 when you start dealing with federations 89 89 00:03:05,610 --> 00:03:08,430 is how are you're going to provision and deprovision accounts? 90 90 00:03:08,430 --> 00:03:10,020 Now, when I talk about provisioning, 91 91 00:03:10,020 --> 00:03:11,310 this is creating an account 92 92 00:03:11,310 --> 00:03:14,100 and giving the user authorization to a particular role, 93 93 00:03:14,100 --> 00:03:16,290 an application or file share. 94 94 00:03:16,290 --> 00:03:18,660 Now, when I make changes to a user account, 95 95 00:03:18,660 --> 00:03:21,450 those changes have to get back to that ID provider. 96 96 00:03:21,450 --> 00:03:23,640 So we need to make sure that we quickly propagate that 97 97 00:03:23,640 --> 00:03:27,060 between the ID provider and the service provider. 98 98 00:03:27,060 --> 00:03:28,800 So if they make a change to their user account 99 99 00:03:28,800 --> 00:03:31,170 and change their username or their password or some 100 100 00:03:31,170 --> 00:03:33,540 of their attributes, we need to know that pretty quickly. 101 101 00:03:33,540 --> 00:03:35,460 And so you have to make sure there's this propagation 102 102 00:03:35,460 --> 00:03:37,110 that happens between the two. 103 103 00:03:37,110 --> 00:03:39,090 Now, you can manually provision an account 104 104 00:03:39,090 --> 00:03:40,980 and this occurs when an account is being configured 105 105 00:03:40,980 --> 00:03:43,770 by an administrator on the service provider site. 106 106 00:03:43,770 --> 00:03:46,440 So when you come to my site and you buy something, 107 107 00:03:46,440 --> 00:03:49,290 we actually don't use manual provision most of the time 108 108 00:03:49,290 --> 00:03:50,940 but if something goes wrong, 109 109 00:03:50,940 --> 00:03:52,710 my team can log into our website 110 110 00:03:52,710 --> 00:03:54,360 and create an account for you manually. 111 111 00:03:54,360 --> 00:03:57,180 It's more time intensive, it's more prone to risk 112 112 00:03:57,180 --> 00:03:58,440 but we have that ability. 113 113 00:03:58,440 --> 00:04:01,110 That's where one of our administrators logs onto our site 114 114 00:04:01,110 --> 00:04:02,520 and creates that account. 115 115 00:04:02,520 --> 00:04:04,590 Now, automatic provisioning, on the other hand, 116 116 00:04:04,590 --> 00:04:05,790 is when users are enrolled 117 117 00:04:05,790 --> 00:04:08,160 with a service provider without intervention. 118 118 00:04:08,160 --> 00:04:11,010 So if you go over to my website and you buy a product, 119 119 00:04:11,010 --> 00:04:12,007 for instance, a course, 120 120 00:04:12,007 --> 00:04:14,100 you're going to end up buying that course. 121 121 00:04:14,100 --> 00:04:15,510 And if it's the first course you bought with us, 122 122 00:04:15,510 --> 00:04:17,340 we will automatically create an account for you, 123 123 00:04:17,340 --> 00:04:19,440 send you an email with your username and log on 124 124 00:04:19,440 --> 00:04:21,360 and then you can log in and use your account. 125 125 00:04:21,360 --> 00:04:23,670 No human will ever touch that in that process. 126 126 00:04:23,670 --> 00:04:25,320 But if something goes wrong, 127 127 00:04:25,320 --> 00:04:27,270 then we go back to manual provisioning. 128 128 00:04:27,270 --> 00:04:29,220 Now, when you reset your password, 129 129 00:04:29,220 --> 00:04:31,170 who are you resetting your password with? 130 130 00:04:31,170 --> 00:04:33,000 Well, if you're using a federation, 131 131 00:04:33,000 --> 00:04:35,580 you're going to be doing that with the ID provider, right? 132 132 00:04:35,580 --> 00:04:38,370 Because the ID provider is the one who's handling all 133 133 00:04:38,370 --> 00:04:39,990 of those password resets. 134 134 00:04:39,990 --> 00:04:41,100 So this is one of the reasons 135 135 00:04:41,100 --> 00:04:43,410 why we didn't like using federation 136 136 00:04:43,410 --> 00:04:45,060 for our users and passwords. 137 137 00:04:45,060 --> 00:04:46,650 The reason was we didn't have any control 138 138 00:04:46,650 --> 00:04:47,970 over helping our students. 139 139 00:04:47,970 --> 00:04:49,710 When they said, "Hey, I lost my password." 140 140 00:04:49,710 --> 00:04:50,700 We couldn't reset it for you 141 141 00:04:50,700 --> 00:04:52,530 because we don't have access to that. 142 142 00:04:52,530 --> 00:04:55,260 That was done by the federated provider, in this case, 143 143 00:04:55,260 --> 00:04:56,730 Google or LinkedIn or Facebook. 144 144 00:04:56,730 --> 00:04:59,340 And so it was more complex for us to support that system. 145 145 00:04:59,340 --> 00:05:01,470 So in our new versions of our website, 146 146 00:05:01,470 --> 00:05:02,400 we don't support that, 147 147 00:05:02,400 --> 00:05:04,320 at least currently as of this recording. 148 148 00:05:04,320 --> 00:05:07,140 Instead, we rely on regular username and passwords 149 149 00:05:07,140 --> 00:05:09,600 because we have the ability to reset those for you 150 150 00:05:09,600 --> 00:05:12,420 or you can reset 'em yourself using your challenge questions 151 151 00:05:12,420 --> 00:05:14,100 or using reset links using 152 152 00:05:14,100 --> 00:05:15,963 that two-step verification process.