SaaS

Slackの氏名を漢字表記にしようとしたらOkta SSOが邪魔をしてきた件

どーもたつみんです。今日もOktaネタです。

Slackってみなさん使ってますか?Oktaと連携してSAMLしてる?プロビジョニングもやってる?

今日はお客様からのご相談でOktaと連携済みのSlackの氏名を漢字表記にできないか?という内容に手こずった話を記事にします。

マッピングの設定変えたらいけるやろーって安易に思っていた自分が恥ずかしい…

今回の課題の確認

まず現状ですが、OktaのユーザープロファイルのFirst name(名前)およびLast name(苗字)に漢字で氏名が入力されています。

そうするとSlack上ではFirst name Last nameの並びで反映されます。つまり名前 苗字という順番の表記となり、日本人にとって違和感を感じる形式となります。

2バイト文字の扱いについて

ユーザープロファイルのFirst name(名前)およびLast name(苗字)はさまざまなSaaSに対して反映される部分であるため、いわゆる2バイト文字を利用することは避けておくのが無難です。おとなしくローマ字表記にしておきます。

では漢字はどこに格納したらいいかというと、Profile Editorからカスタム属性として作成してみました。表示名はsei-jpとmei-jpとなっていますが、内部的な項目名はuser.seiとuser.meiとして作成しました。

ユーザープロファイルに戻り、作成したカスタム属性に対して値を設定します。

最初に試したこと

これらのカスタム属性をSlackアプリケーションのプロビジョニング設定に対してマッピングしてあげればあっと言う間に解決するはず!さぁやってみよう!

下記のようにマッピング設定でFirst nameに対してカスタム属性のuser.sei(苗字)をLast nameに対してカスタム属性のuser.mei(名前)を設定します。

本来の意味とは異なる組み合わせですがSlackの氏名はFirst nameとLast name半角スペースで連結したものが反映されるため致し方ありません。

最後に設定を反映させるためにForce Syncを実行します。

この方法ではダメでした

この方法ではForce Syncを実行した直後は期待した動作となりましたが、ユーザーがSSOつまり新たな認証が実行されたタイミングで氏名はローマ字表記に上書きされる挙動となりました。

原因

よくよく調べてみると以下のことがわかりました。
OktaにはApp Catlogという主要なSaaSとの連携を行うためのテンプレートがあります。Slackのテンプレートの場合、SSO機能の中でユーザーが変更できない設定として、First nameおよびLast nameをSlackの氏名に渡す指定がされていました。

この設定があるためにSSOが実行されるとせっかくプロビジョニングでマッピング設定の値をさらに上書きされてしまうという挙動となってしまいます。

解決方法

ではどうするかというと、SSO設定を行う場合にOktaが用意したテンプレートを使わずに、ゼロベースでアプリケーションを構成します。プロビジョニング設定についてはテンプレートから作成した既存のアプリケーションを活用します。結果としてSlackはSSO用とプロビジョニング用の2つのアプリケーションを作成しそれぞれ設定を行います。

手順

新規SSO設定用アプリケーション構成

  1. Create App IntegrationからSAML2.0を選択し、Nextをクリックします。


  2. アプリ名とロゴを設定します。
  3. SAML Settingsの各項目を以下の値で設定します。
    Single sign on URLには、https://<yourdomain>.slack.com/sso/saml(Enterprise Gridの場合はOrgレベルのURL https://<yourdomain>.enterprise.slack.com/sso/saml を指定します)
    Audience URIにはhttps://slack.com
    Name ID formatにはPersistent
    Application usernameにはOkta username
    Attribute StatementsでNameにはUser.Emailを、Valueにはuser.email
  4. Preview the SAML Assertionをクリックし、エラーが発生していないことを確認後にNextをクリックします。
  5. Are you a customer or partner?にI’m an Okta customer adding an internal appにチェックを入れ、Finishをクリックします。
  6. Sign OnのタブでView Setup Instrucitonsから新たな設定値を確認します。
  7. SlackのSSO設定画面を開き、6.で確認した値をフォームに入力します。
  8. 以下のようにSlack上でテストを行い問題ないかを確認します。
    🚨注意🚨
    この時点で「更新を確認する」はクリックしないでください。クリックすることで既存のアプリケーションから新規作成したアプリケーションへ認証が切り変わるためです。テスト完了後にOkta側で新規作成したアプリケーションにユーザーをアサインしたあとで切り替えを行う必要があります。
  9. テストで問題がない場合は今回作成したアプリケーションに対象ユーザーをアサインします。
  10. アサインを確認したのちに、更新を確認するをクリックします。
    🚨注意🚨
    更新を確認するをクリックすることで設定を適用されます。これによりSAML2.0設定が既存アプリケーションから新規作成したアプリケーションに切り替わります。既存アプリケーションのSSO設定を変更する必要はありません。

