追記

雑記帳


2018-03-13 (Tue) [長年日記]

[AWS] SAMLで認証しているユーザーの権限でAWS CLIを実行する

AWS Management ConsoleにFederated Userでログインを設定した場合には、IAM Userと違って、永続的なAccess Key Idを発行することができない。こういった場合には、STS (Security Token Service)を使って、一時的セキュリティ認証情報を取得する必要がある。

SAMLを使った場合は、AssumeRoleWithSAMLというAPIを使うのだが、そのままAWS CLIを使って手で実行するのは困難である。ということで、ツールを作ろうかと思ったのだが、さすがにすでに存在していたので、それを紹介する。

saml2aws

saml2aws は、いくつかのSAML IdPに対応したTemporary credentialsを取得するツールである。対応しているIdPは以下の通り。

  • ADFS (2.x or 3.x)
  • JumpCloud
  • KeyCloak + (TOTP)
  • Okta + (Duo, SMS, TOTP)
  • PingFederate + PingID

それでは早速使ってみたい。

インストール

macOSの場合は、homebrewに対応している。

 $ brew tap versent/homebrew-taps
 $ brew install saml2aws
設定

PingOneで実行したかったのだが、未対応なのでOktaでやってみる。

 $ saml2aws configure

 Please choose the provider you would like to use:

 [ 0 ]:  ADFS

 [ 1 ]:  ADFS2

 [ 2 ]:  JumpCloud

 [ 3 ]:  KeyCloak

 [ 4 ]:  Okta

 [ 5 ]:  Ping

 Selection: 4

 URL []: https://<your_org>.okta.com/home/amazon_aws/deadbeaf/123
 Username []: <your_account>

 Configuration saved for IDP account: default

ここで入力するURLは、Oktaの場合だと、UserHomeに表示されるAWSにサインインするためのURLで良い。 Usernameは、Oktaにサインインするときに使うものを入れる。

設定はこれだけ。

認証

では、認証トークンを得るために、AWSにサインインしてみよう。

 $ saml2aws login
 Using IDP Account default to access Okta https://<your_org>.okta.com/home/amazon_aws/deadbeaf/123
 To use saved password just hit enter.
 Username [<your_account>]:
 Password: ***************

 Authenticating as <your_account> ...

   1) PUSH MFA authentication
   2) UNSUPPORTED: OKTA TOKEN:SOFTWARE:TOTP

 Select which MFA option to use: 1

 Waiting for approval, please check your Okta Verify app ............ Approved

 Selected role: arn:aws:iam::000000000000:role/<role>
 Requesting AWS credentials using SAML assertion
 Logged in as: arn:aws:sts::000000000000:assumed-role/<role>/<role_session_name>

 Your new access key pair has been stored in the AWS configuration
 Note that it will expire at 2018-03-12 19:25:04 +0900 JST
 To use this credential, call the AWS CLI with the --profile option (e.g. aws --profile saml ec2 describe-instances).

OktaでMFAを有効にしているため、MFA optionを選ぶように促される。ここでは、PUSH MFA authenticationである1を入力し、MFAを実行している。認証に成功すると、expireされる時刻が表示され、aws --profile samlと指定するとAPIが実行できると表示された。

AWS CLI実行

では、AWS CLIを実行してみよう。

 $ aws --profile saml sts get-caller-identity
 {
     "UserId": "ABCDEFG12345ZXYW9876S:<role_session_name",
     "Account": "000000000000",
     "Arn": "arn:aws:sts::000000000000:assumed-role/<role>/<role_session_name>"
 }

assumed-roleの権限で、APIを実行していることが確認できた。

ここで、AWS CLIが利用している認証情報を確認してみる。

 $ cat ~/.aws/credentials
 (snip)
 [saml]
 aws_access_key_id     = ABCDEFG12345ZXYW9876S
 aws_secret_access_key = T5on5Z...1wJrtp
 aws_session_token     = FQoDYX...dd1QU=
 aws_security_token    = FQoDYX...dd1QU=

samlというprofileが自動的に更新されているのが確認できる。aws_access_key_id以外は長いので省略しているが、これがSTSのAPIである、AssumeRoleWithSAMLを実行して得られた認証情報である。

