1
00:00:00,240 --> 00:00:05,520
We already discussed about user details, user data and service user details.

2
00:00:06,150 --> 00:00:12,060
Now we have a clear understanding what is the relationship between all of them on what kind of methods

3
00:00:12,060 --> 00:00:20,100
that these interfaces support and how we how to leverage them in the scenarios of customizing these

4
00:00:20,100 --> 00:00:22,070
interfaces after implementing them.

5
00:00:22,080 --> 00:00:29,930
But to reduce our spring security framework, it provides three implementation of user details.

6
00:00:30,410 --> 00:00:32,700
One is in memory user details.

7
00:00:32,700 --> 00:00:40,320
Maneesha, if we have a requirement of doing some proof of concept or building some sample application

8
00:00:40,320 --> 00:00:44,010
to demo someone we can always leverage in memory user details.

9
00:00:44,460 --> 00:00:51,090
That means you can maintain the users, you can load the user details, authentication details, authorities,

10
00:00:51,090 --> 00:00:55,150
everything from the memory itself, which will store and set the spring content.

11
00:00:55,350 --> 00:00:59,820
So in that scenario, we will use in memory user details.

12
00:00:59,820 --> 00:01:00,900
Minnich, Bozak.

13
00:01:00,900 --> 00:01:08,760
We also have GBC user details manager, which is the most famous implementation provided by spring security.

14
00:01:08,850 --> 00:01:12,600
And this is a production grade ready implementation.

15
00:01:12,630 --> 00:01:20,190
That means if you provide data source details of my school or Oracle or any database, this database

16
00:01:20,260 --> 00:01:27,360
user details Mangeot how all the code related to loading the user details, maintaining them, creating

17
00:01:27,360 --> 00:01:30,030
them, deleting them, changing passwords, whatnot.

18
00:01:30,210 --> 00:01:34,050
It it has all the implementations provided inside it.

19
00:01:34,200 --> 00:01:37,160
And we also have a lab user details.

20
00:01:37,170 --> 00:01:43,920
Manege If your project leverages a lab server for authentication and authorization papers, we are free

21
00:01:43,920 --> 00:01:45,510
to use a lab user.

22
00:01:45,510 --> 00:01:48,180
Details, Maneesha, in most of the scenarios.

23
00:01:48,300 --> 00:01:51,210
We should be good with these user details, Manizha.

24
00:01:51,330 --> 00:01:57,450
But if we have a very specific requirement for your own project where you want to do it in something

25
00:01:57,450 --> 00:02:02,190
different, then you're always free to implement your own user.

26
00:02:02,190 --> 00:02:07,080
Details manage by implementing this user details manager interface.

27
00:02:07,260 --> 00:02:12,660
We will go and see what is a sample representation of all these user details.

28
00:02:12,660 --> 00:02:18,600
Manager implementation one by one so that we can get some better understanding from them.

29
00:02:18,630 --> 00:02:21,360
Let's go first to in-memory user details manager.

30
00:02:22,480 --> 00:02:28,890
This is the memory user details manager present inside the spring security framework with this package

31
00:02:28,920 --> 00:02:36,640
name if I see here it is implementing user details manager and also it is implementing some other interface,

32
00:02:36,820 --> 00:02:38,590
which we will discuss in some time.

33
00:02:38,740 --> 00:02:44,890
But if you see the main thing here is that it is implementing user details, Maneesha, and it also

34
00:02:44,890 --> 00:02:51,340
provides a constructor like you can pass the list of users which all these users will be stored inside

35
00:02:51,340 --> 00:02:53,140
the memory of your application.

36
00:02:53,350 --> 00:03:01,030
Like one by one, it will loop them and call create user and user will put all the user details inside

37
00:03:01,030 --> 00:03:04,590
a map which stored in the memory location.

38
00:03:04,720 --> 00:03:12,370
So we have these constructors followed by, if you remember, we have to take care of implementing how

39
00:03:12,370 --> 00:03:19,510
to create and user, how to delete and user, how to update and user all such methods inside our user

40
00:03:19,510 --> 00:03:20,020
details.

41
00:03:20,020 --> 00:03:20,650
Manager.

42
00:03:20,830 --> 00:03:27,790
By providing a logical setup, we see the very first method is create user so it will accept end user

43
00:03:28,090 --> 00:03:35,470
and it will store that user details inside a hash map and delete user will call remove the user details

44
00:03:35,470 --> 00:03:36,520
from the hash map.

45
00:03:37,030 --> 00:03:39,400
That user will update the user.

46
00:03:39,400 --> 00:03:46,710
Details that we provided to Hashmat by the user name is the key here and the value will be to whatever

