Kasoukatoka

前回申し上げた通り、せっかく太っ腹なOkta Developers環境を使わせてもらっているのに、全然活用できていません。 Oktaのようなサービスを使ってすることの一つとして代表的なものといえば、シングルサインオン連携です。 今回は、Workspace ONE UEMの管理コンソールをSP、OktaをIdPとして、SAML連携を行い、管理者がWorkspace ONE UEMの管理画面にログインするときに、Oktaに認証されるように設定してみました。 ※なお、OktaにはSPメタデータのxmlファイルをパースしてくれる機能がなく、設定の際はSAML tracer片手に手探りでOkta上でカスタムアプリとしてWorkspace ONE UEMの情報を投入していきました。そのため、本ブログでは設定後の画面のスクリーンショットを掲載します。 参考情報： Is it Possible to Import Metadata Files in Okta for Custom SAML Applications Create a Basic Custom SAML Application Using SP Metadata File How to Download the IdP Metadata and SAML Signing Certificates for a SAML App Integration Simulate an SP-initiated flow with the Bookmark App The Unofficial Omnissa Products and Services Visio Stencil ①Okta側の設定 Okta側の設定では、何よりも先にOktaのIdPメタデータが欲しかったので、一度本当にでたらめな値でカスタムアプリを登録し、そのカスタムアプリを少しずつSAML-tracerなどで動作確認しながら設定変更していきました。 なお、そのままSAML連携をしただけでは、Workspace ONE UEMがSP initiatedのフローでしかログインできなくなるため、Bookmarkアプリ機能を用いて、IdP initiatedフローのような画面遷移となるように設定しています。 a.SAML連携用のカスタムアプリの設定 実際にSAMLによ...

私が個人的に使用させてもらっているOktaの検証環境ですが、せっかく太っ腹なDeveloper向け環境を手に入れたものの、そんなに今まで触ってこなかった（触りたくなったら会社の検証環境があるので困らなかった）ので、今後定期的に触れるように触れるようにしたいと思い、日記につけることにしました。 ※何か明確な目的があるわけではないので、日記に「徒然」とつけています。本当に徒然なるままにDeveloper環境をいじっています。 今回は、久々にログインしたOkta Admin Consoleのアクセスポリシーを変更してみたので、その設定方針と設定値を記録していきたいと思います。 ※個人の日記として作成しているため、正確な情報ではない部分があるかもしれませんが、ご容赦ください。 私の利用しているOkta Developer環境には、管理者アカウントが一つしかありません。 別に一つでも使えなくはないのですが、 アクセスポリシーの設定ミスでこの管理者アカウントがログインできなくなると" 詰み "です。 そして、現在の唯一の管理者アカウントでログインするためのアクセスポリシーを見たところ、"Okta recommends that you protect this app with phishing resistant policies"という文言が。一応2要素認証にしているものの、どうやらその認証方式がフィッシングに対してちょっと弱いんじゃないの？という指摘をされているようです。 なるべく早く変更した方がよさそうな気がするものの、失敗すると唯一の管理者がロックアウトされる状態です。 管理コンソールのログインのアクセスポリシーを変更するたびに、そんなスリルを味わいながら設定変更するのは嫌なので、新しく管理コンソールにアクセス可能なアカウントを作成することにしました。 ①まずはユーザーアカウントを作成しよう Oktaの管理者アカウントを作成するとき、まずもとになるユーザーアカウントを作成します。 Directory>People>Add personと進み、必要事項を記入します。Usernameは、メールアドレス形式である必要があります。 ②作成したアカウントにAdmin roleを割り当てよう 次に作成したアカウントを開いて、Ad...