1
00:00:07,590 --> 00:00:15,930
In most organizations, users sign in to the network and are authenticated by an editor's domain controller.

2
00:00:16,440 --> 00:00:23,850
A user who provides the right credentials to the domain controller is granted a security token.

3
00:00:24,450 --> 00:00:32,370
Applications that are running on the servers in the same areas environment trust, the security tokens

4
00:00:32,670 --> 00:00:35,640
the editors domain controllers provide.

5
00:00:36,390 --> 00:00:43,650
This is because the servers can communicate with the same domain controllers on which the user resolves

6
00:00:43,650 --> 00:00:44,520
authenticate.

7
00:00:45,670 --> 00:00:50,470
That type of authentication does not extend outside the eight.

8
00:00:50,470 --> 00:00:53,500
It is forest boundaries easily.

9
00:00:54,070 --> 00:01:04,480
You can implement trusts based on the Kerberos V5 Authentication Protocol or an integrated Windows authentication,

10
00:01:04,810 --> 00:01:09,250
which is RWA between two added Earth forests.

11
00:01:09,910 --> 00:01:18,280
However, client computers and domain controllers on both sides of the trust must communicate with domain

12
00:01:18,280 --> 00:01:25,510
controllers in the other forest to make decisions about authentication and authorisation.

13
00:01:26,140 --> 00:01:34,420
This communication requires network traffic that is sent on multiple boards, so this path must be open

14
00:01:34,630 --> 00:01:41,200
or no firewall for walls between the domain controller and the other computers.

15
00:01:41,770 --> 00:01:50,680
The problem becomes even more complicated when a user must access resources that are hosted in cloud

16
00:01:50,950 --> 00:01:55,750
based systems such as Microsoft Azure or Microsoft Office.

17
00:01:55,750 --> 00:01:56,800
365.

18
00:01:57,670 --> 00:02:05,080
Claims based authentication provides a mechanism for separating user authentication and authorization

19
00:02:05,380 --> 00:02:10,750
from individual applications with claims based authentication.

20
00:02:11,440 --> 00:02:20,230
A user can authenticate a directory service that is located within their organisation and be granted

21
00:02:20,230 --> 00:02:22,960
a claim based on that authentication.

22
00:02:23,650 --> 00:02:30,490
The claim is then presented to an application that is running in a different organisation.

23
00:02:31,840 --> 00:02:42,340
The application allows users the user access to information or features based on the claims presented.

24
00:02:42,880 --> 00:02:45,160
All communications or cures.

25
00:02:45,670 --> 00:02:56,470
Over age, it appears the claim that is used in claims based authentication is a statement about a user

26
00:02:56,770 --> 00:03:03,310
that is defined in one organisation or technology and trusted in another.

27
00:03:04,060 --> 00:03:07,600
The claim can include a variety of information.

28
00:03:07,870 --> 00:03:15,790
For example, the claim can define the user's email, address the user, principal name or a European

29
00:03:16,150 --> 00:03:20,470
account information about specific groups to which the user belongs.

30
00:03:21,160 --> 00:03:28,570
This information is collected from the identity store when the user successfully authenticates.

31
00:03:29,170 --> 00:03:37,780
The organization that manages the application defines the types of claims that the application will

32
00:03:37,780 --> 00:03:38,380
accept.

33
00:03:38,860 --> 00:03:48,250
For example, the application might require the user's email address to verify identity and then use

34
00:03:48,250 --> 00:03:57,490
the group membership that is presented inside the claim to determine what level of access the user will

35
00:03:57,490 --> 00:03:59,950
have within the application.

36
00:04:01,000 --> 00:04:05,800
Next up, we'll be talking about overview of Web services.