In the last few videos, we have created a very simple springboard project and bring security on it.
We also built this app with the part welcome and we tested through Broza enforcement to understand how
it works on a high level.
But if you ask me how spring security framework works internally, once it receives any request from
the Frinton or any third party app consumers, this is the floor.
How it works.
Exactly.
So this video will help you in detailing how being security flow, Wolf.
Internally, as you can see there, a sequence of steps that has been noted right from one to the very
first step that will happen is as soon as someone calls app through browser or any app consumer with
the credentials, a filter authentication filter, which is present in the spring framework spring security
framework, will be intercepting the request.
Once it intercepts that request, it will try to convert whatever authentication details that we are
receiving from the user like username and password into an authentication object.
This authentication object is a base where all the validation of user credentials will be validated
for the steps.
Once that ID object is built, the request will be passed to the authentication manager.
Authentication manager is the place where it will identify what is a correspondent provider authentication
provider that my request has to go like.
We have not many process where we can validate user credentials, like you may use database to validate
user credentials or you may use a lab or you may use or so there can be many possible providers that
your system may have authentication manage.
It is a place where it will identify what is the most appropriate authentication provider that my request
has to be sent once authentication provider receives the request.
This is a place where all your business logic will be implemented.
When I said business logic, the logic related to you security like how do I validate username and password?
There can be scenarios where you may receive email as a user.
There can be some scenarios where you receive a mobile number as a username and password.
So based upon all such scenarios, you will implement all your logic of security validation inside your
authentication provider and authentication provider.
Interns will use to the interfaces.
One is user details services and other one is password.
And the user data services is the interface which holds user schema, like how my user details should
look like.
It might be a scenario where my user eHow username password or T.P artifact ID all that schema.
I will identify under my user and user details, services and password and current user interface,
which will tell all my passwords has to be encrypted.
Encoded are decrypted while evaluating the security, provides many passwords and codes which will be
seen in the coming sections.
Decrypt password and coder, no password and caught in the scenarios where we don't want our password
to be encoded encrypted.
All possible password codes are available in security, which will be seeing in the coming sections.
Once authentication provider using user detail services and password encoder validator with the input
potentials are valid or not, the floor will be given back to the indication manager honored by the
authentication printer.
Now my authentication object, which I initially sent from my filter rehaul, whether the user is a
valid, authenticated user, what are the authorities or what are the rules associated to it?
Inside my authentication object, once my authentication filter, this my authentication object, which
is populated from authentication provider manager, which is seen in the step eight, this authentication
free that will pass that authentication object to security can explain my details will be stored inside
the container.
If you remember in the previous version, there is a token packet children.
So in this scenario, application will hold the.
Which will be stored inside my spring container using security context, interface, security context
is the place where we see the data of the user once he or she authenticate themself, can be it might
be a valid user or she might not be a valid user.
All sorts of details will be stored inside the security context given back to the browser from second
time onwards.
If they are trying to pass the same security information, all this flow will not be executed because
we already tried to validate the person using that credentials.
Enter and spring security will tell you, OK, using this token, whatever I am receiving from second
time onwards, that is a valid token or invalid token.
This is how it works internally in spring security framework.
If there is a scenario where I can remember only one slide in this entire course, this is one of the
slide that I will choose to remember because this is a base for entire spring security and we will discuss
each component by component how to configure according to our custom requirements in the coming sessions.
This is making sense to you.
Thank you.
And see you in the next review by.