freedom-man.com

ブログは俺のセーブポイント

Tag: sso (page 1 of 3)

Salesforceを認証プロバイダとしてCognitoを使ってみる

Salesforceを認証プロバイダとしてAmazon CognitoでAWSのAPIを叩く方法を書いていきます!
参考URLは以下。今回のソースやら設定方法は、ほぼこちらのパクリです。
Building an App Using Amazon Cognito and an OpenID Connect Identity Provider

Continue reading

SalesforceのSCIM叩いてみた

SalesforceがSCIMに対応しているということで試してみました!
SCIMの説明はこちらが詳しいです↓
SAML / OpenID Connect / OAuth / SCIM 技術解説 – ID&IT 2014 #idit2014

SalesforceのSCIMのリファレンスはこちら↓
System for Cross-domain Identity Management (SCIM) の使用

Continue reading

onelogin/php-samlを触ってみた

SAMLのSPとなるようなアプリケーションが簡単に作れるかどうか、という技術検証で

onelogin/php-samlを触ったので使い方をメモってみましたー。

今回はSalesforceをIdP、phpのアプリをSP(ローカル環境)として

ソースに付随されているサンプルのアプリを動かしてみます。

1.  インストール

php使いの人にはお馴染みのComposerを使ってインストールします。

Windowsの場合はChocolateyだと何故か上手く行かなかったので、

本家からインストーラでインストールした方が良いかもしれないです。

からの composer.jsonに”onelogin/php-saml”: “master-dev” を追加

からの

でvenderディレクトリ配下にインストールされます。

2. 証明書の設定

SP側の証明書を設定します。

certsフォルダに秘密鍵と証明書を作成します。

3. settings.phpの設定

まずdemo1ディレクトリ配下のsettings_example.phpをコピーしてsettings.phpを作成します。

settings.phpの中身は以下の通り。

$spBaseUrlにはphp-samlへのURLをセット。

spのNameIDFormatはlib\Saml2\Constants.php のNAMEID_****の定数値から選択します。

idpのentityIdにはマイドメインの値を設定します。

singleSignOnServiceにはSP Initiated SSO用のリダイレクト先URL

(SAML Requestのエンドポイント)を入力します。

ちなみにphp-samlではSAML RequestはRedirectのみ対応しており

SAML AssertionはPOSTのみの対応となっています。

 

また、debug=trueでエラー時にエラーの理由等の詳細な情報が出力され

strict=trueではIdP、SPのentityId等が正確に合致していないとエラーになります。

逆に、strict=falseだとentityId不一致でもログイン出来てしまうので

特別なことが無ければstrict=trueにすべきです。

 

authnRequestsSignedはデフォルトfalseになっており

falseだとAuthnRequestでSignatureが発行されません。

4. Salesforceの設定

設定>作成>アプリケーション から接続アプリケーションを以下のように作成します。

connectapp_phpsaml

各項目には3のsettings.phpに設定した値を入力し

開始URLとACS URLにはassertionConsumerServiceの値、エンティティIDにはentityIdの値

名前ID形式にはNameIDFormatの値をそれぞれセットします。

要求署名を確認をチェックして2で作成した証明書をアップロードしてください。

 

保存後にManageボタンを押下し、有効なプロファイルを設定します。

connectapp_phpsaml_manage

また、メタデータのダウンロードから出力されるXMLのX509Certificateのテキスト値

(以下のMIIErD********の部分)をコピーします。

またメタデータの値がsettings.phpの値と整合性が取れているかどうかも確認します。

(entityIdとかsingleSignOnServiceとか)

5. settings.phpにIdPの証明書を設定

settings.phpのidpのx509certに4でコピペした証明書のテキストをセットします。

6. デモアプリを動かす

IdP Initiated SSOの場合は

Salesforceの接続アプリケーションのIdp-init のログイン URLにアクセスすればOKです。

connectapp_phpsaml_idpsso

アプリケーションランチャーを使ってIdP Initiated SSOをする場合は

接続アプリ>manageの開始URLのところに”Idp-init のログイン URL”の値を入れて

対象アプリケーションのリンクやランチャーをクリックすればOK。

 

SP Initiated SSOの場合は

demo1/index.phpでLoginのリンクをクリックすると

SalesforceにSAML Requestが飛ぶので、Salesforceで認証後に

demo1/index.php?acsにSAML Assertionが返って、認証が出来ます。

 

署名がミスっている場合はSFDCから以下のようなSAMLResponseが

URLパラメータ経由(リダイレクト)で返却されます。

7. デモアプリの中身

デモアプリの根幹であるindex.phpの中身は簡潔で

SP Initiated SSOをする場合はOneLogin_Saml2_Auth#login

SAML AssertionのverifyはOneLogin_Saml2_Auth#processResponse

SLOしたい場合はOneLogin_Saml2_Auth#processSLO

