PaperCut アプリケーション・サーバをSAMLシングルサインオンで展開する方法

■ バックグラウンド

（このガイドはPaperCut MF/Plus 両方に適用されます。）

PaperCutはドキュメントの印刷前、印刷時、印刷後にユーザを認証するための箇所が数多くあります。

【印刷前】

・ PaperCutを管理する。または管理者画面からレポートを表示する

・ エンドユーザがユーザ用Web画面にアクセスして、Webプリントのジョブを送信したり、統計情報を表示したり、

　 プリペイド・カードを登録するなどの操作を実行

・ プリント・ジョブの所有者を識別する

【印刷時】

・ リリースステーションからユーザ名/パスワード、カード認証、生体認証などの方法で認証する

【ドキュメントに永続的な説明責任を追加】

・ 必要に応じてすべてのページにウォーターマーク/デジタル署名を適用。

　 全ページに暗号化されたHMAC署名を追加。この署名によりドキュメントを印刷したユーザをトレースすることができます。

PaperCutはユーザを認証する際、Active DirectoryやLDAPなどのディレクトリ・サービスへ直接接続します。

さらに、管理者用Web画面とユーザ用Web画面でシングルサインオンを設定することができます。

PaperCutが認証のために外部SAMLサービスを信頼します。

このガイドでは、Active Directory フェデレーションサービス(ADFS), IIS およびShibboleth を使用して

PaperCut のSAMLシングルサインオンを構成する方法について説明します。また、類似のサービスにも同じ概念を適用できます。

■ IISの構成 (Shibboleth)

IISをインストールしていない場合、IISをPaperCutアプリケーション・サーバもしくは別のサーバにインストールしてください。

IISをPaperCutアプリケーション・サーバへインストールする場合、

PaperCutが ポート80 または 443 を使用するように設定していないかを確認してください。

そして、IISが標準のPaperCut ポート (9191,9192,9193) を使用しないようにしてください。

IISにISAPI拡張機能とISAPIフィルタがインストールされているかを確認する必要があります。

lSAPI拡張機能とISAPIフィルタは両方とも次のメニューから確認できます。

　[サーバの役割と機能] - [Webサーバー(IIS)] - [Webサーバー] - [アプリケーション開発]

また、IIS6 管理互換性オプションがインストールされている必要があります。

このオプションは[サーバの役割と機能] - [Webサーバー(IIS)] - [管理ツール] - [IIS6管理の互換性] です。

■ ADFSの構成

まだドメインコントローラーにADFSをインストールしていない場合、ADFSをインストールしてください。

ADFSをインストールしたことがない場合、次のページを参照してください。

【AD FS を展開および構成する】

https://technet.microsoft.com/ja-jp/library/gg188612.aspx

フェデレーションサービス名を書き留めておいてください。これは後ほど必要になります。

<Relying Party Trust を追加する>

「Claims Aware」を選択し、[次へ] をクリック

「Import Data about the relying party (信頼するパーティに関するデータのインポート)」を選択し、

/Shibboleth.sso/MetadataによるIISサーバのFQDNを入力してください。

(iis.domain.vm の場合、URLは「iis.domain.vm/Shibboleth.sso/Metadata」)

必要に応じて、表示名を編集し注記を追加することもできます。

アクセス制御ポリシーを設定します。ユーザやグループが認証できるかをロックダウンしたくない場合は、デフォルトオプションのままにしてください。

設定を再度チェックし、誤りがないことを確認してください。そして[次へ] をクリックし終了します。

<Claim発行ポリシーの編集>

「Party Trust」を右クリックし、「Edit Claim Issurance Policy」を選択してください。

弊社のルール・テンプレートでは、「Send LDAP Attributes as Claims(LDAP属性をClaimとして送信)」を選択しています。

ここで、返されるAD属性とそれを設定する発信クレーム・タイプのタイプを選択します。

クレームの名前を入力し、属性ストアからActive Directory を選択します。

「LDAP属性」から「SAM-Account-Name」を選択し、「Outgoing type」をWindowsアカウント名に設定します。

[完了]をクリック

