Wednesday, January 28, 2015

Alfresco 5.0 で外部SSO連携を設定する(リクエストヘッダパラメータ編)

こんにちは。大谷です。

今回はAlfresco 5.0を外部SSO基盤と連携するための設定方法を紹介したいと思います。

外部SSOの仕様によって連携方法が異なりますが、今回は、認証済ユーザのリクエストヘッダに特定のパラメータを付与するパターンのSSOについてみていきます。このパターンはありがちなSSOの仕様の1つで、SSO基盤製品として標準機能で対応しているものや、エージェントと呼ばれるソフトウェアをSSO対象サーバ側にインストールして実現するもの(OpenAMもこのパターンです)などがあります。


AlfrescoでのSSO設定


では早速設定を行います。Alfrescoは2つのファイルに設定を行うだけで上記のパターンのSSOに対応できます。以下では、SSO基盤が認証済ユーザからのHTTPリクエストのリクエストヘッダに X-Test-Remote-User というパラメータでユーザ名を付与することを想定しています。

まずは毎度おなじみ alfresco-global.properties です。ここに以下の3設定を追記します。
  • authentication.chain : Alfresco認証チェーンに外部認証を追加します(external1はデフォルトで定義されている外部認証用の設定)
  • external.authentication.proxyUserName : このプロパティを空に設定することで、external.authentication.proxyHeader で指定したリクエストヘッダパラメータの値をユーザ名として利用します
  • external.authentication.proxyHeader : ユーザ名を読み出すリクエストヘッダパラメータ名を指定します(SSO基盤が認証済ユーザのリクエストヘッダに付与するパラメータ名を指定)

<tomcat_dir>/shared/classes/alfresco-global.properties
authentication.chain=external1:external,alfrescoNtlm1:alfrescoNtlm
external.authentication.proxyUserName=
external.authentication.proxyHeader=X-Test-Remote-User

続いて share-config-custom.xml の設定を行います。まずは既存の <config evaluator="string-compare" condition="Remote"> エレメントをコメントアウトし、以下の設定を追記します。インストーラでインストールした場合は、以下の設定がコメントアウトされた状態で記述されているので、以下の箇所のコメントタグを外します。

<tomcat_dir>/shared/classes/alfresco/web-extension/share-config-custom.xml
   <config evaluator="string-compare" condition="Remote">
      <remote>
         <keystore>
             <path>alfresco/web-extension/alfresco-system.p12</path>
             <type>pkcs12</type>
             <password>alfresco-system</password>
         </keystore>
         
         <connector>
            <id>alfrescoCookie</id>
            <name>Alfresco Connector</name>
            <description>Connects to an Alfresco instance using cookie-based authentication</description>
            <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
         </connector>
         
         <connector>
            <id>alfrescoHeader</id>
            <name>Alfresco Connector</name>
            <description>Connects to an Alfresco instance using header and cookie-based authentication</description>
            <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
            <userHeader>X-Test-Remote-User</userHeader>
         </connector>

         <endpoint>
            <id>alfresco</id>
            <name>Alfresco - user access</name>
            <description>Access to Alfresco Repository WebScripts that require user authentication</description>
            <connector-id>alfrescoHeader</connector-id>
            <endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
            <identity>user</identity>
            <external-auth>true</external-auth>
         </endpoint>
      </remote>
   </config>

設定のポイントは以下の2か所です。インストーラでインストールした場合は必ず以下の2か所を設定変更してください。
  • alfrescoHeaderコネクタのuserHeaderタグ : ユーザ名を読み出すリクエストヘッダパラメータ名を指定します(external.authentication.proxyHeader と同じ値を指定)
  • alfrescoエンドポイントのconnector-idタグ : alfrescoHeader を指定します(リクエストヘッダパラメータを使ったSSO認証を行うようになります)
設定は以上となります。なお、設定を反映させるためにはAlfrescoの再起動が必要です。


動作の確認


では、早速動作確認してみましょう。SSO基盤がある場合はSSO基盤の認証が通った状態でAlfrescoにアクセスしてみます。もしSSO基盤が無く、同様の状況をエミュレートする必要がある場合は、ブラウザのアドオン等を利用します。Chromeであれば、ModHeaderがお勧めです。今回の設定ではパラメータ X-Test-Remote-User からユーザ名を読み出すように設定したので、このリクエストヘッダパラメータにユーザ名(下記スナップショットではtest1)を指定しておきます。

ModHeaderのリクエストヘッダパラメータ追加画面

この状態で、http://<server name>:<port>/share にアクセスしてみましょう(ローカルPCであれば http://localhost:8080/share)。ログイン画面がスキップされ、以下のように指定したユーザのダッシュボード画面が表示されれば動作確認完了です。



