Managing Identities in the Cloud
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
9 hours 59 minutes
Difficulty
Intermediate
CEU/CPE
10
Video Transcription
00:01
>> Let's go over managing identities in the Cloud and
00:01
start out by a planning the identity management,
00:01
then reviewing some of the federation patterns
00:01
that are used to free form in the hub and spoke,
00:01
and wrap up looking at
00:01
the process and architectural decisions
00:01
that you're going to
00:01
have to make as you adopt
00:01
federated identity management approach.
00:01
When you're planning identity management,
00:01
there's certain things that
00:01
the Cloud providers need to offer and
00:01
then the Cloud customers need to figure out themselves.
00:01
It starts with the Cloud providers offering
00:01
the identity service that supports
00:01
customers to use their own identities.
00:01
This could be an internal identity system.
00:01
Then on top of that,
00:01
the Cloud providers need to provide
00:01
a standards-based federation services.
00:01
This would be the SAML,
00:01
the OpenID OAuth combination
00:01
or some of the other ones that we
00:01
didn't touch on earlier.
00:01
This is a building block from
00:01
which you can tie into and integrate
00:01
with the Cloud provider using
00:01
the federated approach for identity.
00:01
On the flip side, the Cloud customers need to determine
00:01
how to manage the identities themselves.
00:01
How do they want to do it? Where do they
00:01
want the identities managed?
00:01
What will be the authoritative source for identities
00:01
associated with individuals and
00:01
their company or their organization?
00:01
Then they're going to have to decide on
00:01
the architectural models to
00:01
employ that will support
00:01
the situation that they're working with,
00:01
making it that balance of
00:01
security as well as ease to manage.
00:01
Finally, there's the technologies
00:01
that they want to support.
00:01
There are a variety.
00:01
We covered three earlier on
00:01
two options for authentication and
00:01
two options for authorization, and there's some others.
00:01
Then there are also a handful of
00:01
proprietary implementations that you'll
00:01
probably encounter with different Cloud providers.
00:01
You're going to have to draw the line and
00:01
determine what are the ones you want to support and
00:01
then what are the circumstances you're willing to support
00:01
the different technologies for federated services?
00:01
Keep in mind, federation is
00:01
enabling technology to support scaling.
00:01
This way the Cloud customers avoid having to create
00:01
different accounts in a variety
00:01
of different Cloud systems.
00:01
If you don't go this route,
00:01
you can easily lose control
00:01
of identity and access management.
00:01
It's very likely you will still have
00:01
a few non-federated identities with each Cloud provider.
00:01
In fact, these are local identities.
00:01
They serve as the administrator
00:01
of accounts for the initial setup,
00:01
as well as for troubleshooting problems
00:01
with the federated link.
00:01
In other words, these are the backdoor
00:01
when things aren't working for some reason,
00:01
you're going to use those local,
00:01
non-federated accounts with a Cloud provider.
00:01
Otherwise, you want to stick with
00:01
the federated accounts as much as
00:01
possible for as many individuals
00:01
and entities as possible.
00:01
The authoritative source is
00:01
the basis for your identity management.
00:01
It contains a combination of usernames,
00:01
passwords, group memberships, and so forth.
00:01
It will often be an internal directory server,
00:01
such as Microsoft Windows Active Directory.
00:01
Once you have that figured out,
00:01
there are two common architecture patterns
00:01
for connectivity between
00:01
the identity providers and
00:01
the service providers that rely on the identity provider.
00:01
We'll start at looking at the free form model
00:01
depicted here.
00:01
This approach has a few disadvantages
00:01
over the hub-and-spoke model,
00:01
which we will cover shortly.
00:01
For starters, your authoritative source needs to be
00:01
connected to all of the Cloud providers.
00:01
That implies some level of
00:01
direct exposure to the Internet.
00:01
In order to support users outside of your network,
00:01
you'll need to have a VPN link established so that
00:01
those Cloud users can
00:01
connect to the authentication source.
00:01
This means you're allowing them to
00:01
connect into your corporate network.
00:01
Finally, there's potential that you
00:01
have multiple authoritative servers.
00:01
For example, you may have multiple domain controllers,
00:01
you may have an HR system for individuals,
00:01
employee information, and then you
00:01
have another one that's managed for
00:01
just user operating system controls and authentication.
00:01
Each of these will need to connect to the providers.
00:01
As you can see on the diagram,
00:01
it gets very complex when you have this web of
00:01
multiple providers on one side,
00:01
identity providers on the top,
00:01
and then there's multiple service
00:01
providers on the bottom,
00:01
and each one needs to talk to each other.
00:01
You get a lot of lines, a lot of cross lines,
00:01
and it creates a lot of complexity.
00:01
To simplify things, we can look at
00:01
the hub-and-spoke pattern where
00:01
the identity providers sync to some centralized broker.
00:01
That broker is going to be Cloud-based and it acts as
00:01
the identity provider for
00:01
all the other service providers
00:01
that you're going to be integrating with.
00:01
The internal identity providers,
00:01
they become and start acting
00:01
as the authoritative sources.
00:01
The internal identity providers feed the identity broker,
00:01
and this avoids the disadvantages
00:01
that come with the free form.
00:01
But at the same time,
00:01
you do have a synchronization taking place.
00:01
There are inevitably some scenarios
00:01
you'll want to make sure and determine,
00:01
is this a one-way sync or a two-way?
00:01
One-way is going to be a lot simpler thing to manage
00:01
as far as reconciling any discrepancies.
00:01
If information about a particular user gets
00:01
changed in two places and you're doing a synchronization,
00:01
you need to have some rules in there.
00:01
How am I going to reconcile
00:01
this difference and resolve the conflict
00:01
between the discrepancy in
00:01
information between the different sources?
00:01
Who is going to be the authority
00:01
that is going to overrule the other?
00:01
If we look at the OpenID authentication example
00:01
that we explored in the prior video,
00:01
you can see all the players coming together.
00:01
Really this is a reflection of the hub-and-spoke model.
00:01
We had the authoritative source,
00:01
just a single source for simplicity,
00:01
sitting on the corporate network
00:01
that was synchronizing information,
00:01
a one-way street over to the identity provider.
00:01
In the real-world, probably not going to actually send
00:01
the password itself in clear text,
00:01
rather it will be some hash of the password.
00:01
It's going out to the identity provider and
00:01
that identity provider is residing in the Cloud,
00:01
then we have the relying party and there
00:01
are multiple different relying parties.
00:01
That's the reason I chose this image
00:01
with multiple servers so they could
00:01
represent many different SaaS providers and so forth.
00:01
There's a trust relationship between those two is
00:01
the relying party communicates
00:01
with the identity provider.
00:01
In this case, the identity provider is
00:01
also carrying the role of the identity broker.
00:01
Let's recap and expand on some of the questions you'll
00:01
need to ask yourself when scaling with federation,
00:01
as well as the architectural
00:01
decisions you're going to make.
00:01
You want to know how the identities, the applications,
00:01
devices, and other services are going to be managed.
00:01
So far, we've really only been providing
00:01
examples using individuals, but keep in mind,
00:01
all these concepts also
00:01
apply when we have identities for applications,
00:01
maybe there's service to service
00:01
communication and certain applications are
00:01
going to trust certain services
00:01
and provide information to certain services.
00:01
But there will be other services that aren't going to.
00:01
To be more concrete, let's say we have
00:01
an HR system and it is been
00:01
configured in such a way that it
00:01
will tell the payroll system,
00:01
here's the social security number for our employees.
00:01
However, there needs to
00:01
be a trust between the two and then
00:01
the two need to have some sort of
00:01
an identity when they're communicating.
00:01
At the same time, let's say somebody
00:01
compromises a different system.
00:01
Maybe it's the salesforce.com CRM system.
00:01
That system then makes
00:01
a connection to the HR system and says,
00:01
I want to get
00:01
the social security number for all these employees.
00:01
Well, at that point probably the authentication in
00:01
the first place isn't going to go because there's
00:01
really no reason that the two should be talking.
00:01
Then finally, of course,
00:01
authorization is going to
00:01
fail because it's going to say you
00:01
shouldn't have or need to access this information.
00:01
That's an example where we have entities.
00:01
These entities have identities,
00:01
but these aren't individuals, these aren't human beings.
00:01
The same mindset rings true for
00:01
devices as well as
00:01
other services that can be running internally.
00:01
You're going to want to also ask yourself,
00:01
how will identity provisioning change?
00:01
What is the formal process to
00:01
support new Cloud providers?
00:01
Both of these questions provide
00:01
a great opportunity to revisit
00:01
any existing processes that may be
00:01
inefficient or flat-out broken.
00:01
In fact, when you're defining the process
00:01
for supporting new Cloud providers,
00:01
there's a certain sequence of actions
00:01
you'll want to make sure happen and take
00:01
place consistently as you're
00:01
bringing aboard new Cloud providers.
00:01
This is mapping the attributes,
00:01
what in one federated system
00:01
is considered a username versus another.
00:01
Sometimes, I've seen situations where
00:01
you have a username that's internal to your own company.
00:01
But the federated system,
00:01
you don't want the ID,
00:01
the identity to be that internal username
00:01
that individuals use when
00:01
logging into their operating system.
00:01
You say, well, we're going to use our email,
00:01
that will become the ID when we're authenticating with
00:01
these different third party SaaS providers.
00:01
You're going to want to make sure there's
00:01
logging and security monitoring in place.
00:01
Even going through the exercise of
00:01
building out an entitlement matrix
00:01
to really lock down who can
00:01
do what under which scenarios.
00:01
Outlining some break fix scenarios as well so that
00:01
your support staff has
00:01
the ability to resolve and troubleshoot issues.
00:01
Of course, they're going to be
00:01
performing those activities and going through
00:01
those scenarios when there are incidents which
00:01
implies you have some an incident response plan,
00:01
who's going to deal with and
00:01
manage the troubleshooting and escalation process.
00:01
To put a finer point on the last question,
00:01
deep provisioning and entitlement change.
00:01
This can be complicated,
00:01
so you'll want to walk through this situation as well.
00:01
When an employee leaves and you
00:01
deactivate their account in the authoritative source,
00:01
you want to make sure that
00:01
the access this individual would have to
00:01
the various SaaS services or
00:01
PaaS services or so forth is also declined.
00:01
This could be a matter of setting rules
00:01
within the different federated providers,
00:01
the relying parties,
00:01
and making sure that they recheck on an incremental on
00:01
recurring basis to ensure
00:01
that authentication can be performed.
00:01
Then when they do that,
00:01
the authentication process will determine
00:01
that this individual's account is no longer
00:01
active and so they should not be able to use
00:01
these additional third party services.
00:01
Moreover, entitlement change.
00:01
Maybe they move from one group to
00:01
another and you need to get that reflected out there.
00:01
It can be complicated in
00:01
some situations and depending
00:01
on the underlying technology you have,
00:01
it could be a pretty simple process,
00:01
but it's something you'll definitely want to
00:01
think through and ask that question to
00:01
be thorough in your analysis when
00:01
you're onboarding new Cloud services.
00:01
Let's take some of our knowledge and
00:01
go with a quick question here.
00:01
Which federation protocol is the best one to support?
00:01
OAuth, OpenID, SAML,
00:01
Security Assertion Markup Language, XACML,
00:01
this is the Extensible Access Control Markup Language,
00:01
not something that we spoke about,
00:01
not one of the big three popular,
00:01
but it is something that may show up on your CCSK exam.
00:01
Just be aware that it is a policy enforcement type
00:01
of a solution that fits in
00:01
the same category as
00:01
these other products we've looked at,
00:01
or SCIM, also something we didn't talk about,
00:01
the System for Cross-domain Identity Management.
00:01
Also, it's a standard for exchanging
00:01
identity information between domains.
00:01
You'll want to be somewhat familiar with that one.
00:01
Which one is the best to support?
00:01
Then finally answer F,
00:01
it depends on the use case and the constraints.
00:01
I don t think this is a particularly
00:01
difficult answer to discern.
00:01
It really does depend on the use cases and constraints.
00:01
Obviously, if the technologies
00:01
aren't supported by a Cloud provider,
00:01
then you can't use those.
00:01
At the same time,
00:01
there are other technologies that
00:01
your own organization has
00:01
decided that they want to support.
00:01
You're not going to use those under those circumstances.
00:01
In this video, we went over
00:01
planning identity management,
00:01
we covered the federation patterns,
00:01
free form, hub-and-spoke,
00:01
and then we revisited and went through
00:01
a checklist of the process and architectural
00:01
decision-making and questions you're going to
00:01
want to ask yourself when setting up federation.
Up Next
Similar Content
