追記

雑記帳

2018-12-07 (Fri) [長年日記]

■ GoogleのセキュアLDAPを使ってPingFederateによる認証をする

セキュアLDAPとは、つい先日リリースされたばかりの、GoogleのCloud Identityまたは、G Suiteに対して、LDAPプロトコルを使って接続できるサービスのこと。

Ping IdentityのIdP製品である、PingFederateから、セキュアLDAPが使えるか試してみる。

Cloud Identity

Cloud Identityとは、GoogleのIDaaSで、企業向けモバイル管理（EMM）サービスのこと。 FreeとPremiumがあり、セキュアLDAPを使うには、Premiumが必要となる。

Freeは、G Suiteを使わないユーザーを管理するのに使うことができる。 GCPを使う開発者向けに、IDを発行し、ID統制できるようになる。

また、G Suite Enterpriseを使っている場合も、セキュアLDAPを使うことができる。 セキュアLDAPを使いたい場合、Cloud Identityを使った方がコスト面では有利なので、このためだけにG Suite Enterpriseにする必要はない。

Cloud Identity Premiumを有効にする

今回は、すでにG Suiteを使っているドメインでPremiumを有効にする。まだFree版も利用していない。

G Suiteの管理コンソールの「お支払い」から、Cloud Identity Premiumの有効化を実施する。 14日間の無料試用ができるので、そちらを選ぶ。

有効化が完了したらライセンスの割り当てをする。割り当て方法については、下記のドキュメントを参照のこと。

LDAPクライアントを追加する

セキュアLDAPに接続するためのLDAPクライアントを、Googleに追加するする必要がある。

アクセス権限を設定する

LDAPクライアントが、どんな情報にアクセスできるのかの権限を設定する。 今回は、PingFederateが認証に使うData Storeとして利用する想定なので、全て許可する。

  • ユーザー認証情報の確認
  • ユーザー情報の読み取り
  • グループ情報の読み取り

証明書をダウンロードする

自動的に証明書が生成されるので、ダウンロードする。

LDAPクライアントをオンにする

Googleの管理コンソールで、サービスをオンにする。

LDAPクライアントを設定する

PingFederateを使う場合は、証明書を使った認証が利用できない。そのため、stunnelを使う。

stunnelのインストールと設定

今回の環境は、CentOS 7を利用している。yumでインストールする。

# yum install stunnel psmisc

Googleから取得した証明書をサーバーの/etc/stunnelに配置する。 それぞれ、google-ldap.crtとgoogle-ldap.keyとする。

/etc/stunnel/stunnel.confとして、下記の内容の設定ファイルを作成する。

[ldap]
client = yes
accept = 127.0.0.1:1636
connect = ldap.google.com:636
cert = /etc/stunnel/google-ldap.crt
key = /etc/stunnel/google-ldap.key

stunnelをサービスとして、systemdに登録する。 /etc/stunnel/stunnel.confとして、下記の内容のファイルを作成する。

[Unit]
Description=SSL tunnel for network daemons
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=stunnel.target

[Service]
Type=forking
ExecStart=/usr/bin/stunnel /etc/stunnel/stunnel.conf
ExecStop=/usr/bin/killall -TERM stunnel

# Give up if ping don't get an answer
TimeoutSec=600

Restart=always
PrivateTmp=false

systemdに登録する。

# systemctl start stunnel.service
# systemctl enable stunnel.service
PingFederateを設定する

PingFederateからstunnelを経由してセキュアLDAPに接続する設定をする。

Data Storeを作成する

Data Storeを作成して設定する。

  • Hostname(s): localhost:1636
  • LDAP Type: general
  • Bind Anonymously: チェックする

設定を保存する。

LDAP PCVを作成する

LDAP Username Password Credential Validatorを作成し設定する。 設定値は、Googleのドキュメントを参考にする。

  • LDAP Datastore: 作成したData Store
  • Search Base: DC=example,DC=com
  • Search Filter: mail=${username}

あとは、IdP AdapterでこのPCVを使うように設定すれば良い。

まとめ

テストしたところ、認証する際に気持ち時間がかかるか？という感じだが、特に問題なく利用できた。

今更LDAP？と思う向きは少なくないと思う。しかし、統合認証を実現しようとすると、LDAPが不要になる世界は、まだ来そうにないのが実情だ。

統合認証と言えば、ほとんどのケースでActive Directoryがデファクトスタンダードになっている。そして、昨今のスタートアップ企業は、今さらActive Directoryを管理・運用したくないという話はよく聞く（自分もそう思う）。そして、そういう企業は大抵の場合、G Suiteを契約してメールはGmailを使っているのだ。

そんな場合に、セキュアLDAPは有力な選択肢になる。

[ツッコミを入れる]

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もされるようなので、積極的にフィードバックしたいと言う人は登録するのがいいと思う。

[ツッコミを入れる]
書いてる人:むらまさ muramasa64 at gmail.com
Twitter

前 2018年
12月		 次
日 月 火 水 木 金 土
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

最新コメント:

  1. Carlos (08-11)
  2. Henry (08-10)
  3. Mishel (08-09)

Generated by tDiary version 5.1.5
Powered by Ruby version 2.7.4-p191