Tipsとか


うまく動作しない場合は、ログを確認してみましょう。Alfresco Shareのログ出力設定に以下の行を加えると、詳細な動作状況を確認することができます。ただし、HTTPリクエストの度にログが出力されるのでログ肥大化には注意が必要です。

<tomcat_dir>/webapps/share/WEB-INF/classes/log4j.properties
log4j.logger.org.alfresco.web.site.servlet=debug

Alfresco起動時には以下のようなログが表示され、

DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [ContainerBackgroundProcessor[StandardEngine[Catalina]]] Initializing the SSOAuthenticationFilter.
DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [ContainerBackgroundProcessor[StandardEngine[Catalina]]] Endpoint is alfresco
DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [ContainerBackgroundProcessor[StandardEngine[Catalina]]] userHeader is X-Test-Remote-User
INFO [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [ContainerBackgroundProcessor[StandardEngine[Catalina]]] SSOAuthenticationFilter initialised.


アクセス時には以下のようなログが表示されるようになります。

DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [http-apr-8080-exec-4] Processing request /share/page/ SID:xxxxxxxxxx
DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [http-apr-8080-exec-4] Touching the repo to ensure we still have an authenticated session.
DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [http-apr-8080-exec-4] Validating repository session for test1
DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [http-apr-8080-exec-4] Accept-Language header present: ja,en-US;q=0.8,en;q=0.6
DEBUG [org.alfresco.web.site.servlet.SSOAuthenticationFilter] [http-apr-8080-exec-4] Authentication not required, chaining ...


起動時に指定したリクエストヘッダパラメータをチェックするように設定されているか、アクセス時に適切にユーザ名を読み取っているかを確認することができます。


本記事は以上となります。比較的簡単にSSO連携設定ができることがお分かり頂けたかと思いますので、是非一度お試しください。なお、本記事はAlfresco DocumentationのExternal configuration propertiesConfiguring Alfresco Share to use an external ssoを参考にしています。

Thursday, January 22, 2015

それ、CMISで繋げます(Liferay篇その2)

前回はLiferay上のDocuments and Mediaポートレットに対して、CMISリポジトリであるNemakiWareをバックエンドとして繋いでみました。 今回はそのリポジトリに対してどんなアクションが行えるか見てみましょう。 CMISはContent Management Interoperability Serviceというくらいなので、繋いでしまえば文書管理のオペレーションを行えるわけです。

一覧画面

Liferay側の機能ですが、表示形式を変えることができます。
各アイテムの横にある矢印ボタンをクリックすると、そのアイテムに対するアクションを行うことができます。



アクションの種類として、コンテキストメニューにダウンロード、編集、移動、チェックアウト、削除が見えています。
また、新規アイテムは画面上部のAddから作成します。
フォルダ/ドキュメントの2種類しか選べないようです。
CMISではドメインモデルとして、フォルダやドキュメントであるにしてもさまざまなカスタムタイプを定義できますが、次の新規作成画面を見てもタイプやそのカスタム属性を入力できる場所は見当たりません。
編集画面も同様で、ファイル実体と、名前の変更だけが可能です。

また、各アイテムの詳細情報を表示したければそのアイテムを一覧上でクリックします。

メタデータとバージョン履歴が表示されます。
メタデータはCMISのごく基本的な属性のうち一部が表示されています。
バージョン履歴では、以前のバージョンをダウンロードしたり、以前のバージョンを復活させる(ver1.1がある状態でver1.0をrevertすると、ver2.0としてver1.0が復活する)こともできます。このrevert自体はCMISで定義されたサービスではありませんが、以前のバージョンの内容で通常の更新アクションを内部的に実行していると思われます。

Documens and Mediaでは通常プレビューも存在すれば表示されますが、CMIS上のコンテンツに対しては、ファイル内容のプレビュー表示はないようです(CMISでは、プレビュー画像のようなものをクライアントに伝えることはできますが、プレビュー画像のデータ型が仕様で決まっているわけではありません)。

チェックアウト

文書管理機能らしいアクションといえば、チェックアウト/チェックインは欠かせません。
共有リポジトリ上で、特定のユーザが作業中は他のユーザから触れないようにファイルをロックしておくことはもちろん、更新作業中のファイルのスナップショットもなるべくローカルマシンに隠蔽しておくのではなくサーバ側に寄せて文書管理の対象とすることができます。

ではtest_02.txtをチェックアウトしてみましょう。
以下はチェックアウト後の状態です。

 ……あれれ?
 ロックされたものの、矢印ボタンも消えてアクションできなくなっています。
他のユーザに対してロックするのはよいですが、自分自身もロックしてしまったのでしょうか(いえ、そんなことはありません)。

 どうしてこうなった

結論からいうと、チェックアウトについてのCMIS仕様に関する解釈がLiferayとNemakiWareで食い違っているためだと思われます。

まずCMISではチェックアウトすると、作業用コピーが独立したオブジェクトとして自動で作成されます。この作業用コピーは、ver.1.0やver.1.1といったバージョンに似ていますが、あくまでバージョンではないとされています(仕様書2.1.13.15.1)。
ドメインモデルの考え方としてはバージョンではないのですが、サービスの方にあるgetAllVersionsメソッドでは作業用コピーも返すことになっているので、元のドキュメントから作業用コピーをたどっていくことは可能です。

一方、スクリーンショットにあるアイテム一覧は、CMISのgetChildrenメソッドによってあるフォルダの子要素一覧として取得されていると考えられます。getChildrenメソッドでは原則的には「最新のバージョン」を返すことになっているのですが、作業用コピーはバージョンではないので、getChildrenでは返されません。作業用コピーを返すためには別途、getCheckedOutDocsというメソッドが用意されています。

NemakiWareの場合、getChildrenで作業用コピーを返していないので、チェックアウトでロックされた元のドキュメントだけが表示されてしまっているのです。ロックされているのでアクションもできませんし、Liferayのバージョン履歴からは作業用コピーをたどることもできませんでした。

getChildrenで作業用コピーを返すことが明示的に禁じられているわけではないので、作業用コピーもgetChildrenで返すリポジトリはあり得ます。実際、Alfrescoがそうなっています。

 CMISリポジトリとしてAlfrescoをLiferayに接続した図です。2つ同じアイテムがありますが、片方には矢印ボタンがついていますね。

作業用コピーに対してチェックインや、チェックアウトのキャンセルができる、みたいです。

「みたいです」、というのは、実際にはAlfrescoの場合もLiferayからちゃんとしたチェックインができるわけではないからです。

まず作業用コピーを更新して、スナップショットをサーバに保存しておくためにEditを開いてみます。

なぜか真っ白。これでは編集できません。
ではチェックインを実行してみると、チェックイン時に更新画面は開かれず、いきなり以下の状態になります。

 ロックは解除されましたが、これではロック中にファイル内容を変更してアップロードすることができません。

まとめ

  • Liferayに接続したCMISリポジトリに対して、基本的なCRUDは可能
  • Liferayからのチェックアウト/ チェックインには難あり。
    • Liferay側のCMIS仕様の解釈に問題がある?
      • 筆者の解釈では、作業用コピーはgetAllVersionsかgetCheckedOutDocsで取得すべき
      • LiferayはgetChildrenで作業用コピーが返されると期待しているのかも(Alfrescoのように、チェックインするためのアクションボタンが表示されていた)
    • CMISの解釈はさておき、Alfrescoにとくに最適化されているのかと思いきや、Alfrescoでも見かけだけでちゃんと機能していない
  • とはいえ、Liferayは別に文書管理ソフトウェアではないのだから、ファイルのシンプルな読み書きだけできればそれで充分かもしれません。
というわけで、チェックアウト/チェックインに関しては残念な結果となってしまいました。今後のアクションとして、原因を正確に切り分けた上で、LiferayのJIRAに投稿するなどしようと思っています。

(文:linzhixing)

Tuesday, January 13, 2015

55% of big businesses block Dropbox: employees evade if no convenient replacement is proposed

According to a GIGAOM study, 55% of businesses with 30k+ employees explicitly forbid SaaS-based file sharing (Dropbox, Box, Office365, Syncplicity, etc).

Do employees accept this rule and go back to using their company's awkward tools, or stop sharing files with their colleagues?
No: According to the same study, 90% of cloud application usage happens without the IT department knowing it.

Block Dropbox, and employees will use a lesser-known alternative. Which is probably even worse.

Conclusion: If you block Dropbox, at the same time you should provide an alternative that offers the same convenience.

CmisSync offers exactly that:
- Looks like Dropbox
- Feels like Dropbox- Syncs like Dropbox
- Connects only to your corporate server, and never to any third-party.
90% of actual cloud application usage happens without the company IT department knowing - See more at: http://blogs.intralinks.com/collaborista/2014/10/out-of-darkness-shedding-light-shadow/#sthash.28CVTMxS.dpuf
90% of actual cloud application usage happens without the company IT department knowing - See more at: http://blogs.intralinks.com/collaborista/2014/10/out-of-darkness-shedding-light-shadow/#sthash.28CVTMxS.dpuf
90% of actual cloud application usage happens without the company IT department knowing - See more at: http://blogs.intralinks.com/collaborista/2014/10/out-of-darkness-shedding-light-shadow/#sthash.28CVTMxS.dpuf

Wednesday, January 7, 2015

Liferay Portal 6.2をインストールしてみよう

こんにちは、おおたにです。 今回はLiferay Portal 6.2のインストール方法について紹介したいと思います。

本ブログでもたびたび取り上げているLiferay Portalは、オープンソースの企業向け情報ポータル製品(Enterprise Information Portal)で、企業のインターネット向けサイトやイントラネット向けサイト、代理店/販売店ポータルなどに代表される組織/企業間、コミュニティポータルなどに代表されるユーザ同士など、様々な形での情報発信/情報共有の場を構築することに利用されています。

エンタープライズ向けと銘打たれているのでインストールの敷居も高いのではないかと思われるかもしれませんが、そんなことはありません。もちろん実運用を考えると諸々の設定やチューニングを行う必要がありますが、とりあえずインストールして使ってみようという限りではとても簡単にセットアップすることができます。

 では、早速インストール方法を見ていきましょう。


Javaのインストール


Liferay PortalはJavaベースのアプリケーションなので、JDKをインストールする必要があります。
Liferay Poratal 6.2の場合はJDK7をインストールします。OracleのサイトからOSに合わせたJava SE Development Kit 7をダウンロードしてインストールしましょう。


Liferay Portalのインストール


続いて、Liferay Portalをインストールします。今回は、アプリケーションサーバ(というかサーブレットコンテナ)としてTomcatを利用します。なお、本記事執筆時点でのCommunity Editionの最新版は6.2 CE GA2となっています。

まずは、LiferayのサイトからCommunity Edition以下のドロップダウンリストをクリックし、「Bundled with Tomcat」を選択して「Go」をクリックします。Bundled with xxxというパッケージは、いくつかのアプリケーションサーバがLiferay向けの設定が施された状態で同梱されているものなので、初めの一歩として利用するにはとても便利なパッケージとなっています。


次に、ダウンロードしたzipファイルを展開します。展開すると liferay-portal-6.2-ce-ga2 というフォルダが作成され、その中に必要なファイルがコピーされます。なお、このフォルダは <LIFERAY_HOME> と呼ばれ、Liferayの設定や運用に際して重要なフォルダとなります。

以上でLiferay Portalのインストールは終わりです(前述のとおり、実運用を考えるとJVMのチューニング等、さらなる設定が必要ですが、ここではひとまず動かすことを目的としているのでデフォルトのままでOKです)。


Liferay Portalの起動と初期設定


では、早速Liferay Portalを起動してみましょう。Liferay Portalを起動するためにはTomcatを起動すればよいので、以下のスクリプトを実行します。

Windows : <LIFERAY_HOME>/tomcat-x.x.xx/bin/startup.bat
Linux (or Mac OS X) : <LIFERAY_HOME>/tomcat-x.x.xx/bin/startup.sh

Liferayが正常に起動すると、ブラウザが自動的に起動して http://localhost:8080 にアクセスします。起動しない場合は手動でブラウザを起動して先のURLにアクセスしてみてください。以下の画面が表示されればOKです。なお、初回起動時はDBテーブル作成等を行うため、通常起動時よりも時間がかかります(手元のノートPCでは90秒ほどかかりました)。


上記画面は初回起動時のみ表示される基本設定画面です。ここではポータル名やデフォルト言語、管理者ユーザの情報やサンプルデータの有無を設定することができますが、デフォルトのままで問題ありません。データベースについてもデフォルトではHypersonicが使われますが、お試し用途であればこのままでOKです。

では、「設定終了」をクリックして次に進みます。しばらく待つと(手元では60秒程度)以下の画面が表示され、無事設定が保存されたことが分かります。


「Go to My Portal」をクリックすると、利用規約が表示されるので「I Agree」をクリックします。続いてパスワードリマインダ(パスワードを忘れた時の秘密の質問)を入力して「Save」をクリックします。以下のランディングページが表示されたら設定完了です。


なお、デフォルトでの管理者のユーザID(Eメールアドレス)はtest@liferay.com、パスワードはtestとなっていますので、次回以降Liferay Portalにログインする際にはこれらを入力する必要があります。

以上でLiferay Portalが使える状態になったかと思います。みなさまも是非Liferay Portalをインストールしていただき、実際に触ってみてください!


トラブルシューティング


Liferayが正常に起動しない場合は、以下のログの内容を確認してみてください。

<LIFERAY_HOME>/logs/liferay.xxxx-xx-xx.log
<LIFERAY_HOME>/tomcat-x.x.xx/logs/catalina.xxxx-xx-xx.log

また、サーバに宛がわれたメモリを確認してください。Liferay Portalはデフォルトでヒープに1GB、PermGenに256MB使う設定となっています。2GBだとギリギリですので、最低でも3GBは欲しいところです。