Since applications are the entrance to our data and our systems,
it is important that we have good identity management.
We've looked at the concepts of access control through identification,
authentication, authorization, and accounting or auditing.
Now let's look at some of the implementations of identity management.
The idea of Identity as a Service, and of course, we know that almost
anything is as a service today, is that it's something an
implementation of a type of software service‑based information
assurance and monitoring type of offering.
We know that it's a cloud service. It supports things like single sign‑on.
This is a huge advantage. When an organization has to put access controls
into every single application, that's a lot of work.
And of course, it creates the opportunity for more vulnerabilities.
So therefore, if I can go to a centralized type of system so that
all of my identity for any of the applications is handled by one
central point, well, that reduces the attack surface and, of
course, in some cases can help with things like consistency, and
maintenance, and support.
So single sign‑on is often a real advantage for an organization,
even in the cloud. What it does through Identity as a Service is
permit the correct level of access for users to various cloud
applications, and it supports some of the standards we're going to
look at here in federation.
It also allows us then to have access to logs so we know who is on the system,
who tried to get on the system, when were they there, and even what did they do?
The idea of identity management can also be handled through
something like a CASB, a cloud access security broker.
It may be used to manage access rights as a type of a third party, and of
course, an advantage of this is it can manage access across multiple
platforms or multiple different cloud implementations.
When we look at access control,
it's important that we manage access permissions all the way
through the identity lifecycle. Let's say,
for example,
they were set up originally to begin with, but then a person who moves
around within the organization works on a special project, and we
quite often start to see access expansion.
That means that their access quickly violates the terms
of least privilege and need to know.
So we want to ensure that we manage access so that it is correct at all
times from the time when we first provision that access,
we maintain a user's level of access, but then, of course,
we remove it when it's no longer needed through a process
we can call deprovisioning.
The idea of single sign‑on is a great idea if it can be done well.
But of course, we know that anything that has
advantages can also have disadvantages.
The idea, of course, of single sign‑on is it reduces sign‑in
requirements for a user that has to access multiple systems or multiple
applications. They log in once with a single user ID,
a single password, and now they have access to everything they need.
However, that also makes it a single point of failure.
If the single sign‑on system goes down, nobody gets anywhere.
It also makes a single point of compromise.
If someone is able to compromise the single sign‑on solution,
they now have access to everything the user would have access to, not
just one application, for example. But the idea behind this is it can
be a much better way to ensure compliance.
We now have a central point where we manage all access. We log, we
record, and we therefore do things in a consistent manner,
not where every application administrator does things as they see best, for
example. One of the implementations of single sign‑on,
especially in the web, is the idea of federated identity management.
It's what we could say here single sign‑on for the internet,
and it's where many different companies can actually use a
common identity management system.
For example,
I could go to a social media organization, and I have a login for them.
Well, they become a third party that manages access
to multiple different merchants.
We can see that here.
We have a user that wants to purchase a product for
merchant A. When they get to merchant A,
merchant A says,
oh, would you like to continue as a guest or would you like to log in?
The person says, well, I buy things from you all the time, so let's
create an account. Now merchant A says, well okay,
I could create the account for you, but that means I have to manage password
reset, storing passwords, storing user IDs. So instead, I'll give you a
preferential solution, and that is why don't you use one of your social
media accounts to actually log in to me?
So then, the person says, well sure, I've got a social media account, and the
merchant then directs them up to the identity provider.
The identity provider says, okay, use your login ID for
whatever type of social media this is.
And when the person then logs in,
the identity provider puts a token on the user's machine that says,
yeah, I'm comfortable that the user is who they say they are.
They've logged in correctly to my system.
And here's a token that if you trust me, then you as the merchant can just
accept the fact that the user is who they say they are.
And that gives the advantage now. The merchant doesn't actually have to do
any access control, should we say, mechanisms themselves.
If the user a few minutes later goes to merchant B, well, another merchant
sees that token is already on the user's machine and can say,
hey, I know who you are. You don't even need to log into me because you've
already logged in through an identity provider that I also trust.
So this is federated identity management.
It allows us to do a type of single sign‑on for an
internet‑based type of, let's say, e‑commerce situation.
There are a number of different standards for FIM, federated identity
management, we've used over the years such as Security Assertion Markup
Language, or SAML, OpenID, Open Authentication, OAuth.
And each of these has advantages and some disadvantages as well.
It's just a point to decide which one we would like to use. In
summary, this course was all about addressing the importance of
designing and implementing security and applications and
specifically, in this case, cloud‑based applications.
Since we've discussed that applications sit at the front edge of an
organization's network and they are subject to attacks that could lead to
compromise of the organization's data or business processes, it's that much
more important that we build them in a secure manner.