を叩くだけで、SAML Assertionのverifyが通ったタイミングで

php側のセッションを発行すればOKです。

Azure Active DirectoryでTwitterにシングルサインオンしてみる。

Azure Active Directoryネタです。

今回はAzure Active DirectoryでTwitterにシングルサインオンをしてみます。

通常、Twitterやfacebookなどサービスにシングルサインオンというと

これらのWebサービスをIdP(OP)としてOAuth、OpenID Connectによる認証連携をイメージしますが

Azure Active Directoryの場合は、AzureAD自体がIdPになり

TwitterなどのWebサービスがSPとなるような構成になります。

1. TwitterのギャラリーアプリをAADに追加

まずは対象のDirectoryを選択

aad-sso-select-directory

アプリケーションを選択して、追加をクリック

aad-sso-select-application

今回はギャラリーからアプリを追加

aad-sso-addapp

Twitterのアプリケーションを選択

aad-sso-twitter-gallery

追加するとこんな画面が表示される

aad-sso-twitter-settings

シングルサインオンの構成をクリックしてパスワードシングルサインオンになっていることを確認

aad-sso-settings

2. ユーザの割り当てを実行

Twitterのギャラリーアプリ設定画面から、「ユーザの割り当て」を選択してユーザ一覧にアクセスし

対象のAzureADユーザに対して割り当てを行う。

aad-sso-userlist

割り当てでは「ユーザの代わりにTwitter資格情報を入力する」にチェックを付けて

紐付けるTwitterのユーザ名/パスワードを入力する。

aad-sso-userassignment

これで、AzureAD側の設定は完了です。

3. アクセスパネルからシングルサインオンを行う

https://myapps.microsoft.comにアクセスしてAzureADユーザでログインを行うと

以下のようにシングルサインオン用のパネルが表示されます。

aad-accesspanel

複数のディレクトリに属すAzureADユーザの場合は右上のメニューからディレクトリを選択することが可能。

また、各ブラウザのAzureAD用のプラグインがインストールされていない場合は

パネルをクリックするとプラグインのインストール画面に遷移します。

aad-sso-plugin

AzureADのシングルサインオンの仕様上、プラグインをインストールしないと認証連携が動作しません。

インストール後にTwitterのアクセスパネルをクリックすると

一瞬Twitterのログイン画面が表示されて、AzureADに保持しているクレデンシャルと

プラグインのDOM操作によって自動ログインが行われます。

 

ChromeExtensionだと、以下のスクリプトがAzureADから発行されて

クライアントのChromeExtensionで当スクリプトを実行することで自動ログインを実装しているっぽいです。

HTTP通信やコードから全てを追ったわけではないので推測になりますが

おそらくは、AzureADからクレデンシャル付きの各アプリ固有のJSが送られてきて、

それをSessionStorageに保存して、各プラグインがSessionStorageに格納されたJSを

evalで実行するといった流れだと思われます。

 

ギャラリーアプリはTwitter以外にもfacebookやAWS(コンソール)、Salesforceにも対応しています。

SalesforceはSAMLだけじゃなくて今回の無理矢理(?)自動ログインの方法にも対応しています。

 

印象としてセキュリティポリシー云々でエンタープライズ領域で良いかどうかはわかんないけど

個人的に利用する分には便利だなーって感じです。

ただ、個人的に利用するんだったらLastPassみたいなパスワード管理サービスでも良いような気がしますが…。

おそらくLastPassもAzureADと同じような仕組みで自動ログインしているものと思われます。

OpenAMでSSO【OpenIG編】

今回はOpenAM+OpenIG+PolicyAgentなSSOをやってみます。

以下のような構成になります。

openig-architecture

 

 

フローを簡単に説明すると

1. UserAgentがWebサーバにアクセス(初回)

2. Policy Agentがリクエストをインタラプト、Cookieが入っていないのでOpenAMに認証要求リダイレクト

3. OpenAMで認証後、Webサーバにリダイレクト

4. 認証されている(=Cookieが入っている)のでPolicy AgentはCookie値をOpenAMに問い合わせて

ユーザ名/パスワードを取得

5. Policy Agentが取得したユーザ名/パスワードをヘッダに入れてOpenIGにリクエスト

(パスワードは暗号化されている)

6. OpenIGはログイン画面がリクエストされた時のみヘッダからユーザ情報を取得し、認証リクエストを行う

(通常のフォームPOSTを模倣する)

7. Webアプリは認証リクエストを受け取り、ユーザ認証実行後OpenIG・Policy Agent経由で

UserAgentにレスポンスを返して認証終了

といった感じです。

 

OpenIGはリクエストのプロトコルやURI、ヘッダ等の情報やフォワードしたHTTPリクエストに対する

レスポンスの正規表現マッチングを使って処理を分岐させたり

