There are many identity management systems out there.

Okta - Which is cloud based. ADFS - normally used within enterprises.

Ping identity and so on.

Many major corporations like Oracle and IBM also have identity
management systems that they sell.
The idea is that these identity management systems include not only
support for SAML authentication,
but also other authentication mechanisms like OpenID Connect, Directory
Services or can even act as authentication
brokers.

Here is the security architecture using SAML.

So basically, we have taken this delegated authentication model and

given concrete names to all the
actors who are involved
So, for example, here.
The application is the same as service provider, and that SAML service
provider is the one which will
initiate a request to the SAML identity provider through the browser.
Remember, there is no direct communication between these two.
So we assume that the SAML service provider cannot directly talk to the
SAML identity provider because
they might be in different data centers.

The entity which will take that request and do the actual work.
is called the Identity Provider, and it's really a part of the identity
management system.
The user who's actually logging into the system in SAML is also called the
subject. In the SAML request,
and in the SAML response - you will see the user being referred to as the
subject.

The browser, which is used for redirecting the request to the small identity
provider, is called the
user agent.
This makes sense because the browser is really acting on behalf of the
user to automatically forward
requests as needed.
In fact, the user agent is critical because there is no direct path between
the service provider and
identity provider.
The communication has to go via the user agent.

Here's another scenario.

The applications are deployed in multiple clouds, one in AWS cloud and
the other one is in Google Cloud.
Both are part of the same enterprise, but they are deployed in two
different clouds.
But they have a trust relationship with the same SAML identity provider.

You can see that.

Web Application 2 has a trust relationship with the SAML identity provider
and Web application 1
also has a trust relationship between the identity provider.
We mentioned that the trust really means that the two entities know
about each other.
So in this case, the identity management system knows about web
application 1 and web application 2
We have to manually set it up.

So let's talk a little bit about single sign on out here.

So if a user, for example, goes ahead and tries to access web application
1 because it has a trust
relationship between the identity management system and web
application 1, it will redirect the request
to the SAML identity provider.
User will log in. Next time when the user actually tries to access web
application 2 -
because it has the same trust relationship with the same Somali identity
provider,
the user will not have to do an explicit log in.
It will automatically log into the Web application 2
So that's the idea about Single Sign On

And in fact, if the user is part of the enterprise itself.

Then the user does not even have to enter the credentials because it has
already logged into the
network, so in which case the user does not have to even enter the
credentials when it is accessing
web application 1
Also note that the diagrams I've shown are very general.
You could have all your applications within the enterprise.
That is, all applications are within the same data center or security
domain, and everything will
work fine.

You could even have the identity management system in the cloud like
Okta.
So point being, many variations of the same architecture are possible, but
the ideas pertaining to Single
Sign-On and delegate authentication are valid for all of these
architectures.
So - armed with this knowledge, let's go through the SAML authentication
flow to get some concrete
idea about what requests and responses are being sent.

In other words, let's see how SAML solves the problem of cross domain log i
I'm also assuming here that the trust relationship between the SAML
identity provider and the SAML
service provider is already complete.
In other words, the administrator has set up a web application from
identity management console and
attributes specific to the service provider are known to the identity
provider.
Also, the application is set up with the information about the SAML
identity provider.
One quick way to achieve this is to exchange the SAML metadata file,
which is also an XML
formatted file. In this case, instead of setting the attributes separately,
SAML metadata file can
be created for the identity provider and one for the service provider.
The SAML identity provider can then just upload the SAML Service
Providers metadata file.
The same can be done by the service provider.

In addition, users are also assigned to this application in the identity

management system.
So the identity management system knows which users are allowed to
access the Web application.
So now let's go through the SAML authentication flow
when the user accesses the web application for the first time.

So user accesses the Web application for the first time using the URL that
is provided.
So at this point, the application does not have any valid session with the
user.
The application does not know who the user is, so it forwards the request
to a well-defined SAML identity
provider
Single sign on
URL
This single sign on URL is defined in the identity provider's metadata file.
And so the application knows about it.
We talked about this approach during the delegated authentication model.
The actual request is an XML, which is optionally signed and the format is
defined by the SAML protocol.
There are a number of ways this request can be sent.
It can be sent using the HTTP redirect mechanism.
In this case, the application
replies to request number 1 with an HTTP 302
Status code and add the SAML request.
This makes the browser send the HTTP get request with the SAML request
as part of the URL.
It can also be sent using HTTP post mechanism. In this case, when the
user accesses the application -
the web application will return an HTML page.
Which contains.
Necessary JavaScript code to automatically submit a similar request using
the post mechanism to the
SAML identity provider.
This is also very common.

The SAML protocol defines a field called protocol binding, which defines
what forward mechanisms to
use, whether to use HTTP redirect or to use HTTP post.
Either way, a similar request is sent to the SAML identity provider from the
browser.
As far as the SAML service provider is concerned, it has asked the browser
to send this request to
the identity provider.
Think now from the identity providers perspective.
An HTTP request has been sent to the identity provider.
But it doesn't know who the user is
So the identity provider will show a login screen.
to get the credentials of the user.
The user will enter his assigned username and password and will click on
the submit.
at which point the user credentials are sent to the SAML identity provider.
The SAML identity provider will grab the user and password and will
interact with the directory services,

mostly Active Directory.

to validate the user's identity.
We went through this when we talked about LDAP directory services, but
now it's the identity management
system that is doing it for us.
behind the scenes.
The identity provider will also take care of any invalid passwords, the
retries, invalid user and
all the other errors, and the application does not have to deal with it.
It doesn't.
have to be bothered with those errors.
If the authentication succeeds and if the user is a valid user of the
application, then the SAML identity
provider will create a SAML authentication response, which is also of a
XML format.