■ Shibboleth のインストールと設定

次のサイトから最新のShibbolethをダウンロードしてください。

https://shibboleth.net/downloads/service-provider/latest/

そして、デフォルト・オプションを選択したまま、インストールを実行してください。

すべてのファイルは次のフォルダにあります: [C:\opt\shibboleth-sp\etc\shibboleth]

テキスト・エディタから「shibboleth2.xml」を開いてください。

<InProcess を編集して正しいIISサイトを使用する>

サイト名を変更する必要があります。ユーザが接続する完全修飾ドメイン名(FQDN)に変更してください。

　 <InProcess logger="native.logger">

    <ISAPI normalizeRequest="true" safeHeaderNames="true">

        <Site id="1" name="iis.domain.vm" scheme="https" port="443" />

    </ISAPI>

  </InProcess>

<ApplicationDefaults を更新する>

「ApplicationDefaults」は、設定したいヘッダを含む変数「remote_user」を設定します。

この記事の例では「ppcuser」をWeb Auth 用としてPaperCut の設定で使用するようにしたいと想定しています。 

  <ApplicationDefaults entityID="https://iis.domain.vm/shibboleth"

    REMOTE_USER="eppn persistent-id targeted-id ppcuser"    

   cipherSuites="ECDHE+AESGCM:ECDHE:!aNULL:!eNULL:!LOW:!EXPORT:!RC4:!SHA:!SSLv2">

<SSO を更新する>

SSO セクションには自分のIDプロバイダの場所が含まれます。IDプロバイダは、フェデレーションサービス名の後ろに「/adfs/services/trust」が続きます。

  <SSO entityID="http://fs.domain.vm/adfs/services/trust"

       discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">

       SAML2 SAML1

  </SSO>

<自動メタデータ・フェッチを追加する>

IDプロバイダのメタデータをロードする方法は2つあります。

1つ目はローカル・ファイルからロードする方法です。変更すると手動で更新する必要があります。

2つ目は必要に応じて自動的にメタデータを取得するURLを使用する方法です。

このURLは「/federationmetadata/2007–06/federationmetadata.xml

」の後ろに続くフェデレーションサービス名です。

  <MetadataProvider type="XML" url="https://fs.domain.vm/federationmetadata/2007-06/federationmetadata.xml"/>

<attribute-map.xml を開く>

Shibboleth にppcuserに設定したい値がどこにあるかを伝える必要があります。

クレーム発行にWindowsアカウント名オプションを使用したので、ここでその設定を行います。

  <Attribute name="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" id="ppcuser"/>

<Shiboleth の再起動>

Shibbolethの再起動方法は2つあります。

サービス管理(services.msc) を開いて、Shibboleth2 デーモンを見つけて再起動する方法、

もしくはコマンドプロンプトを開いて次のコマンドを実行してください。

　net stop shibd_default

　net start shibd_default

■ IISの構成 (Proxy)

最後に、プロキシとして動作するIISを設定します。

この設定を行うために、弊社では IIS ARR (Application Request Routing) モジュールを使用しています。

次のサイトからダウンロードできます： https://www.iis.net/downloads/microsoft/application-request-routing

インストールが完了したら、プロキシ・オプションを有効にしてください。

そしてIISマネージャを開き、左側のツリーからローカル・サーバを選択してください。

そして「Application Request Routing Cache」を探してください。

右側から「Server Proxy Settings」を選択してください。

「Enable Proxy」にチェックをつけ、右側から[適用] をクリックしてください。

左側からサイトを選択し、「URL 書き換え」をクリックしてください。

右側から「規則の追加」をクリックし、「受信規則」から「空の規則」を選択してください。

作成する最初のルールは、「[FQDN]/Shibboleth.sso/」に入るリクエストを無視するものです。Shibboleth関数をブロックしないためです。

　1． ルールに名前を付け、「要求されたURL」から「パターンに一致する」を選択し、「使用」から「正規表現」を設定してください。

　2. 「パターン」に「Shibboleth.sso/.*」と入力してください。

　3. 「大文字と小文字を区別しない」にチェックをつけてください。