既存アプリケーションをプロビジョニング用途へ変更

  1. 既存作成済みのSlackアプリケーションのGeneralタブに移動します。
  2. Applicatin labelをSlack Provisioning Onlyなどわかりやすい名前に変更します。
  3. また、このアプリケーションはユーザーダッシュボードに表示させる必要はありませんので、Application visibilityのDo not display application icon to usersにチェックを入れSaveをクリックします。
  4. Provisioningタブに移動し、OktaからSlackに対するAttribute MappingのFirst nameおよびLast nameを任意のAttributeに変更します。
    Slack上の氏名はAttributeのFirst nameとLast name半角スペースで連結したものが反映されます。今回は漢字で苗字 名前の並びにするために通常の意味とは逆になりますが、First nameにuser.seiをLast nameにuser.meiを指定しています。
  5. Force Syncをクリックします。
  6. Slack上で氏名が以下のように漢字表記で性 名の順番で表記されているかを確認します。
  7. OktaダッシュボードからSSO認証を実行し、新たな認証が実行された場合でも氏名が上書きされないことを確認します。
任意指定したAttributeに値が入っていない場合

これまで通りOktaのUser ProfileにあるFirst nameおよびLast nameが反映されます。

解説

原因の部分で下記のような記載をしました。これは具体的にどこから確認したかについて解説します。

OktaにはApp Catlogという主要なSaaSとの連携を行うためのテンプレートがあります。Slackのテンプレートの場合、SSO機能の中でユーザーが変更できない設定として、First nameおよびLast nameをSlackの氏名に渡す指定がされていました。

Slackテンプレートを使用した場合

テンプレートから作成したアプリケーションであるSlack Provisioning OnlyのSign OnタブのSettingsからEditをクリックして編集状態にし、Preview SAMLをクリックします。

別タブで下記のような内容が表示されます。

この中で下線を引いた内容がSSO時にSlackに渡される属性値です。User.Email,first_name,last_name,User.Usernameの4つが渡されていることがわかります。

これら4つの属性値は下記のSlackのSAMLに関する資料についても記載されています。しかし必須の属性値はUser.Emailのみです。

ゼロベースで作成したアプリケーションの場合

今回テンプレートを使わずにゼロベースで作成したアプリケーションの場合についても、どのような属性値がSlack側に渡されているのかについても確認してみたいと思います。

こちらはGeneralタブからSAML SettingsのEditをクリックします。General Settingsの画面をNextで進めて、Configure SAML画面を表示します。

Preview the SAML Assertionをクリックします。

こちらも 別タブで下記のような内容が表示されます。 こちらはUser.Emailのみが渡されていることがわかります。

まとめ

今回の課題はプロビジョニングでのマッピングさえ実施すればできるはずだという思い込みがあり、なかなか解決方法までたどり着くことができず苦戦しました。また、プロビジョニング時とSSO認証時という条件で挙動が変わることでも混乱もしましたが、逆にそこが糸口となり解決に近づくことができました。

今回の事例はOktaのApp Catalogにあるテンプレートが良かれと思ってやっている設定が邪魔してしまう場合があるという稀なケースのように思います。

今後もSSO時にどのような挙動となっているかは、Preview SAMLで確認してみるというのを覚えておくと役に立つ機会がありそうですね。

それでは今日はこのあたりで〜👋

たつみん

事業会社の情シスからクラウドネイティブにJoin!
好きなものはF1海外観戦とベルギービール!
集中力の質は深く長く遅い典型的なシングルタスクタイプです。