HTTPクライアントとして動かしたりできるリバースプロキシソフトウェアになります。

 

今回はOpenIGを使ってOpenAMで認証されたユーザ名/パスワードでWebアプリにSSOするフローをやってみます。

※本記事ではOpenAMのユーザ名/パスワード=Webサイトのユーザ名/パスワードになることを想定しています。

 

参考URLは以下になります。

OpenAMによるシングルサインオン(2)リバースプロキシー編 – Tech-Sketch

OpenIG | LAJ技術ブログ

Chapter 5. Detailed Use Cases

Chapter 7. Tutorial On OpenAM Password Capture & Replay

Chapter 11. Configuration Templates

 

1. OpenIGのインストール

Javaのアプリケーションサーバで動作するらしいのでtomcat使ってやってみます。

ダウンロードはここから→https://forgerock.org/downloads/openig-builds/

 

展開したwarファイルをtomcatのルートに設置

tomcat実行ユーザのホームを/etc/passwdで調べて以下のディレクトリに設定ファイルを作成

 

あとはconfig.jsonの設定ファイルを書き換えていくだけでOK。(3を参照)

 

2. OpenAMの設定

Policy Agent編でのPolicy Agentの仕事はトークンの検証のみで良かったのですが

今回はユーザ情報をOpenIGに送る必要がある(OpenIGからOpenAMのユーザ情報を取得できない)ことから

エージェントが”OpenAMからユーザ情報を取得する”設定に書き換える必要があります。

 

アクセス制御>対象のレルム>エージェント>対象のエージェント で

アプリケーションタブをクリックしてセッション属性処理を以下のように編集

openam-openig-setting1

 

アクセス制御>対象のレルム>認証 で

すべてのコア設定をクリックして認証ポストプロセスクラスを以下のように編集

openam-openig-setting2

openam-openig-setting3

 

次にPolicy Agent→OpenIG間の通信でユーザのパスワードを暗号化する為の対称鍵(DES)を作成します。

DESキー作成のためのモジュールはOpenAMに入っているので以下を実行して暗号化の対称鍵を生成

 

設定>サーバー及びサイト>対象のサーバ>高度 で

生成した暗号化キーを追加

openam-openig-passwd

 

また、XUIを使っているとパスワードがヘッダに付与されなかったりするみたいなので(参考URL

設定>認証>コア のXUIインターフェースを無効にしてください。

openam-xui

 

3. OpenIGの設定

今回は超簡単に特定のIDのformタグがあればPolicy Agentから取得した

ユーザID/パスワードを自動的にPOSTして認証を行うような設定にします。

config.jsonは以下のとおり

 

シーケンスはこんな感じ(テキトーです)

openig-sequence

 

CryptoHeaderFilterのkeyには2で作成した暗号化キーを設定してください。

上記設定ではhtmlの正規表現パターンマッチによりログイン画面の判定をしていますが

URLでの判定も可能なので、リクエストしたURLに応じて処理を分けるのも有りです。

 

また、今回は必要最低限のフォームデータをPOSTしていますが

通常formにはCSRFトークン等のnonceがCookieあるいはhiddenに埋め込まれていると思うので

その値を${exchange.response}のプロパティや正規表現を使ってセットする必要があります。

 

OpenIGからデータベースやテキストファイルにアクセスすることも可能なので

WebアプリとOpenAMのログインユーザのマッピングも可能です。

※通常のフォームPOSTなのでOpenAMのパスワードを利用しない場合は

Webアプリのユーザのパスワードを暗号化するなりしてどこかに保存しておかなければなりません。

 

config.jsonは複雑なので参考URLのChapter 11. Configuration Templatesをベースに作成 すると楽です。

 

4. Webサーバの設定

Apacheはポート80のリクエストをポート8080のOpenIG(tomcat)にフォワーディングする設定にします。

 

Policy Agentのインストール・設定は以前の記事を参照。

 

Python/Flaskのサンプルアプリは以下の通り。

ログイン画面出して認証するだけのプログラムです。面倒だったのでセッション立ててませんw

agent.py

templates/login.html

 

あとはagent.pyを稼働させてWebサイト(/login)にアクセスすると、クライアント側からは

Webサイトにアクセスする→OpenAMにリダイレクトして認証→Webサイトに自動認証

という流れで画面遷移し、SSOが実現できます。

 

OpenIG+Policy AgentはPolicy Agentのみのパターンとやっていることは同じですが

Policy AgentのパターンでWebアプリを改修しないといけない部分を

OpenIGが担っているのでWebサイト側は基本的には改修不要になります。

 

ただし上記例はWebとOpenAMのユーザ名とパスワードが一致している必要があり

一致していない場合はDBでマッピングする、Webアプリ内からOpenAMのREST API叩く等の

仕組みを検討する必要があります。

 

Older posts

© 2017 freedom-man.com

Theme by Anders NorenUp ↑