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