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