メモなので、間違いなどあればコメントいただけると嬉しいです。
wikipediaより。
A principal in computer security is an entity that can be authenticated by a computer system or network. It is referred to as a security principal in Java and Microsoft literature.
Principals can be individual people, computers, services, computational entities such as processes and threads, or any group of such things. They need to be identified and authenticated before they can be assigned rights and privileges over resources in the network. A principal typically has an associated identifier (such as a security identifier) that allows it to be referenced for identification or assignment of properties and permissions.
コンピューターセキュリティおけるプリンパル（principal）とは、コンピューターシステムまたはネットワークによって認証可能なエンティティのこと。JavaやMicrosoftの語彙では、セキュリティプリンシパルと言われる。
プリンシパルは、個々の人間、コンピューター、サービス、プロセスやスレッドのようなコンピューター上のエンティティ、またはそれらの任意のグループである。プリンシパルがネットワーク内のリソースに対する権利や特権が割り当てられるには、まず識別および認証される必要がある。プリンシパルは一般的に関連する識別子（セキュリティ識別子）を持ち、これによってプロパティやパーミッションの識別または割り当てのためにプリンシパルが参照できるようになる。
アプリケーション（Application）は、Azure ADのアプリ登録（App Registration）で登録されるエンティティであり、 Application オブジェクトで表現される。アプリケーションは、ホームとなるAzure ADテナントに存在する。
サービスプリンシパル(Service Principal）は、アプリへのアクセスを管理者が承認（approve）するためのオブジェクトで、利用者たるプリンシパルが存在するテナントに作成される。ホームテナントでのみサービスプリンシパルを作成できるアプリケーションをシングルテナント、他のテナントでもサービスプリンシパルを作成できるアプリケーションをマルチテナントという。
以下のプロパティを見ればわかるように、作成者にしか定義できないものはアプリケーションにしかないし、利用側の組織のポリシーに関わるものはサービスプリンシパルにしかない。
| Application | ServicePrincipal | 説明 |
|---|---|---|
| appId | appId | アプリケーションのID。 |
| applicationTemplateId | ||
| appOwnerOrganizationId | アプリケーションのホームテナントのテナントID | |
| id | id | オブジェクトID |
| identifierUris | servicePrincipalNames | aud にも使われる、アプリ識別用の URI。 |
| servicePrincipalType | Application、ManagedIdentity、Legacy（互換性用）、SocialIdp（たぶんB2C用） | |
| createdDateTime, deletedDateTime | ||
| description, displayName | appDescription, appDisplayName | |
| logo, info, note | homePage, info, notes | |
| description | ここはサービスプリンシパルの説明 | |
| verifiedPublisher | ID、表示名、追加日時 を持つ | |
| addIns | addIns | |
| appRoleAssignmentRequired | ||
| disabledByMicrosoftStatus | ||
| loginUrl, logoutUrl | ||
| keyCredentials, passwordCredentials | keyCredentials, passwordCredentials | keyCredentialは種別と使用法を持つバイナリ。passwordCredentialはヒントを持つ文字列。いずれもID、名前、有効期間を持つ。 |
| groupMembershipClaims | アプリケーションがトークンの group クレームに入れてほしい AAD の各種グループの種類 | |
| optionalClaims | IDトークン、アクセストークン、SAML2トークンで返すクレーム audの形式をGUIDに固定する方法があることは覚えておくとよさそう | |
| appRoles | ||
| appRoles.allowedMemberTypes | ユーザー、グループ、アプリケーションのどれに割り当て可能か | |
| appRoles.{id, name, value, description, displayName} | ||
| requiredResourceAccess | ||
| requiredResourceAccess.resourceAppId | アクセス先リソース | |
| requiredResourceAccess.resourceAccess | ||
| requiredResourceAccess.resourceAccess.id | スコープオブジェクトかロールオブジェクトのID | |
| requiredResourceAccess.resourceAccess.type | idがスコープかロールか | |
| api | ||
| api.acceptMappedClaims | ||
| api.knownClientApplications | クライアントアプリを登録しておくと、クライアントアプリへの同意がこのサーバー側APIアプリの同意にもなる | |
| api.oauth2PermissionScopes | ID、種類、scp に入れたときの値、同意に関する説明や表示名 |
|
| api.preAuthorizedApplications | 管理者によってあらかじめ許可されたこのAPI呼び出し元 | |
| oauth2PermissionScopes | アプリケーションで指定した api.oauth2PermissionScopes の値 | |
| publicClient | ||
| publicClient.redirectUris | ||
| spa | ||
| spa.redirectUris | ||
| web | ||
| web.homePageUrl, web.logoutUrl, web.redirectUris | ||
| web.implicitGrantSettings | IDトークンとアクセストークンの発行が有効かどうか | |
| replyUrls | アプリケーションで指定した {publicClient | |
| preferredSingleSignOnMode, samlSingleSignOnSettings | ||
| oauth2RequiredPostResponse | ||
| isFallbackPublicClient | ||
| isDeviceOnlyAuthSupported | ||
| signInAudience | サインインで AAD と MSA のどちらを許すか。 | |
| parentalControlSettings |
- appRoleAssignment -> 割り当てられれているロール
- claimsMappingPolicy -> このSP向けに発行されるトークンのマッピング
- memberOf -> 割り当てられているグループ
- oauth2PermissionGrants -> 委任されたアクセス許可
- tokenLifetimePolicy -> トークン有効期間ポリシー
Azure CLIでコマンドを実行するためのサービスプリンシパルを作成し、サブスクリプションレベルの Contributor （共同作業者）RBACを与える。
特殊なサービスプリンシパル。 az identity コマンドで作成したりできる。
その資格情報は隠ぺいされており、マネージドIDが割り当てられたリソースが別リソースにアクセスする際に自動的に使用する。アプリから使う場合は、そのリソース上からのみアクセスできるリンクローカルアドレスに公開されたHTTP APIにアクセスして、OAuth2のアクセストークンとして取得し、Bearerトークンなどで送る（「など」と言っているのはRDBMSでも使えるから）
- システム割り当てはリソースと一緒に削除され、そのリソース専用である。したがって、リソースを認証したい場合に使う。ログとか。
- ユーザー割り当ては個別に割り当てることができる、複数のリソースに設定したり、同一リソースに複数割り当てたりできる。そのため、アプリなどリソースとは独立したものの認証に使う。DBアクセスとか。WindowsなWeb JobからLinuxのFunctionに移したり、ACIやAKSに動かすかもしれないし。多重防御の為に、アプリ内で読み取りRBACしかないIDと、書き込み権限のあるIDを使い分けるかもしれないし。