参考
SAML
【#27 SSO SAML】シングルサインオン セキュリティのお勉強 - YouTube
理解通り。
リバプロSSO
www.youtube.com
目からうろこ。
ケルベロス
www.youtube.com
わかりやすい。
Oauth2.0/OpenID Connectについて
参考
イメージ
OAuth2.0を図解してみた（解説） - YouTube
OAuthを分かりやすく解説（セキュリティ入門#7） - YouTube
OAuthとパスワード - インゲージ情報セキュリティ講座 - YouTube
踏み込む
ポイント
Oauth2.0は、サービス間でリソースへのアクセス権限の許可を行う仕組み
サービス間連携で必要な認証を、ID/パスワードのやりとり不要で実現
サービスはトークンにより、別サービスのデータへのアクセスが許可される。トークン取得時には認証/認可が必要。
例) 昨今のメーラーはID/PW保存しない実装がされてる。
認証、認可
OAuth & OIDC 入門編 by #authlete - YouTubeより引用
認可する前に、認証もされるケースが多い。
| 技術 | 標準化の範囲 | トークン |
|---|---|---|
| Oauth2.0 | 認可 | アクセストークン |
| OpenID Connect | 認証 | IDトークン |
アクセストークンの失効について
OAuth アクセストークンの実装に関する考察 - Qiita
失効のリアルタイム実装は難しい。
アクセストークンの有効期限を短くするのが妥当。
KeyCloakメモ
機能概要
②IDブローカリングとソーシャルログイン
SNSや既存のOpenIDConnectまたはSAML2.0IDプロバイダーによるユーザー認証が可能。
管理コンソールだけで設定可能
③ユーザーフェデレーション
既存のLDAPサーバーまたはActiveDirectoryサーバーと連携したユーザー認証が可能。
RDMBS等、他のユーザー情報ストアとの連携も独自プロバイダ構成により可能。
④クライアントアダプター
KeyCloakとの連携を容易にする為の、SP向けのライブラリ。さまざまなプラットフォーム、言語向けにあり。
SAML2.0とOpenID Connect用があり。
※ SAML2.0とOpenID Connectプロトコルに標準対応してる為、他ライブラリも利用可能。
⑤管理コンソール
全側面を一元管理
機能の有効/無効化、IDブローカリングとユーザーフェデレーションの構成
SPの作成・管理、承認ポリシーの定義
ユーザーの権限やセッション管理
等
⑥アカウント管理コンソール
ユーザーの自アカウントの管理機能
プロファイルの更新、パスワードの変更、および2要素認証の設定
セッション管理、アカウントの履歴表示
⑧承認機能
ロールベースだけでなく、個別のきめ細かい承認ポリシーも管理コンソールで定義可能。
リリース状況
参考サイトから引用
Mattermostメモ
URL
Product Overview — Mattermost documentation
Team Edition vs Enterprise - #3 by tomstieger - Mattermost Discussion Forums
Self-Managed Pricing - Mattermost - Open-source collaboration, self-managed or SaaS
メモ
導入パターン
①Mattermost Team Edition
オンプレ利用可能、MITライセンスで無償利用可能
②Mattermost Enterprise Edition
オンプレ利用可能、有償
③Mattermost Cloud
クラウドのみ、有償
Mattermost Team EditionとEnterprise Editionの違い
EnterPrise機能の利用可否。
Team Editionは利用孵化。EnterPrise機能は実装されてるが、有効化する機能がない。
Enterprise Editionは利用可能。ライセンスキー投入により、EnterPrise機能が有効化される。
無償で使う場合でも、Enterprise Editionの方が良い。
EnterPrise機能が必要になった段階で、EnterPrise機能をシームレスに有効化できる。
ライセンスキーを投入せず利用しても問題なし。
Mattermost Cloud
エンタープライス機能が利用可能。以下2タイプがあり
①Mattermost Cloud Professional
②Mattermost Cloud Enterprise
単一の顧客専用のAWSVPC内のプライベート環境にデプロイされる。
基盤のデプロイ・運用はMattermost社が専門家が実施。
Cookie実装メモ
ポイント
名前=値、属性で構成
状態を示す情報で、無差別に送信しない実装がある
Cookie入手元サイトには送信する
送信先をドメイン/パス指定属性で制限できる
例) https://example.com/loginでCookieを得た場合
Domain=example.com
※.example.comは送信、example.com以外のドメインには送らない。
Path=/
Cookie入手元サイト全体に送る。
サードパーティーCookie
アクセスしたドメインとは別のドメインから発行されたCookie
例)
アクセスしたコンテンツ内の別サイトの広告から得たCookie
1サイト内で、複数サイトのデータをビューする場合など、広告以外の用途で利用される場合もあり、ブラウザで無効化すると動作しないサイトもあり。
Httponly属性でJavaScriptによる送信を防ぐ(セキュリティ目的)
O365とDMARC認証
参考
スパム対策メッセージ ヘッダー | Microsoft Learn
DMARCとは？ | SendGridブログ
Define your DMARC record - Google Workspace Admin Help
https://www.iijmio.jp/guide/senderauth/
DMARC 詳細仕様-2 | なりすまし対策ポータル ナリタイ
ポイント
DMARCのDNSレコードの指定方法
https://support.qualitia.co.jp/s/article/000002563?language=ja
aspf、adkimでアライメントモード指定。未指定の場合、relaxed
pでポリシー指定 none等
spはサブドメインに別ポリシーを指定したい場合に利用。pと同じ書式。
→サブドメインにも影響与える。dmarc認証する時に、チェック対象ドメインのdmarcレコードを確認するが、定義ない場合に、親ドメインのdmarcレコードを見るフローがあるのだろう。
親ドメインにdmarcレコードあり＆spなしの場合
→pに従う
親ドメインにdmarcレコードあり＆spありの場合
→spに従う
ruaは認証結果全て、ruf認証失敗のみのレポート。大量メールが来る可能性あり。
構文チェックサイトあり
外部ウェブサイト）PowerDMARC： DMARCレコードチェッカーツール
外部ウェブサイト）MXToolBox：DMARC Check Tool
DMARCアライメントとは
https://baremail.jp/blog/2023/09/26/3474/
チェックの厳しさ
以下2種類あり
relaxed
ヘッダFromの組織ドメインと、SPFやDKIMで認証したドメインが同じなら成功。サブドメインを利用していても一致とみなす
strict
ヘッダFromのFQDNがSPFアライメントの場合はReturn-Path（エンベロープFrom）と、DKIMアライメントの場合は署名ドメインが完全に一致
組織ドメインの定義があるのだろう。
fromアドレスのドメイン部分=組織ドメインではないのだろう。
fromアドレスのドメイン部分=ヘッダFromのFQDN
なのだろう。
https://eng-blog.iij.ad.jp/archives/3273
やっぱりそうだ。
ポイントとしては
relaxedは組織ドメインで評価しサブドメインマッチを許可、restrictはfromヘッダなドメインと完全マッチと覚える