47
00:03:46,750 --> 00:03:48,790
user that we store is that exists.

48
00:03:48,790 --> 00:03:55,420
Also will check whether the user is present with the given username and change password implementation

49
00:03:55,420 --> 00:04:02,830
also provided, followed by update password details and this updated password details is coming from

50
00:04:02,830 --> 00:04:07,150
the other interface that we have seen like user details.

51
00:04:07,150 --> 00:04:10,360
Password service interface has one.

52
00:04:11,480 --> 00:04:18,820
This is useful in the scenarios where you are user don't know what his old password, but he still want

53
00:04:18,820 --> 00:04:24,460
to update his new password on to create a new password in such scenarios.

54
00:04:24,730 --> 00:04:30,880
If you remember in most of the websites, whether we say forget password, they will provide you a link

55
00:04:30,880 --> 00:04:32,950
where you can reset your own password.

56
00:04:33,070 --> 00:04:39,730
In such scenarios, we can leverage this update password where users don't have to pass his password.

57
00:04:39,910 --> 00:04:47,890
A key will always pass his new password that we also have our famous method, which is law user by user

58
00:04:47,890 --> 00:04:51,220
name, which is coming from the user details service here.

59
00:04:51,370 --> 00:04:58,210
It's very easy if someone passing user name, it will go and check the map inside our memory location

60
00:04:58,330 --> 00:04:59,590
and try to get that.

61
00:04:59,740 --> 00:05:10,060
If that user is present, it will return a user details type by creating a user level using IT constructor

62
00:05:10,060 --> 00:05:16,690
where we can pass all the values present inside the user that we are getting from that memory.

63
00:05:16,690 --> 00:05:23,890
Look, this is the way how our in-memory user details manager has been implemented.

64
00:05:24,430 --> 00:05:29,410
And now I will show you the sample code that we have written previously.

65
00:05:29,710 --> 00:05:36,520
If you can see no line by line, this will make more sense to you now because we know what is the relationship

66
00:05:36,520 --> 00:05:37,510
between all of them.

67
00:05:37,720 --> 00:05:44,620
First, we are creating a new instance of user details, managing this in-memory user details manager

68
00:05:44,890 --> 00:05:51,040
intense extends user detent manager, which also extend user detail service.

69
00:05:51,070 --> 00:05:56,200
So that's why I named it as user detail service with the help of user.

70
00:05:56,740 --> 00:06:03,040
If you can recall from our previous videos, user is the default implementation provided by the spring

71
00:06:03,040 --> 00:06:07,170
security that occurs to the user details interface schema.

72
00:06:07,780 --> 00:06:14,440
So by leveraging that and we also have built inside that using them, we are creating a user name by

73
00:06:14,440 --> 00:06:18,400
passing user details along with passwords authorities.

74
00:06:18,730 --> 00:06:27,250
So once we have that user we are calling create user inside this in-memory user database manager, which

75
00:06:27,250 --> 00:06:36,700
will store these details inside a memory location Bozak that my authentication manager Beta I am indicating.

76
00:06:36,850 --> 00:06:39,310
So this is my user detail service.

77
00:06:39,550 --> 00:06:47,320
So when I say user details service, whenever you try to validate the user details in terms of credentials

78
00:06:47,320 --> 00:06:53,470
and authentication, go ahead and leverage this implementation that I am providing to you.

79
00:06:53,830 --> 00:07:01,720
Otherwise, Springboard, always go and follow the default way of handling the authentication.

80
00:07:02,050 --> 00:07:12,050
Now I can show you quickly if I start my server with this code framework, it call my law user by username.

81
00:07:12,490 --> 00:07:14,200
I'm getting a break point here.

82
00:07:14,920 --> 00:07:20,970
I'll go to your browser and call the service my account here.

83
00:07:21,010 --> 00:07:21,850
I'm entering the.

84
00:07:22,510 --> 00:07:29,170
I mean, one, two, three, four, five, if you see here, the breakpoint stopped here, which means

85
00:07:29,710 --> 00:07:37,260
the framework there is a provider which by default follows, which we call the authentication provider.

86
00:07:37,270 --> 00:07:46,360
From there, it will call the in-memory details manager load by username, because here the framework

87
00:07:46,360 --> 00:07:52,720
inside provider class, it will check what is a current user details service implementation.

88
00:07:53,260 --> 00:07:55,960
The current user details service implementation.

89
00:07:55,960 --> 00:07:58,670
Is this in-memory user details manager.

90
00:07:58,810 --> 00:08:05,200
So that's why we said that user detail service, which will be sent to the current one and framework