対応しているIdPが限られているが、これはかなり便利だと思う。


2018-01-28 (Sun) [長年日記]

[GTD] 今年登場するOmniFocus 3は刷新されるようなので新機能をまとめた

The Omni Blogで、2018年のロードマップが公開された。

中でも特に、OmniFocusはバージョン3で刷新されるとのことで、どのように変化するのかが詳しく書いてあった。自分も長く使っている中で、不満に思っていたことが、かなり解消されるようなので、超うれしい!ということで、ちょっとまとめてみた。

コンテキストからタグに変更

従来は、GTDで言うところのコンテキストは、一つのタスクに対して一つしか設定できなかった。OmniFocus 3では、コンテキストはタグに置き換わることで、一つのタスクに複数のタグを設定できる。

自分もこれまで、複数のコンテキストを設定したいと思っていたので、これは嬉しい。

手動での並び替え

コンテキスト内のタスクの並び順ついて、これまでは自動的に順番が決まっていて、並び替えはできなかった。タグごとのリストでは、任意に順番を変更できるようだ。

これも地味に嬉しい。コンテキストが一つしか使えなかったと同様に、これも使いづらかった要因だったかと思う。その辺りが理由でコンテキストをうまく使えていなかったので、ここが改善されたらさらに便利になりそう。

柔軟なスケジューリング

これについては、どう変わるのかがよく分からなかったんだけど、特に繰り返しに関するタスクのスケジューリングが柔軟にできるようになるようだ。

これまでは、タスクの開始と期限しか設定できなかった。これについては、実際に触ってみたら良さを実感するだろうと思う。

柔軟性のある通知

これまでは、期日に達した時と、位置情報に基づくコンテキストの通知がされていた。

また、複数のタスクが同時に通知された時には「他3件」のようにまとめて通知されていた。この場合は、いちいち詳細を確認する必要があった。

iOSの新しいリッチな通知をサポートするようになったため、位置情報に基づく場合に地図が表示されたり、複数のタスクがリストで表示されるようになった。

さらに細かい通知の設定ができるようなるようだ。

複数のタスクが通知される時に、リストが見られるようになったのが特に嬉しい。

デザイン

iOS 7からのフラットデザインに対応していたが、よりよくリデザインされたようだ。

また、ドラッグ&ドロップに対応して、iPadとかでもタスクの移動がやりやすくなったりするようである。

強力な自動化

JavaScriptに対応した自動化がサポートされる。フィルタリング、レポート作成、テンプレートを使ったコンテンツの作成などができるようだ。

これまで自動化は使ったことはなかったが、機会があれば使ってみようと思う。

コラボレーション

これまでは個人で使うことが前提になっていたため、タスクを共有するような機能はなかった。

OmniForcus 3では、それぞれ個別に所有している別々のデータベース間でのリンクする機能が追加される。タスクがリンクされていると、それぞれのタスクのステータスを確認できるとのとこ。

これも便利そうだ。自分は自分がやらないといけない家事のタスクを管理しているが、これを家族内で共有したいと思うことはよくあったので、ぜひ活用したい。

OmniFocus for The Web

簡易的なビューがWebブラウザで提供される。これはアプリ版のOmniFocusを使っている人向けに、Windowsなどの未対応デバイスでタスクを確認したりするのに使えるもの。 いざという時に使えそうだ。

以上、OmniFocus 3の新機能をざっとまとめてみた。TestFlightもされるようなので、積極的にフィードバックしたいと言う人は登録するのがいいと思う。


2017-12-20 (Wed) [長年日記]

[AzureAD][SSO] Workplace by Facebookを一斉展開する

Facebookによる企業向けのSNS、Workplace by Facebook(以下、WF)というものがある。企業向けSNSということなので、当然ID Providerと連携してSSOすることができる。

今回は、Azure ADをID Provider(IdP)を使い、自動ユーザー登録とSSOを使ったログインができるように構成する。WFはギャラリーに存在するので、そこから追加すれば良い。

なお、今回はSSOとプロビジョニング設定が主眼なので、WF自体の開始方法は説明しない。すでに利用開始できているものとする。

