Azure ADのゲストでBOXにSSOするときの属性マッピング

個人的に契約してるMS365テナントでの検証の話。
Azure ADとBoxのシングルサインオンとプロビジョニング設定をして、Azure ADのゲストでBoxにシングルサインオンできるか試していたらうまくいかなかった。
※ゲストはMSアカウントとメールベースOTPのこと（要は他社AADユーザーではないゲストのこと）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/95f0667c-1b9b-d85b-3ceb-a1e49e47da91.png)
[Boxサポート記事](https://support.box.com/hc/ja/articles/360043695094-SSO%E9%96%A2%E9%80%A3%E3%81%AE%E5%95%8F%E9%A1%8C%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E7%94%A8%E3%81%ABSAML-Trace%E3%82%92%E5%8F%8E%E9%9B%86%E3%81%99%E3%82%8B)に沿ってSAML Tracerで見てみたら怪しいところがあった。※メールアドレスはダミーです。
```
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
                <AttributeValue>test_tailspintoys.com#EXT#@contoso.onmicrosoft.com</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
                <AttributeValue>test@tailspintoys.com</AttributeValue>
            </Attribute>
```
ここの部分でBoxに2種類のメールアドレスを渡している。AzureADからプロビジョニングしたBoxユーザーは`tailspintoys.com`なので`contoso.onmicrosoft.com`のほうが悪さしてそう。

[Boxサポート記事](https://support.box.com/hc/ja/articles/360043696514-Enterprise%E3%81%A7%E3%81%AE%E3%82%B7%E3%83%B3%E3%82%B0%E3%83%AB%E3%82%B5%E3%82%A4%E3%83%B3%E3%82%AA%E3%83%B3-SSO-%E3%81%AE%E8%A8%AD%E5%AE%9A)のここの部分
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/26f3edfc-472b-30d7-3e92-79a6587589ed.png)
によると`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`でメールアドレス渡せてるからいいのでは？と思ってたら、もうちょっと下の方にAzure（AD）の場合`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`を使うと書いてあった。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/0b0d7533-36b7-38f3-fbae-77054b031990.png)
そこで、AzureAD側のBoxシングルサインオン（属性とクレーム）のところで、`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`を以下のように編集した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/6f086eca-c44d-978f-7064-e473e8129c9b.png)
自社AzureADユーザーについては、`user.userprincipalname`がメールアドレスに一致してるのでそれを返して、ゲストの場合は`user.mail`でメールアドレスを返すようにした。
なお今回試したゲストは、MSアカウントとメールベースOTP（ワンタイムパスワード）ユーザーなので、要求条件のユーザータイプは`すべてのゲスト`ではなく`外部ゲスト`にすれば十分。その場合、ゲストが他社AADユーザーのケースが漏れてしまうので、ユーザータイプ`AADゲスト`で値を`user.userprincipalname`にする。他社AADユーザーの場合、UPNは他社テナント側のものが使われるので結果的にメールアドレスと同じことになる。`user.localuserprincipalname`が招待元テナントでのUPNになる。
どのケースでもUPNがメールアドレスを返さないことがあるようなら、要求条件のところで条件わけせずに最初からシンプルにソース属性を`user.mail`にしておくのが無難。
最後に、使ってなくて紛らわしいので
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`は消した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/9a014682-0dd5-6bbf-ee0e-13c74eedc40a.png)
無事ゲストでBoxにシングルサインオンできた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/57d41c12-335d-72ff-c91e-7d974e8281fe.png)

補足として、MSの[チュートリアル記事](https://learn.microsoft.com/ja-jp/azure/active-directory/saas-apps/box-tutorial)を見ると、属性とクレームの設定でuser.userprincipalnameではなくBoxの場合はメールアドレスにマップしろとある。そこまではBoxの記事と同じだが、`name`ではなく`Unique User Identifier`（一意のユーザーID）のほうを使うと言ってる。`Unique User Identifier`をメールアドレス（user.mail）にしてもSSOできなかった。MSの記事は誤りっぽい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66591/f6ed37de-f531-d2ec-7cdb-0c542141ba61.png)
誤りあればご指摘ください。