We already discussed about user details, user data and service user details.
Now we have a clear understanding what is the relationship between all of them on what kind of methods
that these interfaces support and how we how to leverage them in the scenarios of customizing these
interfaces after implementing them.
But to reduce our spring security framework, it provides three implementation of user details.
One is in memory user details.
Maneesha, if we have a requirement of doing some proof of concept or building some sample application
to demo someone we can always leverage in memory user details.
That means you can maintain the users, you can load the user details, authentication details, authorities,
everything from the memory itself, which will store and set the spring content.
So in that scenario, we will use in memory user details.
Minnich, Bozak.
We also have GBC user details manager, which is the most famous implementation provided by spring security.
And this is a production grade ready implementation.
That means if you provide data source details of my school or Oracle or any database, this database
user details Mangeot how all the code related to loading the user details, maintaining them, creating
them, deleting them, changing passwords, whatnot.
It it has all the implementations provided inside it.
And we also have a lab user details.
Manege If your project leverages a lab server for authentication and authorization papers, we are free
to use a lab user.
Details, Maneesha, in most of the scenarios.
We should be good with these user details, Manizha.
But if we have a very specific requirement for your own project where you want to do it in something
different, then you're always free to implement your own user.
Details manage by implementing this user details manager interface.
We will go and see what is a sample representation of all these user details.
Manager implementation one by one so that we can get some better understanding from them.
Let's go first to in-memory user details manager.
This is the memory user details manager present inside the spring security framework with this package
name if I see here it is implementing user details manager and also it is implementing some other interface,
which we will discuss in some time.
But if you see the main thing here is that it is implementing user details, Maneesha, and it also
provides a constructor like you can pass the list of users which all these users will be stored inside
the memory of your application.
Like one by one, it will loop them and call create user and user will put all the user details inside
a map which stored in the memory location.
So we have these constructors followed by, if you remember, we have to take care of implementing how
to create and user, how to delete and user, how to update and user all such methods inside our user
details.
Manager.
By providing a logical setup, we see the very first method is create user so it will accept end user
and it will store that user details inside a hash map and delete user will call remove the user details
from the hash map.
That user will update the user.
Details that we provided to Hashmat by the user name is the key here and the value will be to whatever
user that we store is that exists.
Also will check whether the user is present with the given username and change password implementation
also provided, followed by update password details and this updated password details is coming from
the other interface that we have seen like user details.
Password service interface has one.
This is useful in the scenarios where you are user don't know what his old password, but he still want
to update his new password on to create a new password in such scenarios.
If you remember in most of the websites, whether we say forget password, they will provide you a link
where you can reset your own password.
In such scenarios, we can leverage this update password where users don't have to pass his password.
A key will always pass his new password that we also have our famous method, which is law user by user
name, which is coming from the user details service here.
It's very easy if someone passing user name, it will go and check the map inside our memory location
and try to get that.
If that user is present, it will return a user details type by creating a user level using IT constructor
where we can pass all the values present inside the user that we are getting from that memory.
Look, this is the way how our in-memory user details manager has been implemented.
And now I will show you the sample code that we have written previously.
If you can see no line by line, this will make more sense to you now because we know what is the relationship
between all of them.
First, we are creating a new instance of user details, managing this in-memory user details manager
intense extends user detent manager, which also extend user detail service.
So that's why I named it as user detail service with the help of user.
If you can recall from our previous videos, user is the default implementation provided by the spring
security that occurs to the user details interface schema.
So by leveraging that and we also have built inside that using them, we are creating a user name by
passing user details along with passwords authorities.
So once we have that user we are calling create user inside this in-memory user database manager, which
will store these details inside a memory location Bozak that my authentication manager Beta I am indicating.
So this is my user detail service.
So when I say user details service, whenever you try to validate the user details in terms of credentials
and authentication, go ahead and leverage this implementation that I am providing to you.
Otherwise, Springboard, always go and follow the default way of handling the authentication.
Now I can show you quickly if I start my server with this code framework, it call my law user by username.
I'm getting a break point here.
I'll go to your browser and call the service my account here.
I'm entering the.
I mean, one, two, three, four, five, if you see here, the breakpoint stopped here, which means
the framework there is a provider which by default follows, which we call the authentication provider.
From there, it will call the in-memory details manager load by username, because here the framework
inside provider class, it will check what is a current user details service implementation.
The current user details service implementation.
Is this in-memory user details manager.
So that's why we said that user detail service, which will be sent to the current one and framework
now.
OK, this is the current implementation and I have to call this method where it will come and try to
load the user details from the memory location.
And if the user is present, it will create a new user and send back the response, which is of user
dictates.
Similarly, we have JDBC user details manager, I would say compared to in-memory user details, manager,
Priebke user details manager.
How more advanced and it has most of the production ready features.
That's where it implements user details manager.
Along with that, it also extend their classes and interfaces.
And you can see it has many methods.
One is primary one which is load user by user name.
So whenever we say load user by user name, it will go and look into the database that we configure
with the table name users, because by default in the framework, they expect you to have a user stable
with this column names.
Otherwise this will not work.
You have to customize it as part of the requirements.
Similarly, we have the user where it will leverage create user rescuable, which is this one for creating
a new user in the database.
Similarly for delete update, everything we have is a school statement and associated matter.
Along with that, we also have groups concept here.
If you want to maintain authorities, it's always good to have a rules associated for the group and
assign all the users to your group.
Suppose I want to have some admin group.
I can have some 500 users mapped to admin group.
Similarly, I can create any number of groups.
All such configurations can be managed using group manager where you have all the methods which are
related to groups like find all groups, find users in group, create group, delete group.
So all these methods are also implemented inside this user details.
Maneesha.
So if we have a requirement of storing the user details and retrieving the user details from database,
then always leverage this database user details manager.
And if we want to customize it, aspro requirements like I want to have a different table in different
columns, then all of us take this as a reference and create your own user details manager and specify
that the spring framework so that it is aware, OK, this is the details manager that I have to use
while doing authentication.
And for the scenarios where we have a lab server very similar to JDBC User Details manager.
We also have a lab user details manager that implements user database manager and it also support create
user update user and our famous method, which is load user by username based upon your requirement,
always free to use any of these default details managed by spring security.
On top of that, if you have any specific requirement, take them as a reference and implement in a
similar way as per your application requirements.
With this, we have enough of information about details.
Manager and what are the default implementations provided by Spring sickert in next few videos, let's
try to create a database maintained users inside database connect to that and try to do authentication
using GBC user details.
Manager, thank you by.