In the previous videos, we have created users and the passwords, authorities using user details,
user details, service, user, details, manager, and this is the code that we have created.
But do we know what is the relationship between all of them that spring security follows?
No, we have not looked into that.
Let's try to go and look into deep how this all user detailed user details of these user details.
Manager all are interlinked with each other.
This is a slide that can help you in understanding how end user will be managed by spring security,
we how all important interfaces and classes revolving around user management insights bring security.
We know whether we're dealing with authentication and authorization in any framework we need.
User details are customer details or want to access our application.
That's way we call it as user management in spring security.
If we see the very bottom interface that we have is user details.
User details is an interface which will define the schema or blueprint of the user that we are going
to deep inside an application.
It will how various methods like get password, get user name, get authorities like all these are needed
for my spring security framework to decide whether the given user is a valid user.
Again, these are all abstract methods.
Whatever user that we are going to create schema which is specific to our framework, we have to make
sure implementing these user detailed interface and this interface has all the methods revolving around
security.
Like I want the user name, I want the password authorities.
I want to know whether the account is expired or not.
Our current expert is the account is enabled or not.
All such possible user related information is backed into an interface called user detailed inside our
spring security.
So user details is an interface.
And these are all the abstract methods available inside this interface.
Whenever we are trying to create our own user schema definition specific to our application, we have
to make sure implementing this interface pos that we how user details service.
So this is an interface again, which have a single abstract method called law user by user name.
Ideally, most of the applications they just wanted to validate whether the given user is present inside
a database or an application inside and memory of my spring security container.
So in altered scenarios, we just pass user name to this abstract method that we are receiving from
the UI and this method we have in logic of patching the user details from the database or relapser out
from the memory of the spring container.
So user detailed is an interface which have a logic of attaching the user from the database or any other
place.
And the return type of law, user by user name is user details, because whenever we are dealing with
users, we decided to use user detailed schema adhering to that spring security.
Once we use a digital service, we also have user details manager, which again extends this interface.
So User Details Manager is an interface which again extends user details service, followed by where
this user details service will use this user details and schema to maintain the user data.
The primary difference between user details, service and user details manager interface is user detail.
Service will be using only in the scenario where I have a requirement to only fetch the user details
from the database or any other place.
In such scenarios.
We will go and use user detail service by implementing it and customizing espera requirements.
But if your application how a requirement to also maintain the user details that I want to create user.
I want to update, delete, change passwords along with fetching the user details inserts in adieus.
We have to make sure we are customizing by implementing user details.
Maneesha.
So since user details manager has extending this user detailed service also, that means along with
this method, it also inherits load user by user name, user details manager handles everything like
maintaining the user, switching the user name where user details service will only have better call
load user by user name, which will fetch the data at the same time.
Spring security provider.
Defamers user details manager implementation.
So whatever you're seeing in the top, all these are classes and they are default implemented by spring
security framework itself, by leveraging or by extending implementing this user details, manager interface,
in-memory user details manager.
We already seen in the last videos where it maintains the users it will create the user, fetch the
users from the memory of the spring container.
That's why we call it as in memory user details manager.
At the same time, ideal way of maintaining the users will be in the database in such scenarios, whether
you are masculine, Oracle or Mangat, to be wherever you are saving your user details, we will go
and use already implemented class, which is due to this user details manager.
And at the same time, if you have a requirement where the users are maintained an alert observer,
we will go ahead and use the user data manager class in our application.
But again, these are all provided by spring security.
We are free to use them as power requirements at any scenario.
If these three passes are not matching with our requirements, we are free to go and implement this
user details manager and override all these methods aspart requirements.
Now we have seen enough of Peery.
Let's try to go and see each component by component, which is revolving around user management inside
the framework and try to do some Hands-On application.
Also, hope this is making sense to you and I can assure you these things will make more sense in the
coming videos.
Thank you.
And by.