Hi my name is Peter Björk and I'm a
senior staff architect at VMware in this
video I'll cover an overview of Identity
and Access Management if you google
Identity and Access Management you often
get a definition similar to this one
Identity and Access Management is the
security discipline that enables the
right individuals to access the right
resources at the right time for the
right reasons that sounds easy enough
but embedded in that sentence is quite a
lot we need to manage the life cycle of
users we need to make sure the user is
who the user claims to be we must think
about ease of access for our users
access management doesn't mean it must
be hard to gain access just that the
access must fulfill our security
policies let's have a closer look at the
components that build a typical
Enterprise Identity and Access
Management solution first we need a user
store this is often based on Active
Directory but doesn't have to be
secondly quite early on companies
invested in some single sign-on or SSO
capabilities these were often focusing
on internal applications and used
non-standard methods of achieving single
sign-on but once the company started to
interact more with external parties such
as partners and software as a service
SaaS applications Federation was needed
these solutions very much are built on
standards and you can integrate products
from many different vendors because of
that closely tied to SSO and Federation
are the need for multi-factor
authentication or MFA with the use of
MFA we can have a higher trust level in
who the user is
with an ever-growing catalog of
application directories partners of SaaS
applications we need something that can
help with the lifecycle of the users
many companies have tied their user
lifecycle to their human reason
management system and lastly we need
capabilities to monitor and audit our
identity and access management solution
to make sure the right person has the
right access at the right time and for
the right reasons let's move on with
some common vocabulary the first one is
an easy one
Authentication, authentication is the act
of proving who you are it is often
referred to as AuthN typically
authentication is done by the use of
username and password or a certificate
to gain a higher trust level in the
authentication you can use things like
multi-factor authentication
authorization once the user has
authenticated authorization decides
what the user has access to
authorization is often written as AuthZ
as an example, you authenticate into
your domain join Windows machine once
logged in you open a file share and
browse the content your access to that
content is your authorization at the
beginning of mankind when developers
were asked to create an application the
developer started out investigating the
business requirements are starting
coding the business logic pretty soon
they realized they need some method of
separating different users from each
other the reason could be to store
individual user settings and preferences
or controlling access to data and so on
so developers had to create a user store
within the application in order to know
who the user were the developers had to
create some method of authentication and
roles and writes engine each new
application required this of course the
code could be reused but what happened
if username and password weren't good
enough anymore
perhaps you require certificate based
authentication instead now each
application must be changed and updated
and to make it worse the developers who
mainly cared about the business logic is
now in charge of
protecting the user store and to make
sure it's not being hacked or become
corrupted using a local method for
authentication is painful for developers
end users must enter user name and
password for each application often
resulting in weak passwords or the reuse
of passwords and lastly it's painful for
the administrators first they must
create users in each application
secondly if someone leaves they must
disable the user in each one of the
applications to solve this we have for a
long time had claim based access in the
claim based model the developer replaces
the authentication logic in the
application with a simpler logic that
can accept a claim and Trust is
established between the application and
a source of authentication and
authorization in this case I call it an
identity provider or IdP the application
will happily accept the claim that is
sent from the IdP the application may
still have a local user store for user
settings and access rights but the
application does not have to handle any
passwords since the users never
authenticate directly into the
application the user authenticate into
the identity provider instead and when
users wants to access the application a
claim or access token is generated by
the identity provider and sent to the
application the identity provider can
issue claims to all your applications
claim based access is much simpler for
the developers because they do not have
to create a strong authentication method
nor do they have to protect the users
passwords if a change in authentication
method is needed you change it on the
identity provider and the application
remains unmodified users are super happy
they can be authenticated once into the
identity provider and with that gain
seamless access into all their
applications administrators are also
happy if a user leaves the company
the administrator can disable the user
in the identity provider and immediately
access to all application has been
revoked let's try to use a common
scenario to explain the concept of a
claim a little more in depth
imagine you are about to go on a trip
and you decided to fly to the
destination when you arrive at the
airport you walk up to the check-in counter here you provide proof of
purchase of the ticket and you
authenticate with the help of your
passport
the check-in personnel validates your
credentials and issue you a boarding
pass this is your claim and the check-in
counter is the identity provider you
walk through security and when it's time
to board you show your boarding pass to
the personnel at the gate the gate
trusts the check-in counter
therefore it accepts what the boarding
pass claims for example my name my
frequent flyer status which plane I'm
supposed to board the boarding pass is
signed so the gate knows the claim
hasn't been tampered with and in today's
world of flying the gate trusts multiple
different identity providers the gate
trust the check-in kiosk and many times
also web check-in in a claim based
access model trust is at the heart in
order for it to work the application
must trust the identity provider how you
establish trust varies depending on
which standard you use often is trust
built with the help of exchanging
certificates when you create the trust
you are often asked to use something
referred to as the metadata
this is typically a file or a link to a
file the application shares its metadata
with the identity provider and the
identity provider shares its metadata
with the application using a metadata
file simplifies the establishment of
trust the metadata often contains the
certificate, login and logout URLs and
what else parameters each system
supports or requires not using a
metadata file require
you to manually enter these parameters
for some standards you do not use a
certificate instead you use something
like a system username and password now
we have a better understanding of claim
based access but as I mentioned before
in most cases we still need user objects
in the applications today many companies
use a centralized human resource system
to create and manage their users this
system can provision users into the
identity provider and then the identity
provider can provision the users into
the application but for larger
enterprises a more centralized system is
needed most enterprises have many
different users stores so they
incorporate a metadirectory as their
centralized and single point of truth this metadirectory is often fed by the
human resource management system from
the meta directory users are being
synchronized into each one of the other
systems this way the whole lifecycle of
the user is driven from the metadirectory you will often hear the term
realm or security domain when discussing
claim based access a realm or security
domain is basically the circle of trust
within the realm each component trusts
each other and claims are used to
provide access to systems but if you
have multiple realms or security domains
by default they do not have a trust
between each other so users in realm B
cannot make use of their claim issued by
their local identity provider to gain
access to applications in realm A this
is where Federation comes into play with
Federation it is possible to establish
trust between two different realms and
thereby a user in realm B can access an
application within realm A Federation
offers a great user experience users can
use their own local identity provider
for authentication and then seamlessly
access applications
in other realms user administration is
handled within each realm which means if
a user in realm B should no longer have
access the administrator of realm B
disables the user the administrator of
realm A doesn't have to be told the user
will lose all access once disabled by
the administrator in realm B when
federating between different realms you
often discuss the level of assurance in
other words how much do I trust the
other realm's processes, systems, users and administrators if I know that in order
for a user to be created in realm B the
user must provide proper means of
identification and in order to
authenticate the user are prompted for
multi-factor authentication my level of
assurance is quite high but if a user
can get a user account by simply filling
in an anonymous form and are prompted
for only username and password my level
of assurance is of course quite low you
can tie this to the fact that many
claims include information about how the
user was authenticated so you may have a
trust established between two different
realms but if the user is authenticated
using a too weak of an authentication
method I may decide not to allow access
many times I can redirect the user back
to its home realm and in my redirect
message requests for a higher level of
authentication when you federate with
many different entities you must have a
method of knowing the home realm of the
user this is often referred to as tenant
discovery you can argue tenant
discovery is more when using a SaaS
application who have many different
tenants and each tenant has its own
Federation configuration but the
principle is the same a user connects
directly to a resource and the resource
do not know if it should try to
authenticate the user or if it should
redirect the user to someone else for
authentication realm or tenant discovery
is quite hard to automate it often
requires some kind of user interaction here is a
couple of different variations of realm
discovery prompts Office 365 is well known
by most people in office 365 we often
perform tenant discovery by entering
your email address this tells Office 365
which tenant you belong to and thereby
it knows the Federation configuration
other ways of performing tenant
discovery is to simply offer a custom
URL then each tenant has a unique URL
that the user use for access here's an
example where both a custom URL and a
user prompt is used this tenant is
configured for two different identity
providers one for employees and one for
the externals with realm or tenant
discovery the system can now
successfully redirect the user for
authentication once authenticated the
user gets a claim that can be passed to
the system for access there are many
different standards regarding claims
which means a claim can contain many
different things but as a bare minimum a
unique user identifier must be included
the claim is often signed so the
receiving entity can verify the claim
hasn't been tampered with nowadays it
becomes more and more common to encrypt the whole claim for further protection
in some claims you have information
about if the user managed to
authenticate or not this might sound
weird but you often use this to see if a
user can perform a certain method of
authentication or not what method of
authentication the user performed is
also often passed in the claim if I
think the method is too weak I can
either prompt for another method myself
or I can redirect the user back to
perform a stronger method of
authentication some standards are very
flexible with the content of the claim
where others are very strict and
minimalistic but you can often see
things like email address first-name
lastname you can pass things like
rolls and group membership in a claim
sometimes you hear the word claim
transformation so here's two example of
claim transformation in alternative one
I use one type of claim to gain access
to an identity provider in this case I
use Kerberos once authenticated the
identity provider sends me forward with
a new kind of claim this time is
saml-based claim another way of viewing
claim transformation is if you change
the content of the claim as an example
the user may authenticate using username
a password and thereby authenticate into
the identity provider as an individual
but the application may not need
individual users separation so the only
thing that may be needed in the claim is
group membership or the role employee of
a certain company you can build chains
of federating entities with each hop the
claim is terminated and a new claim is
issued a claim is never passed through a
hop in this example the application only
trusts the last identity provider in the
chain and lastly
just to clarify multi-factor
authentication or MFA. MFA means you must
prompt for at least two different
factors and the factors typically are
something you know like a password or a
pin, something you have like a
certificate on a smart card or something
you are like your fingerprint if you
prompt twice for username and password
you are still only using one factor so
you haven't elevated your trust in the
user's authentication method the only
result you gained was to annoy the users
with that I thank you for watching this
video I hope you found it informative to
learn more please visit techzone.vmware.com
