1
00:00:00,180 --> 00:00:07,380
In the last few videos, we have created a very simple springboard project and bring security on it.

2
00:00:07,440 --> 00:00:15,660
We also built this app with the part welcome and we tested through Broza enforcement to understand how

3
00:00:15,780 --> 00:00:17,150
it works on a high level.

4
00:00:17,310 --> 00:00:25,470
But if you ask me how spring security framework works internally, once it receives any request from

5
00:00:25,470 --> 00:00:30,930
the Frinton or any third party app consumers, this is the floor.

6
00:00:31,110 --> 00:00:32,070
How it works.

7
00:00:32,070 --> 00:00:32,759
Exactly.

8
00:00:32,910 --> 00:00:38,850
So this video will help you in detailing how being security flow, Wolf.

9
00:00:39,000 --> 00:00:46,200
Internally, as you can see there, a sequence of steps that has been noted right from one to the very

10
00:00:46,200 --> 00:00:55,580
first step that will happen is as soon as someone calls app through browser or any app consumer with

11
00:00:55,590 --> 00:01:01,920
the credentials, a filter authentication filter, which is present in the spring framework spring security

12
00:01:01,920 --> 00:01:05,340
framework, will be intercepting the request.

13
00:01:05,340 --> 00:01:12,060
Once it intercepts that request, it will try to convert whatever authentication details that we are

14
00:01:12,270 --> 00:01:18,130
receiving from the user like username and password into an authentication object.

15
00:01:18,270 --> 00:01:26,760
This authentication object is a base where all the validation of user credentials will be validated

16
00:01:27,000 --> 00:01:27,920
for the steps.

17
00:01:27,960 --> 00:01:34,260
Once that ID object is built, the request will be passed to the authentication manager.

18
00:01:34,370 --> 00:01:41,670
Authentication manager is the place where it will identify what is a correspondent provider authentication

19
00:01:41,670 --> 00:01:45,030
provider that my request has to go like.

20
00:01:45,060 --> 00:01:53,310
We have not many process where we can validate user credentials, like you may use database to validate

21
00:01:53,310 --> 00:02:01,290
user credentials or you may use a lab or you may use or so there can be many possible providers that

22
00:02:01,290 --> 00:02:03,630
your system may have authentication manage.

23
00:02:03,630 --> 00:02:11,009
It is a place where it will identify what is the most appropriate authentication provider that my request

24
00:02:11,009 --> 00:02:15,580
has to be sent once authentication provider receives the request.

25
00:02:15,810 --> 00:02:21,090
This is a place where all your business logic will be implemented.

26
00:02:21,090 --> 00:02:28,620
When I said business logic, the logic related to you security like how do I validate username and password?

27
00:02:28,620 --> 00:02:32,360
There can be scenarios where you may receive email as a user.

28
00:02:33,060 --> 00:02:38,030
There can be some scenarios where you receive a mobile number as a username and password.

29
00:02:38,310 --> 00:02:46,970
So based upon all such scenarios, you will implement all your logic of security validation inside your

30
00:02:47,130 --> 00:02:49,980
authentication provider and authentication provider.

31
00:02:50,280 --> 00:02:53,940
Interns will use to the interfaces.

32
00:02:54,090 --> 00:02:57,830
One is user details services and other one is password.

33
00:02:57,840 --> 00:03:06,360
And the user data services is the interface which holds user schema, like how my user details should

34
00:03:06,360 --> 00:03:07,300
look like.

35
00:03:07,590 --> 00:03:17,280
It might be a scenario where my user eHow username password or T.P artifact ID all that schema.

36
00:03:17,280 --> 00:03:24,780
I will identify under my user and user details, services and password and current user interface,

37
00:03:24,930 --> 00:03:29,190
which will tell all my passwords has to be encrypted.

38
00:03:29,190 --> 00:03:36,150
Encoded are decrypted while evaluating the security, provides many passwords and codes which will be

39
00:03:36,150 --> 00:03:37,860
seen in the coming sections.

40
00:03:38,460 --> 00:03:45,240
Decrypt password and coder, no password and caught in the scenarios where we don't want our password

41
00:03:45,240 --> 00:03:47,440
to be encoded encrypted.

42
00:03:47,490 --> 00:03:55,410
All possible password codes are available in security, which will be seeing in the coming sections.

43
00:03:55,440 --> 00:04:03,710
Once authentication provider using user detail services and password encoder validator with the input

44
00:04:03,730 --> 00:04:11,250
potentials are valid or not, the floor will be given back to the indication manager honored by the

45
00:04:11,250 --> 00:04:12,440
authentication printer.

46
00:04:12,600 --> 00:04:20,850
Now my authentication object, which I initially sent from my filter rehaul, whether the user is a

47
00:04:20,850 --> 00:04:27,180
valid, authenticated user, what are the authorities or what are the rules associated to it?

48
00:04:27,180 --> 00:04:34,210
Inside my authentication object, once my authentication filter, this my authentication object, which

49
00:04:34,230 --> 00:04:41,910
is populated from authentication provider manager, which is seen in the step eight, this authentication

50
00:04:41,910 --> 00:04:50,840
free that will pass that authentication object to security can explain my details will be stored inside

51
00:04:50,850 --> 00:04:51,630
the container.

52
00:04:51,960 --> 00:04:55,370
If you remember in the previous version, there is a token packet children.

53
00:04:55,740 --> 00:04:59,130
So in this scenario, application will hold the.

54
00:05:00,030 --> 00:05:07,230
Which will be stored inside my spring container using security context, interface, security context

55
00:05:07,770 --> 00:05:16,740
is the place where we see the data of the user once he or she authenticate themself, can be it might

56
00:05:16,740 --> 00:05:19,920
be a valid user or she might not be a valid user.

57
00:05:20,010 --> 00:05:26,160
All sorts of details will be stored inside the security context given back to the browser from second

58
00:05:26,160 --> 00:05:27,180
time onwards.

59
00:05:27,330 --> 00:05:34,830
If they are trying to pass the same security information, all this flow will not be executed because

60
00:05:34,830 --> 00:05:39,030
we already tried to validate the person using that credentials.

61
00:05:39,030 --> 00:05:45,180
Enter and spring security will tell you, OK, using this token, whatever I am receiving from second

62
00:05:45,180 --> 00:05:48,910
time onwards, that is a valid token or invalid token.

63
00:05:49,050 --> 00:05:53,420
This is how it works internally in spring security framework.

64
00:05:54,000 --> 00:06:01,560
If there is a scenario where I can remember only one slide in this entire course, this is one of the

65
00:06:01,560 --> 00:06:09,870
slide that I will choose to remember because this is a base for entire spring security and we will discuss

66
00:06:09,870 --> 00:06:17,040
each component by component how to configure according to our custom requirements in the coming sessions.

67
00:06:17,400 --> 00:06:18,920
This is making sense to you.

68
00:06:18,960 --> 00:06:19,560
Thank you.

69
00:06:19,710 --> 00:06:22,080
And see you in the next review by.