1
00:00:00,240 --> 00:00:06,320
We have seen in the previous videos both in the authentication, Maneesha, and authentication provider,

2
00:00:06,570 --> 00:00:12,810
so there is a method called authentication which accepts and returns authentication object.

3
00:00:13,080 --> 00:00:20,130
So that means this authentication object is very crucial to the framework whenever it wants to perform

4
00:00:20,130 --> 00:00:21,990
any authentication, often user.

5
00:00:22,200 --> 00:00:28,890
So let's try to understand what is this authentication object and how it is different from user detailed

6
00:00:29,250 --> 00:00:35,280
interface or object that we have discussed previously, along with the user details, service and password.

7
00:00:35,280 --> 00:00:37,470
And so authentication interface.

8
00:00:37,800 --> 00:00:43,320
It implements principle interface, which is from the Java API.

9
00:00:43,710 --> 00:00:52,500
So principle is an interface from Java Security API and it has only one method which indicates the name

10
00:00:52,500 --> 00:00:53,360
of the user.

11
00:00:54,150 --> 00:01:01,440
But coming to the authentication interface, it has various methods like get authorities or the authorities

12
00:01:01,440 --> 00:01:08,160
associated for this user, get credentials, which usually represents the password of the user, get

13
00:01:08,160 --> 00:01:15,530
detailed the additional details that we want to maintain associated for this user, like the IP address

14
00:01:15,540 --> 00:01:23,300
he's trying to log in any such additional details we can maintain and fetch it from the get details

15
00:01:23,310 --> 00:01:30,270
method and get principle is the one which is extended from this principle interface.

16
00:01:30,420 --> 00:01:38,490
And using that principle will come to know the name of the user and is authenticated is the one which

17
00:01:38,490 --> 00:01:42,880
maintained by the framework for the user is authenticated.

18
00:01:43,110 --> 00:01:45,180
So by default, this value is false.

19
00:01:45,360 --> 00:01:51,660
But of the successful authentication this is authenticated will be changed to prove, and this will

20
00:01:51,660 --> 00:01:58,590
continuously maintained by the framework at various stages of the authentication and authenticated.

21
00:01:58,800 --> 00:02:07,080
So this is the method that we use when we want to change the authentication of the user is true or false.

22
00:02:07,530 --> 00:02:14,100
So now we understand authentication is an important interface maintained by the security and it has

23
00:02:14,100 --> 00:02:19,780
all the associated details of an user while performing authentication.

24
00:02:20,100 --> 00:02:26,750
So let's try to look into the core also, as I was saying, authentication, interface principle.

25
00:02:27,240 --> 00:02:30,620
And this is from the our library.

26
00:02:31,290 --> 00:02:40,800
It has only one which retains the name of user and entity that we have methods like authorities to understand

27
00:02:40,800 --> 00:02:45,060
the authorities associated with the user, followed by get credentials.

28
00:02:45,450 --> 00:02:52,370
Usually this is the password of the user, followed by additional details that we want to maintain using

29
00:02:52,370 --> 00:02:54,720
get details and get principle.

30
00:02:55,350 --> 00:03:02,040
Usually referred to the user name and is authenticated is a boolean, which indicates whether the user

31
00:03:02,040 --> 00:03:04,170
is logged in successfully or not.

32
00:03:04,320 --> 00:03:12,750
And authenticated is a method which we call whenever we want to update the is authenticated boolean.

33
00:03:13,200 --> 00:03:18,290
So now we understand this is the ID object that maintained by this being security.

34
00:03:18,480 --> 00:03:24,930
But if you remember from our previous implementation inside our application, we are dealing with user

35
00:03:24,930 --> 00:03:25,700
details.

36
00:03:26,070 --> 00:03:33,690
So if I go to my user detail service implementation of my application, we are calling your user by

37
00:03:33,690 --> 00:03:37,020
user name and it will retain user details.

38
00:03:37,620 --> 00:03:45,000
And we know by default, setting security really leverages Davo authentication provider.

39
00:03:45,510 --> 00:03:50,490
But how the conversion between this user details and authentication is happening.

40
00:03:50,670 --> 00:03:55,690
Let's try to look into the code by going to the Davo authentication provider.

41
00:03:55,980 --> 00:04:02,570
I'm just going to the authentication provider and we don't have authenticate method inside this, which

42
00:04:02,580 --> 00:04:09,270
will be called by the manager that is being maintained inside this class, which is tracked user details,

43
00:04:09,310 --> 00:04:11,060
authentication provider.

44
00:04:11,460 --> 00:04:16,589
I go to the complicated matter from this authenticate method.

45
00:04:16,950 --> 00:04:18,990
It call will go to the retrieve user.

46
00:04:19,529 --> 00:04:23,600
So it is implemented inside our transaction provider itself.

47
00:04:24,090 --> 00:04:31,350
Here you can see by default, this is calling my user details service, which is Implementor and the

48
00:04:31,350 --> 00:04:33,110
return type is user details.

49
00:04:33,460 --> 00:04:38,370
OK, so and that type of user also user details.

50
00:04:38,580 --> 00:04:46,110
Let's try to backtrace and the way the conversion is happening here, we are capturing the user.

51
00:04:46,320 --> 00:04:53,760
And if you come down so this is the place where it will convert this user to an authentication object.

52
00:04:53,770 --> 00:04:59,880
If you go and look into this creates a complication, the return type is automatically.

53
00:05:00,570 --> 00:05:09,330
And leverages that he's received from our user detailed surveys, and it is converting into a type of

54
00:05:09,330 --> 00:05:11,920
username, password authentication toker.

55
00:05:12,240 --> 00:05:20,130
So this is an implementation of a product application which internally extends protection.

56
00:05:20,430 --> 00:05:28,690
That means as long as you retaining this, since it is implementing authentication interface itself,

57
00:05:29,010 --> 00:05:30,870
the framework will not complain.

58
00:05:31,170 --> 00:05:37,830
And by the way, our user details is converting into authentication details.

59
00:05:38,130 --> 00:05:42,960
But you may ask, what is the need of authentication and user details?

60
00:05:43,170 --> 00:05:48,790
Two different mechanisms to maintain the similar user details.

61
00:05:49,290 --> 00:05:52,100
The answer is spring security.

62
00:05:52,410 --> 00:05:57,410
Want to give you that flexibility at each and every layer.

63
00:05:57,720 --> 00:06:07,500
So my user details manager and user detail service will leverage my user details, whereas my authentication

64
00:06:07,500 --> 00:06:14,010
manager and the authentication provider, they always leverage authentication interface.

65
00:06:14,250 --> 00:06:22,130
So that's why spring security always give you the flexibility of maintaining aspart your requirement.

66
00:06:22,350 --> 00:06:30,750
But if you don't want user details to be maintained, you can always free to customize the authentication

67
00:06:30,750 --> 00:06:36,510
provider aspart requirement and free to use directly the authentication object.

68
00:06:36,780 --> 00:06:43,350
So now we understand what is authentication authentication provider in the last few videos.

69
00:06:43,680 --> 00:06:51,710
So let's try to implement and customize authentication provider based upon our custom requirements inside

70
00:06:51,720 --> 00:06:54,150
our application and see how it works.

71
00:06:54,390 --> 00:06:54,830
Thank you.

72
00:06:54,840 --> 00:06:56,220
And see you in the next review by.