個人的に契約してるMS365テナントでの検証の話。
Azure ADとBoxのシングルサインオンとプロビジョニング設定をして、Azure ADのゲストでBoxにシングルサインオンできるか試していたらうまくいかなかった。
※ゲストはMSアカウントとメールベースOTPのこと（要は他社AADユーザーではないゲストのこと）
Boxサポート記事に沿って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サポート記事のここの部分
によるとhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressでメールアドレス渡せてるからいいのでは？と思ってたら、もうちょっと下の方にAzure（AD）の場合http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameを使うと書いてあった。
そこで、AzureAD側のBoxシングルサインオン（属性とクレーム）のところで、http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameを以下のように編集した。
自社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は消した。
無事ゲストでBoxにシングルサインオンできた。
補足として、MSのチュートリアル記事を見ると、属性とクレームの設定でuser.userprincipalnameではなくBoxの場合はメールアドレスにマップしろとある。そこまではBoxの記事と同じだが、nameではなくUnique User Identifier（一意のユーザーID）のほうを使うと言ってる。Unique User Identifierをメールアドレス（user.mail）にしてもSSOできなかった。MSの記事は誤りっぽい。
誤りあればご指摘ください。