WFの設定情報の取得

社内ダッシュボードの認証設定画面で、LoginをSSOにすると、設定画面が開く。下記の情報が表示されるので、それをメモる。Azure AD側の設定をする際に必要となる。

  • オーディエンスURL
  • 受信者のURL
  • ACS (Assertion Consumer Service) URL

Azure AD側の設定

Azure ADのWorkplace by Facebookを開き、下記の設置を行う。

シングルサインオンの設定
シングルサインオンモード
SAMLベースのシングルサインオン
サインオンURL
WFの組織トップURL(https://<organization>.facebook.com/)
識別子
先にメモしたオーディエンスURL
SAML証明書
自動的に作成されているのでダウンロードする
通知用メールアドレス
証明書が切れそうな時に通知欲しいメールアドレス

そして、最下部に[Workplace by Facebookの構成]があるので、クリックして情報を表示する。下記の情報をメモる。

  • Azure AD Single Sign-On Service URL
  • Azure AD SAML Entity ID

[Download Azure AD Signing Certificate (Base64 encoded)]というリンクから、証明書をダウンロードする。

WF認証の設定

WF側のSSOの設定をする。社内ダッシュボードの認証ページを開き、下記の項目を埋める。

SAML URL
先にメモしたAzure AD Single Sign-On Service URL
SAML Issuer URI
先にメモしたAzure AD SAML Entity ID
SAML証明書
ダウンロードした証明書の内容をテキストで貼り付ける

ここまで設定したら、[SSOをテスト]ボタンを使って設定が正しいのかのテストができる。押してみて正しく動作しているかを確認する。

ここまでの設定で、WFにすでに登録されているユーザーは、SSOができるようになっているので、確認すると良い。

メンバー追加の設定(プロビジョニング)

SSOの設定ができても、WFに登録されていないメンバー(ユーザー)は、ログインすることができない。メンバーアカウントをWFに自動的に登録する必要がある。

ここでは、Azure ADにあるプロビジョニング機能を使ってユーザーの登録や削除を実施する。WFと同期するメンバーは、先ほど作成したグループのメンバーとなる設定を行う。

アプリの登録

WFの社内ダッシュボードにある、[統合]を開き、[カスタム統合]を選択する。[+カスタムアプリを作成]を押す。

カスタムアプリの名前と説明に、 任意の値を入力する。

アクセス許可に、[グループの管理]と[アカウントを管理]にチェックを入れる。

[アクセストークン]ボタンを押して、アクセストークンを取得する。

[保存する]お押して、データを保存する。

プロビジョニングの設定

WFのプロビジョニングを開く。プロビジョニングモードを[自動]にすると、設定項目が表示される。下記の項目に値を入れる。

シークレットトークン
先ほど取得したアクセストークン
テナントのURL
https://www.facebook.com/scim/v1/

[テスト接続]を押して、問題ないか確認する。問題なければ、一旦[保存]する。

[プロビジョニング状態]を[オン]に変更し、[保存]すると、同期が開始される。

同期の状態は、監査ログに出力されるので、そこを確認するといい。

ユーザーの招待

プロビジョニングができたら、自動的にユーザーの登録は実施されるが、まだユーザーはログインすることはできない。利用できるようになるには、招待メールを送信しなければならない。

実はここに罠がある。SSOで構成していると、プロビジョニングされたユーザーに自動的に"Confirm your email for Workspace"という件名のメールが送信される。しかし、そのメールだけではサインインすることができない。サインインするためには、管理者によって、招待メールの送信が実施される必要がある。

社内ダッシュボードにアクセスすると、まだ招待されていないユーザーに招待メールを一斉に送信するボタンがあるので、それを押せば良い。

補足

プロビジョニングをする際には、対象となるユーザーの絞込みが必要になることが多いと思う。その場合は、プロビジョニングのマッピングの設定を使って、対象となるオブジェクトのフィルタができるようだ(未検証)。

また、Azure ADにある情報から、WFに同期する情報の属性マッピングもできるので、ADに有用な情報が含まれている場合は、ここの設定を活用すると便利だろう。