The response will contain all of the attributes of the user or in this case,
we also call it subject.
The response example has the SAML assertion XML tag, which in turn
contains all the attributes
of the user.
In addition to the user attributes, the SAML assertion will also contain the
groups associated with
the user, which will be used by the application for authorization.

This response is sent back to the application URL, which handles the SAML
assertion.
And so in the SAML terminology, it is also called Assertion consumer
service.
URL
That's the ACS URL
Once the application gets this response, it will have to verify the SAML
response and the assertion.
The assertion is also called a token.
It's called the SAML token.
This is important because this response could have been sent by a rogue
user or an application.
So to protect against this, many validations are done on the SAML
response.
Check that the SAML token has not expired, its signatures can be verified
to make sure that it is
signed by the identity management system.
The assertion can be decrypted if it was encrypted in the first place.
Let me make an important point over here.
If you look at how the authentication was done by the SAML identity
provider, that's Arrow 3
and Arrow 4, the user entered the credentials and then the identity
provider verified that with
the directory services using LDAP
But if you think about it, the user already has logged into the enterprise
network using a username
and password.
So if everything is within their enterprise - that is the user, the identity
provider and the browser,
then the Samuel Identity Provider should be able to recognize the user,
even if the user does not provide
the credentials.
That's exactly what happens if everything is set up correctly for single
sign-on in an enterprise.
In this scenario, when request 2 is sent to the identity provider, the SAML
identity provider will
recognize the user as the one logged into the enterprise network and will
simply send back the same
response to the application without asking for credentials.
This provides for an excellent user experience.
This entire authentication flow that we just talked about is called the SP
initiated SAML single sign
flow
Both the service provider, as well as the identity provider, are entities,
and in SAML, they have an
Entity ID associated with them.
In requests and responses of SAML, you will see this entity very often.
For example, who is the issuer of a request?
Who is the recipient of the response and so on.
And EntityID would be used to refer to these rules.

These entities can simply be any string.

But usually we set them as URLs, and we will see this in action when we
start sending requests
manually.

Also, frequently, the service provider is also called the relying party.
So application service provider and the Relying Party refer to the exact
same entity.

There is one more important SAML concept that needs to be discussed,

and that is the Relay State
You will see them often in requests and the URLs

So after receiving the SAML response 5,

the Web application must verify the response, and if everything looks
good, then it can redirect to
the Relay State
URL.
The Relay State parameter may not always exist, and so the application
may just choose the homepage
or it can choose a page, depending on the user and the groups associated
with the user.
That's where the authorization of the user comes into the picture, which
we have already talked about,
is the sole responsibility of the application.

IDP initiated SAML flow

We then mentioned that the user should use the same identity for all the
applications.
That's really ideal because we want a single password to be managed for
a user.
We don't want multiple passwords.
With SAML - this is possible as long as all the applications are written so
that they all integrate
with the common SAML identity provider.
In other words, the SAML identity provider knows all the applications and
their users.
More generally, this is the job of the identity management system - Okta,
ADFS etc

Because in a more general scenario, all applications might not be using

SAML, they might be using
other authentication mechanisms like OpenID Connect.
So there will usually be a mixture of applications, some using SAML and
some using OpenID Connect.

So in a more general sense, it would be really ideal to have a scenario

where an enterprise user logs
into an enterprise dashboard and sees the applications that he or she has
access to.
From here, the user can click on a particular application icon or a link and
get redirected to that
application page.
In SAML, this is done using the IDP initiated single sign on flow.

The identity management system will provide a URL for accessing the
dashboard.
So now all the action starts when the user logs into the dashboard.
The user will enter the dashboard URL and then from the login screen,
enter the username and password

and submit to the identity provider.

We've mentioned this before.
If set up correctly, the user does not have to enter the username and
password because the user has
already logged into the corporate network and the IDP or the IDM can
recognize this when the user logs
in.
This is also called a desktop single sign on.
After the IDP authenticates the user, the IDP will display the dashboard
user interface.
to the user with all the user applications as links.
Now, the user clicks on one of the application links to access a particular
application.
What should happen? That user click will go to the IDP.
And because the IDP has all the information about the application, IDP will
create a response XML
with the right assertion.
The assertion is simply an XML within the response, which contains the
user attributes as well
as the group attributes.
The assertion that is created by the IDP is also digitally sign and
encrypted. because this requires the exchange of the public key
information between the SP and IDP.
The resulting response after encryption and signing is then sent to a
service provider.
Not here, that the service provider did not have to send a request to the
IDP.
The request is totally bypassed.
What happens to the Relay State parameter. we talked about this in the
SP initiated SAML Single Sign
On
Most IDPs will have the option to set up a default Relay State because the
Relay State is not coming
from the SAML request anymore, and the IDP initiated flow will use this
default Relay State and
that will get sent back to the web application.
The rest of the flow is similar.
Once the application gets the response from the IDP, the application will
have to verify that assertion.
And if all looks correct, it will redirect to the home page.
That application page could be the home page.
Or the application might choose the Relay State to redirect to that
particular page in the user interface.
Typically, this application will open in a separate browser page or a
different browser window.
At this point, the user can then click on a different application from the
dashboard and can access
another application as well.
This is extremely convenient because, as you can see, the user did not
have to enter the credentials
to access the applications as well as all applications are in one place
ready to be accessed.
One other thing which is kind of important are the browser sessions.
One other thing which is kind of important are the browser sessions.
We will talk about the browser sessions and future lectures.
But take a look at the screen.
There will be one browser session with the web application and one
browser session with the IDP.
This can get confusing, but we will take a look at this deeply in the future
lectures when we do some
hands on requests and responses.
with Okta