And then come back, not in Greece, we will be discussing at a high level overview about salmon.
So Salmon stands for the Security Association markup language and it is a secure XML based communication
mechanism for communicating the identities across the organizations.
Now, this point will be better understood in a moment here.
So the salmon eliminates the need to maintain multiple authentication credentials, such as passwords
in multiple locations.
So if you look into the classic way where you have multiple applications and services that are running
within your organization and each application has its own identities to.
So Jenkins has its own username and password.
The editor's has its own username and password in terms of an H.R. management software will have its
own username and password and so on.
So having these is a bit of a pain.
So let's look into some of the challenges in the classic way that we were discussing.
The first one is that the administrator does not really have the visibility with underlying database
of the SAS provider.
So currently we were discussing about JENKINS'.
So if you are hosting a Jenkins' within your own service, then you have a good amount of visibility.
But there are a lot of service providers which does not really give you any visibility of the database.
And in fact, it has been seen that a lot of the places where the usernames and passwords are stored
underlying the storing it in plain text and even big organizations are involved here.
So this is one big challenge.
Second challenge is that if there are multiple SaaS providers, it is difficult to keep track of which
user has access to which SaaS application.
So it might happen that the developer has access to Jenkins'.
However, the developer, Steve, has access to the database and all the users have access to it.
So at the end, if a certain user is leaving the organization, it is difficult to find out that user
has access to this application, specifically if you have maybe an application within your organization.
And that is what the third point is, that when the user leaves the organization, he needs to be removed
from all the entities.
It can be Jenkins, ET, etc. and so on.
So I still remember that in the organization that I have been working with so that any user who is leaving
the organization in his last day will come up with a form and he need the signature of the authority.
So, for example, he has access to a VPN and so he come to our team and we remove his access and then
we sign it in the document, which he'll have to submit to the API.
So in such cases, he'll have to take a signature from everyone saying that his user and his access
is removed and Post will submit that form to the ATO.
So in the organizations who does not really have single sign on doing such things is bit of a pain because
now you'll have to remove his access manually from all the applications.
So let's look into the different views here in a classic approach.
So the administrators view in classic approach here is that he'll have to log in to different provider
to manage and control the permission of an individual user across the organization.
And in case if he has forgotten his username and password and maybe lost this one for Amethi, then
the administrator will have to set the new MFA across all the applications.
So this is a bit of a pain.
Second is that users view users view is that he'll have to remember the password of all the applications
within the organization.
And it might also be present that use user idea across the applications are different.
So this is more open and the site's broader view in case the service provider, if it is storing the
username and password, the service provider will have to maintain the username and password database
of their customers.
And in case, if this database is leaked, then it is a big security liability of this aspirator.
So in the classic view, the administrator, the user, as well as the South Florida, everyone is not
happy.
So now comes the better way, which is the same.
So in summary, what you have, you have an identity provider and you have a service provider, Banzet.
So the service provider can be Jenkins', it can be EWR, it can be a set up and so on.
And the identity provider is the one which will be storing all the identities.
So instead of all the identities being stored at a service provider, we move that identity to the identity
provider site.
So let's look into the workflow diagram where you have the identity provider, all sort of what is the.
And the service provider for ADP.
So what will happen here is the use of its first login to the identity provider, the identity provider
will verify if the credentials are correct and a response is said.
So the user will go ahead and send that response to the service provider and the service provider.
If the response is as expected, it will be redirected to the management consultant.
So remember that in order for the service provider to accept this response, there needs to be a trust
between the identity provider and the service provider, which would had been established prior to this
entire process to work.
So this is what the Samawi is.
And this response can also be referred as this Samael assertion.
So let's look into the high level or so the flow gets initiated when the user opens up the ADP worried
and does the username and password and selects the appropriate application or so the application can
be a edged jenkins' and so on.
So the identity provider will validate the credentials and associated permissions and then use over
it, receive a Samit assertion from the IDP's part of the response.
So, you know, we were discussing this response.
This is basically this Samin assertion which the user receives.
So once the user has received this assertion, the user does up most of that Samin assertion to the
source signing page and the service provider will validate those assertion on validation.
The service provider will construct a relevant temporary credentials and also construct a signing warrant
for the console and sends it back to the user.
So that's the high level where, you know, let's quickly look into a demo so that this becomes better
understood.
Now, the first step that we are discussing is the user will have to send a user name and password to
the identity provider.
So they would be a concern, something similar to this, and the user username and password would need
to be sent.
So let's try it on grid.
So the authentication has been successful.
Now, if you look over here, once the authentication is successful, the user will have to select the
appropriate application because there can be multiple applications that would be present.
So it can be a database, it can be jenkins', it can be others.
So depending upon the application, because the service provider changes all you so you have a service
provider of a W.S. Jenkins, etc..
So this is important.
So what will happen is depending upon the service provider that the user chooses, the appropriate Samin
assertion will be said.
So let's try it out.
So as soon as I click on the management console currently enduring, you see it is Stammen and it is
basically signing in and it verifies and you are logged into the account.
So behind the scenes sort of thing has happened.
Like you have received the salmon assertion, the Salmon Association was forwarded to the service provider.
Service provider had validated that salmon, as I said, and he would add redirected to the management
console.
So let's do one thing in order to understand it in a better way.
I have a Sunday presser installed within my crew and we use that to see on what exactly happens behind
the scenes to understand this process at a high level overview.
All right.
So the first thing as we were discussing, the user will click on the management console.
So it is signing you in and you are signing.
So let's go.
And.
So now let me maximizer.
So the first thing here is basically the gate request is being made.
So this is the gate request that is being made to the ISS over here.
Now, if you look over here, there is also post now as we were discussing that once this assertion
is received, then the Post is being sent to the service provider.
So if you look into this specific post request, this post has been sent to this signing page of Dawe
with salmon.
So remember that Eatables has a separate bureau for authenticating if you're making use of salmon.
So this is the exact area that you will need to sink your salmon assertion, as you were discussing
once you received a salmon assertion.
That assertion needs to be sent to a specific in in the case of a device.
It is this Eweida.
So this is where the post is happening.
And if you look into the salmon, this is the salmon assertion, which is being sent to, you know,
if you go down at.
There is a small reading which is coming in and within this redirect, if you look into the location,
this is the location which is being shared by the AWB.
So similar to what we are discussing, a similar solution is being sent to the service provider, service
provider will verify and then it will send a redirect to the management console.
And that's what has been happening over.
So that's the high level overview about Simon.
And we also look into how the single Sinon providers to make use of Samin to go ahead and allow users
to connect to a specific service provider so that this will conclude this video.
I hope this video has been informative for you.
And I look forward to see you in the next video.