IDaaSとSASE/CASBの蜜月：SAMLとOIDCで紐解く「ゼロトラストのID基盤」
ネットワークエンジニアの皆さん、こんにちは。境界防御という「城壁」が崩れ去り、クラウドとモバイルが主役となった現代において、我々が守るべきものはもはやIPアドレスではなく「ID」そのものです。
ゼロトラストアーキテクチャにおいて、SASE（Secure Access Service Edge）やCASB（Cloud Access Security Broker）がいくら強力なインスペクション機能を持っていても、その入り口である「誰がアクセスしているのか？」というIDの信頼性が揺らいでいれば、すべては砂上の楼閣です。
今回は、IDaaS（IdP）とSASE/CASBを連携させるための要、SAML 2.0とOIDC（OpenID Connect）の認証フローについて、現場で泣きを見た経験も交えながら深掘りしていきましょう。
—
なぜ「認証連携」がSASEの生命線なのか
SASEやCASBのポリシーエンジンは、ユーザーがアプリケーションへアクセスする際、単に「認証済みか」を見るだけではありません。「どのデバイスからか」「どの場所からか」「どの時間帯か」といったコンテキストを統合的に判断します。
ここで重要になるのが、IdPからSASEへ渡される「アサーション（主張）」です。SAMLであれば SAML Assertion、OIDCであれば ID Token に含まれるクレーム（属性情報）が、SASE側のアクセス制御ポリシーを動かすエンジンとなります。
—
1. SAML 2.0：エンタープライズの古き良き（しかし堅牢な）守護者
SAMLは、XMLベースのプロトコルです。やや冗長ですが、大規模なエンタープライズ環境では、その堅牢さゆえに今なおデファクトスタンダードです。
SAMLの認証フロー（Service Provider Initiated）
1. Request: ユーザーがSASE（SP）にアクセス。SASEは AuthnRequest を生成し、ユーザーをIdPへリダイレクト。
2. Authn: ユーザーがIdPで認証（MFAなど）。
3. Response: IdPはブラウザ経由でSASEに SAMLResponse（Base64エンコードされたXML）をPOST。
4. Validation: SASEはデジタル署名を検証し、属性を取り出す。
実務Tips：デバッグの基本
SAMLのトラブルは、大抵の場合「証明書の不一致」か「時刻のズレ」です。ブラウザのデベロッパーツールで SAMLResponse を拾い、以下のツールでデコードして中身を確認するのが鉄則です。
# SAMLResponseをデコードして整形する（Pythonワンライナー例）
echo "PHNhbWxwOl..." | base64 -d | xmllint --format -
# これで、Subject（ユーザーID）やAttributeStatement（部署名など）が正しく飛んでいるか確認します—
2. OIDC：モダンなWeb API時代の申し子
OIDCはOAuth 2.0の上に構築されたアイデンティティレイヤーです。JSON（JWT）を扱うため、モバイルアプリやモダンなWeb APIとの相性が抜群です。
OIDCのシーケンス例
SASEのバックエンドでOIDCフローを処理する場合、以下のように token エンドポイントを叩くのが一般的です。
import requests
# IdPのトークンエンドポイントへコードを送信し、IDトークンを取得する
payload = {
'grant_type': 'authorization_code',
'code': 'ユーザーがリダイレクトで受け取ったコード',
'redirect_uri': 'https://sase.example.com/callback',
'client_id': 'your_client_id',
'client_secret': 'your_client_secret'
}
response = requests.post('https://idp.example.com/oauth/token', data=payload)
id_token = response.json().get('id_token')
# このid_tokenをデコードすると、ユーザーのメールアドレスやロールがJSONで取得できる
print(id_token)—
3. 実践：属性マッピングとポリシー制御
SASE側で「特定の部署（例：DevOps）の人間だけが、AWSのコンソールへアクセス可能にする」といったルールを設定する場合、IdPから送られてくる属性を正しくマッピングする必要があります。
設定のポイント
- NameID: ユーザーを一意に識別するID。メールアドレスを使うのが一般的ですが、変更可能性を考慮して
Immutable IDを使うのが安全です。 - Groups: 権限管理に直結します。IdP側で
groups属性を付与し、SASE側でその値をパースしてACLを動的に生成します。
もし、トラブルシューティング中に「認証は通るのにポリシーが適用されない」という事象に遭遇したら、まずIdPから出力されている Claims をログで確認してください。Groups が配列（Array）で来ているのか、単一の文字列で来ているのか、この「型」の不一致が運用現場では最も多い落とし穴です。
—
最後に：エンジニアへのメッセージ
SAMLやOIDCの仕様書は確かに退屈で、RFCのページをめくるだけで眠くなるかもしれません。しかし、これらはゼロトラストという巨大なパズルを完成させるための「接続コネクタ」です。
コネクタの規格が合わなければ、どんなに素晴らしいSASEの機能も宝の持ち腐れ。現場で苦労した分だけ、そのパケットが通る道のりが見えてくるはずです。「なぜ動かないのか」ではなく「認証のどのフェーズで期待値とズレが生じているのか」を、シーケンス図を描きながら冷静に追ってみてください。
皆さんのネットワークが、今日も安全であることを願っています。それでは、また現場でお会いしましょう。
コメント