Federated Trusts
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
15 hours 43 minutes
Difficulty
Advanced
Video Transcription
00:00
>> In our last section,
00:00
we talked about Kerberos.
00:00
We talked about how Kerberos gives us
00:00
single sign-on in our domains.
00:00
But the issue is that we'd like to take
00:00
that single sign-on and expand beyond our domains.
00:00
In order to do so,
00:00
we're going to have to create what we
00:00
refer to as federated trusts.
00:00
In this section we're going to talk
00:00
about taking a single sign-on that
00:00
we might perform in
00:00
our local domain and extending that out
00:00
to Software-as-a-Service providers or
00:00
other provider networks like perhaps business partners.
00:00
We'll talk about how we provide
00:00
that authentication to expand beyond domains.
00:00
We'll look at specifically some of
00:00
the protocols and languages that are necessary.
00:00
We'll talk about SPML,
00:00
SCIM, SAML, OpenID Connect,
00:00
and OAuth, and how those work across federated trusts.
00:00
Here we go back to talking about
00:00
>> identity management but
00:00
>> also access management since we really
00:00
could read identity and access management.
00:00
We start with making sure that we have
00:00
a streamline process to
00:00
handle the provisioning of user accounts.
00:00
I want to make sure that I have
00:00
a means to automatically create
00:00
user accounts based on an employee being
00:00
hired and that employee coming
00:00
>> on board with the company.
00:00
>> We want to streamline that process so that
00:00
HR doesn't have to input that information,
00:00
and then IT, and then perhaps to have to set
00:00
that information up with
00:00
Cloud service providers and so on.
00:00
Then I need a means of
00:00
authentication that can span
00:00
domains and that's where SAML,
00:00
OpenID Connect come in.
00:00
Then I'd like to be able to authorize,
00:00
>> in many instances,
00:00
>> authorize even applications to
00:00
perform certain activities on the network on my behalf.
00:00
That's where OAuth comes in.
00:00
Let's just start off with provisioning accounts.
00:00
Our environment is going to
00:00
be one in which we have a single sign-on directory.
00:00
That very well could be Active Directory.
00:00
It could be some other specific format.
00:00
Whatever it is where we store our user accounts.
00:00
Originally, the HR person is going to take
00:00
all our information and enter that into HR software.
00:00
We want to create a connection between
00:00
the HR software and our
00:00
single sign-on directory, like Active Directory.
00:00
We want to pull what's been entered in one system,
00:00
into a repository in another system.
00:00
Right now we're just focusing on the circle
00:00
>> on the left.
00:00
>> SCIM and SPML are
00:00
two languages that are designed to facilitate this.
00:00
Ultimately, when we talk about SPML or SCIM,
00:00
this is the communications means that would
00:00
allow these two directories
00:00
of user accounts to communicate,
00:00
so that as an account is created with the HR software,
00:00
that significant information can be pulled into
00:00
our LDAP or Directory environment
00:00
so that we don't have to have
00:00
IT in on the same information that's
00:00
just been added in HR.
00:00
When a user gets added to
00:00
the HR database, they get hired,
00:00
that automatically allows the provisioning
00:00
of a user account in Active Directory.
00:00
Then also if that user were to
00:00
be terminated within the company,
00:00
then that would also automatically
00:00
generate the de-provisioning of the user account.
00:00
That way that orchestrates the process of
00:00
on-boarding and off boarding
00:00
>> as far as user accounts go.
00:00
>> That's really helpful.
00:00
The next thing is,
00:00
I want to access services throughout the web.
00:00
I want to access Salesforce and QuickBooks
00:00
>> and I want to
00:00
>> access Webex and all
00:00
these other Software-as-Service applications.
00:00
We're left with the problem of traditionally,
00:00
what our users would have to do is to create
00:00
accounts at each one of those service providers.
00:00
For instance, if you want an account with Office 365,
00:00
you would create an account on
00:00
the Office 365 database server
00:00
with all your personal information.
00:00
That would be stored at the Office 365 server and
00:00
every single time you would want to access Office 365,
00:00
you are sending your username and
00:00
password across the Internet.
00:00
Not very secure.
00:00
Or if I want to access Salesforce,
00:00
I would send my user authentication information
00:00
again back and forth across the Internet,
00:00
and Salesforce too would have
00:00
to house my account information.
00:00
Now, honestly, Office 365 and Salesforce,
00:00
they don't want my information
00:00
>> because if they store it,
00:00
>> they have to protect it.
00:00
They just want an assurance that the person that's
00:00
accessing their software has paid for it really.
00:00
They don't care about all my personal details.
00:00
They just want to know did they get a check from me?
00:00
Right now the problem is that
00:00
the users would be responsible for creating
00:00
all these passwords for
00:00
all these resources out on the Internet.
00:00
I may have different passwords to keep
00:00
up with and we all know what that's like.
00:00
If you think about all the user accounts
00:00
you have on the Internet and
00:00
how many passwords and
00:00
how many times you forget those passwords.
00:00
What if when a user account
00:00
was provisioned on Active Directory,
00:00
we could use SCIM and an alternative to SCIM is SPML.
00:00
Either one of those would work.
00:00
We would use that to pull over
00:00
the accounts to
00:00
a publicly accessible identity provider server.
00:00
Now that identity provider would work
00:00
like Active Directory in the previous example,
00:00
but we would never open Active Directory up to
00:00
external entities like Office 365 or Salesforce.
00:00
If we can just punch a hole in our firewall and let
00:00
all those service providers
00:00
just verify from Active Directory,
00:00
that would solve the problem,
00:00
except we would have a huge security vulnerability.
00:00
Instead, we set up in a DMZ an entity provider server.
00:00
That usually could be running LDAP.
00:00
It's usually running x-dot 500,
00:00
which is a more elaborate and more sophisticated form
00:00
of LDAP and it's there to
00:00
store directory information on my users.
00:00
When an account gets populated to Active Directory,
00:00
that information is automatically pulled to
00:00
the identity provider in my DMZ.
00:00
Rather than Office 365, and Salesforce,
00:00
and Webex having individual account databases
00:00
with my account in them,
00:00
now this is where we start thinking
00:00
about being in more of a network environment.
00:00
My network administrator,
00:00
can set up federated trusts
00:00
with these service providers,
00:00
so that they can get that authentication and
00:00
that verification from the identity provider,
00:00
instead of me having to send passwords and
00:00
usernames across the web
00:00
every time I want to access a resource.
00:00
Let's look at this just a little bit more in depth,
00:00
because we have another language,
00:00
SAML, which is Security Association Markup Language.
00:00
That's going to make that even easier for us.
00:00
It's all about ease of use and administration.
00:00
>> The way this would look is,
00:00
first thing in the morning,
00:00
I come in and I'm going to log in
00:00
>> to the company portal.
00:00
>> My name is Kelly H, my password sunshine.
00:00
Now, if I enter my information correctly,
00:00
then I get a dashboard.
00:00
My administrators already configured this.
00:00
Ultimately, in this illustration,
00:00
you can see this is managed
00:00
>> by a company called OneLogin.
00:00
>> There lots of different companies that do this.
00:00
This is essentially set up by my identity provider.
00:00
Ping is another one,
00:00
there lots of identity providers out there.
00:00
At any rate, my username and password is
00:00
getting authenticated in this instance by OneLogin,
00:00
and as long as the authentication is correct,
00:00
I get a dashboard.
00:00
All these icons represent
00:00
organizations that we've created
00:00
>> a federated trust with,
00:00
>> which means my domain authentication
00:00
will suffice for accessing these resources.
00:00
Meaning, as I log on through this portal,
00:00
I'm granted access to these resources.
00:00
The way that works is,
00:00
I decide I want to access Salesforce.
00:00
Now, Salesforce determines
00:00
that I've already logged in with OneLogin.
00:00
Salesforce sends a SAML requests
00:00
to OneLogin that basically says,
00:00
is Kelly Handley legitimate?
00:00
Has she logged in? Does she really have an account?
00:00
OneLogin goes back and says,
00:00
yeah, we'll vouch for her.
00:00
OneLogin sends back a SAML token
00:00
and that token is digitally signed so that
00:00
the Salesforce in this instance
00:00
can be guaranteed that it hasn't been
00:00
modified and that it truly comes from
00:00
the organization that's trusted, OneLogin.
00:00
Then what happens,
00:00
that SAML token is verified by Salesforce.
00:00
If you'll look at
00:00
the end result at the bottom right corner,
00:00
there is a person who is
00:00
delighted to be accessing Salesforce.
00:00
Look at that heart, look at the joy on their face.
00:00
All of this process has culminated
00:00
in single sign-on to access Salesforce.
00:00
Now of course, the beauty of this is,
00:00
now I want to access Box or Office 365.
00:00
I don't have to log in again.
00:00
I go back to my portal,
00:00
I click on Box,
00:00
and the remainder of that process,
00:00
the last three steps,
00:00
where the request is sent
00:00
to OneLogin for a SAML response,
00:00
sends back the SAML token and I'm allowed access.
00:00
Rather than having to have user accounts on
00:00
all these companies that I'm
00:00
going to access through the web,
00:00
we set up an identity provider,
00:00
which in this case, like I said, it's OneLogin.
00:00
OneLogin sets up
00:00
federated trusting relationships on our behalf,
00:00
based on our configuration
00:00
with their network administrator,
00:00
the various applications on the web we want to access.
00:00
Rather than usernames and
00:00
passwords going across the network,
00:00
we have SAML tokens which are
00:00
protected and don't contain sensitive information.
00:00
This makes things much smoother.
00:00
Now, I'm also going to mention,
00:00
SAML has been around for a while and still around,
00:00
absolutely but it's relatively
00:00
slow based on a lot of the new technology that we have,
00:00
so OpenID Connect is
00:00
an alternative to SAML that
00:00
works almost exactly the same way.
00:00
Instead of SAML tokens,
00:00
they have OpenID Connect tokens.
00:00
I'll also mention that whereas with SAML,
00:00
we refer to OneLogin,
00:00
in this case is the identity provider
00:00
and we call Salesforce the service provider.
00:00
Of course, OpenID Connect
00:00
is going to have different lingo.
00:00
Instead of the identity provider,
00:00
it's called the OpenID identity provider
00:00
but what they really change is,
00:00
Salesforce in the other applications are referred to
00:00
as RPs, relying parties.
00:00
Little bit of different lingo,
00:00
but this idea of logging in
00:00
once to a portal and having federated
00:00
trust between our identity provider and
00:00
our service providers so that once
00:00
>> I provide credentials,
00:00
>> that identity provider can
00:00
issue SAML tokens or distribute
00:00
SAML tokens on my behalf to prove that
00:00
I'm legitimate and to prove that I've authenticated.
00:00
Now, this is just a little more generic path
00:00
of how SAML works.
00:00
This might be something that you want to
00:00
get a screenshot of.
00:00
It just gives you a little bit more detail
00:00
than I have on the screen before.
00:00
I'll also mention the last
00:00
of these issues when we talk about single sign-on,
00:00
I wanted to mention OAuth.
00:00
OAuth is actually a part of OpenID Connect.
00:00
OAuth is a framework.
00:00
It's not a language, it's not a protocol,
00:00
is just a framework on which we build applications.
00:00
What it's going to allow us to do,
00:00
is delegate certain activities to applications.
00:00
For instance, let's say you have a Facebook account.
00:00
You should be the only entity
00:00
that can update your Facebook account.
00:00
But let's say you go in and
00:00
>> you're listening to Spotify,
00:00
>> and you get a message from Spotify that says,
00:00
"Would you like us to update
00:00
your Facebook page so
00:00
your friends know what music you're listening to?"
00:00
Now, if you click Yes,
00:00
Spotify is going to update Facebook on your behalf.
00:00
That's because of the OAuth framework
00:00
that allows these delegation of activities.
00:00
I was working on my taxes,
00:00
I hate taxes but they go to good use so, whatever.
00:00
But anyway, I was
00:00
working on QuickBooks to manage my taxes,
00:00
and it used to be that I'd have to
00:00
go out to each of my accounts,
00:00
write down my expenses,
00:00
manually enter them into QuickBooks.
00:00
But now, I can authorize QuickBooks to do
00:00
a transfer and bring in
00:00
information from each of my accounts.
00:00
That's not typical to allow
00:00
an application to query my bank to
00:00
find out all my expenses but
00:00
that's what the OAuth framework allows.
00:00
Really, what we're seeing is we're seeing
00:00
a very different environment now.
00:00
The web applications and
00:00
web services are becoming
00:00
so much a part of everyday life.
00:00
We want to make sure that we can have
00:00
single-sign-on across our domains,
00:00
whether they're with business partners or with
00:00
their companies that we're
00:00
leasing or using services from.
00:00
Then the account provisioning piece is
00:00
done through SPML and SCIM.
Up Next
Instructed By
Similar Content
