Identity and Access Management: Technical Overview - YouTube

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