　4. 「アクションの種類」から「なし」を選択してください。

　5. 「後続の規則の処理を停止する」にチェックをつけてください。

弊社の次のルールは PaperCut Application Server に他の何かを渡すことです。

新しい空白のルールを作成し、今回はパターンを(.*)に設定します。

「アクションの種類」から「書き換え」を設定し、「URLの書き換え」に以下のURLを設定してください。

　http://[papercut_ip_or_fqdn]:9191/{R:1}

そして「クエリ文字列の追加」にチェックをつけます。もう少し設定を続ければ、必要に応じてHTTPSを使用するように内部ルールを設定することができます。

右側から再起動をクリックするか、コマンドプロンプトをiisreset を実行して、IISを再起動してください。

■ PaperCutの設定

ここまでの設定で、SSOにWeb Auth を使用するように設定できるようになったはずです。

続いて、PaperCutの設定を行います。

　1． PaperCutの管理画面へログインし、<オプション> - <拡張> から 「Webシングル・サインオン (SSO)」を表示してください。

　2． プルダウンから「WebAuth」を選択

　3． 「WebAuth HTTP ヘッダ・キー」に「ppcuser」を設定してください。認証に成功した後、「ppcuser」にユーザ名が入ります。

　4． 「許可された WebAuth IP アドレス」

　　　ここには、IISサーバのIPの設定が必要ですが、

　　　安全のためlocalhost(127.0.0.1)とPaperCut アプリケーション・サーバのIPアドレスも追加してください。

　5． SSOを使用するページを選択します。

　　　上記のステップに従って設定した場合、ユーザ用Web画面のログイン・ページのみとなりますが、必要に応じて変更することができます。

　6． 「ログアウト時にユーザが移動するURLを入力」に、以下のURLを入力すると、PaperCut社のWebサイトへリダイレクトすることができます。

　　　　https://[iis_fqdn_or_ip]/Shibboleth.sso/Logout?return=https://papercut.com

　　　リダイレクト先のサイトは必要に応じて変更可能です。

■ テスト

ブラウザを起動し、「http://[IIS_HOST]/ 」と入力すると、ADFSログイン・ページが

表示されます。「domain\username」とパスワードを使用してログインするとPaperCutのユーザ用Web画面のページが開きます。

■ トラブルシューティング

上記の手順で設定を行うことですべての環境で動作するかどうかは検証が必要です。

問題が発生した場合、まずは使用するURLをチェックしてください。

URLはブラウザのアドレスバーにIIS ホストを入力することで動作するはずです。チェックする3項目は次の通りです。

　・ Shibboleth ステータス: https://localhost/Shibboleth.sso/Status

　・ Shibboleth メタデータ: https://localhost/Shibboleth.sso/Metadata

　・ ADFS メタデータ: https://[adfs_fqdn]/federationmetadata/2007-06/federationmetadata.xml

また、次のディレクトリからShibbolethのログ・ファイルが生成されます：

C:\opt\shibboleth-sp\var\log\shibboleth

弊社で検証している間、このログ・ファイル(shibd.log)が最も問題解決に役立ちました。

「ERROR」や「FATAL」を検索し、どこが間違っているかを調べることができます。

認証は管理されているが、PaperCutのログイン・ページが表示される場合、

PaperCut アプリケーション・サーバのデバッグ・ログを有効化し、もう一度やり直してください。

デバッグ・モードの有効化とログ・ファイルの場所は下記ページを参照してください。

【デバッグモードの有効化とログの場所(Application Server)】

http://cosy500-papercut-2.blogspot.jp/2013/04/application-server.html

「server.log」を開き、「WebSsoAuthenticationFilter」を検索してください。

この箇所に記録されている内容により、何が発生しているかの確認ができます。

PaperCut Ver.17.3.2 以降を実行していて、認証後にCSRFエラーが発生している場合、弊社までご連絡ください。

管理者画面のログインページのSSOを有効化していて、ログインできない場合、ログインURLの末尾に「add /nosso」を追加してください。

SSOオプションがスキップされ、管理者画面へログインできますので設定をチェックしてください。