91
00:08:05,560 --> 00:08:05,920
now.

92
00:08:06,100 --> 00:08:14,020
OK, this is the current implementation and I have to call this method where it will come and try to

93
00:08:14,170 --> 00:08:17,530
load the user details from the memory location.

94
00:08:17,740 --> 00:08:25,900
And if the user is present, it will create a new user and send back the response, which is of user

95
00:08:25,900 --> 00:08:26,440
dictates.

96
00:08:26,860 --> 00:08:35,200
Similarly, we have JDBC user details manager, I would say compared to in-memory user details, manager,

97
00:08:35,530 --> 00:08:37,510
Priebke user details manager.

98
00:08:37,539 --> 00:08:42,880
How more advanced and it has most of the production ready features.

99
00:08:43,299 --> 00:08:46,930
That's where it implements user details manager.

100
00:08:47,080 --> 00:08:52,600
Along with that, it also extend their classes and interfaces.

101
00:08:52,840 --> 00:08:57,070
And you can see it has many methods.

102
00:08:57,670 --> 00:09:01,320
One is primary one which is load user by user name.

103
00:09:01,660 --> 00:09:10,000
So whenever we say load user by user name, it will go and look into the database that we configure

104
00:09:10,180 --> 00:09:19,090
with the table name users, because by default in the framework, they expect you to have a user stable

105
00:09:19,300 --> 00:09:20,950
with this column names.

106
00:09:21,400 --> 00:09:23,770
Otherwise this will not work.

107
00:09:23,800 --> 00:09:26,980
You have to customize it as part of the requirements.

108
00:09:27,430 --> 00:09:37,780
Similarly, we have the user where it will leverage create user rescuable, which is this one for creating

109
00:09:37,780 --> 00:09:39,680
a new user in the database.

110
00:09:39,850 --> 00:09:46,420
Similarly for delete update, everything we have is a school statement and associated matter.

111
00:09:46,660 --> 00:09:51,370
Along with that, we also have groups concept here.

112
00:09:51,880 --> 00:09:58,930
If you want to maintain authorities, it's always good to have a rules associated for the group and

113
00:09:58,930 --> 00:10:00,620
assign all the users to your group.

114
00:10:00,790 --> 00:10:03,220
Suppose I want to have some admin group.

115
00:10:03,460 --> 00:10:06,590
I can have some 500 users mapped to admin group.

116
00:10:06,760 --> 00:10:09,070
Similarly, I can create any number of groups.

117
00:10:09,220 --> 00:10:18,180
All such configurations can be managed using group manager where you have all the methods which are

118
00:10:18,220 --> 00:10:23,310
related to groups like find all groups, find users in group, create group, delete group.

119
00:10:23,500 --> 00:10:27,880
So all these methods are also implemented inside this user details.

120
00:10:27,880 --> 00:10:28,410
Maneesha.

121
00:10:29,110 --> 00:10:36,070
So if we have a requirement of storing the user details and retrieving the user details from database,

122
00:10:36,430 --> 00:10:40,210
then always leverage this database user details manager.

123
00:10:40,990 --> 00:10:47,590
And if we want to customize it, aspro requirements like I want to have a different table in different

124
00:10:47,590 --> 00:10:56,170
columns, then all of us take this as a reference and create your own user details manager and specify

125
00:10:56,170 --> 00:11:01,840
that the spring framework so that it is aware, OK, this is the details manager that I have to use

126
00:11:02,020 --> 00:11:04,180
while doing authentication.

127
00:11:04,750 --> 00:11:11,500
And for the scenarios where we have a lab server very similar to JDBC User Details manager.

128
00:11:11,680 --> 00:11:20,810
We also have a lab user details manager that implements user database manager and it also support create

129
00:11:20,830 --> 00:11:29,920
user update user and our famous method, which is load user by username based upon your requirement,

130
00:11:30,280 --> 00:11:36,790
always free to use any of these default details managed by spring security.

131
00:11:37,360 --> 00:11:43,630
On top of that, if you have any specific requirement, take them as a reference and implement in a

132
00:11:43,630 --> 00:11:46,870
similar way as per your application requirements.

133
00:11:47,560 --> 00:11:51,340
With this, we have enough of information about details.

134
00:11:51,340 --> 00:11:58,990
Manager and what are the default implementations provided by Spring sickert in next few videos, let's

135
00:11:58,990 --> 00:12:06,070
try to create a database maintained users inside database connect to that and try to do authentication

136
00:12:06,220 --> 00:12:08,190
using GBC user details.

137
00:12:08,200 --> 00:12:10,090
Manager, thank you by.