kagamihogeの日記

kagamihogeの日記です。

アトラス作品ファン交流会の真・眼鏡祭（2017/04/16）に行ってきた

眼鏡祭

2017年4月15日 真・眼鏡祭に行ってきました。

眼鏡祭とは、ペルソナなどアトラス作品ファンによるオフ会です。当日の天候は予報ではやや雨でしたが、特に降られずに済みました。ただ交通機関が乱れ気味で乗り換えなどに苦労した人がぽつぽつと見られました。会場は新宿のカフェを貸し切っての開催で、参加人数は200人を超え、相変わらずの盛況ぶりとなりました。当日の様子はtwitterのハッシュタグ #眼鏡祭0415 hashtag on Twitter で追えます。

コスプレOKなオフ会

眼鏡祭の最大の特徴はなんといってもコスプレしての参加が可能である、という点でしょう。

コスプレして、飲んで、騒ぐ。

眼鏡祭は特にこれといった催し事はありません。参加者同士のコミュニケーションが全てです。しかし、そのシンプルさ故にか多くの人に支持されるイベントに仕上がっています。

コスプレの分布ですが、さすがに今回はペルソナ5のキャラクターが大勢を占めました。今回の開催からP5のネタバレも解禁となったため、ゲーム終盤で登場するキャラクターもいました。これまでは基本的にはP3またはP4の勢力が大多数だったため、自分の目にはかなり新鮮な光景に映りました。

参加者が多いため、主役級のキャラクターだけでなくサブキャラクターも多くなるのが眼鏡祭の特徴です。世の中にコスプレイベントは数多くありますが、アトラス系だけに絞るものは中々無いらしく、それぞれ工夫を凝らして組み合わせに夢のある写真を撮る人が会場のそこかしこで見られます。

とはいえP5以外の勢力が居なくなるわけではないのが眼鏡祭のすごいところです。P5で新たに入ってきた人から、昔ながらの作品をこよなく愛する人までそろっており、しかしだからといって統一感が損なわれないのがこのオフ会の面白いところです。

ルールについて

眼鏡祭は、オフ会であっていわゆるコスプレイベントではありません。

コスプレはどうしても目立つ分ついつい忘れがちになりますが、第一目的はあくまでもファン同士の交流です。そして、コスプレだけに限れば不便な点はかなり存在します。たとえば、会場は単なるカフェ・レストランなので、更衣室は会場の一部に仕切りを設けただけ、撮影機材もあるわけではない、等々。

f:id:kagamihoge:20170416173857j:plain

上記は参加者全員に配布され、オフ会開始時にもグループリーダーより口頭でも説明のある注意事項です。コスプレに関して言えば、撮影は本人の許可を取ること、SNSへのアップは撮影とは別途に許可を取ること、が必須事項です。眼鏡祭でしかコスプレをしない人も多く、社会常識的にこの辺りは守る必要があります。

あれこれ書くとなんだか面倒そうに見えますが、実際のところは大人同士の飲み会を楽しくやるための最低限のルール、といった程度です。

初参加で楽しめるかどうか

はっきり言って200人超のオフ会に、知り合いが居ればともかく、単独で参加するのは尋常の度胸ではないでしょう。P5は色々語り合いたい要素も多く、そのために眼鏡祭に辿り着いた人も多いと予想するのですが……この辺はややステマめいたやり方ですが実際に今回参加した人のtweetをいくつか引用します。

眼鏡祭をどうしたら楽しめるか

そうはいっても知らない人とのコミュニケーションに尻込みするのは当然で、そのために眼鏡祭はコスプレを許可している背景があります。コスプレをしていると、少なくともそのキャラクター・ないし、その作品に何らかの愛着がある、と口で言わずとも全身で表してるようなものです。なので、話しかけやすいし、話しかけられもされやすいです。

眼鏡祭では「コスプレ」というより「仮装」という表現をします。テーマパークでテンション上げるためにペイントしたり被り物したり、とかと似たような意味合いです。そのため、質にこだわる人はあまり居ないです。実際、コスプレ歴の長い人何人かに聞いたことはあるんですが、長い人ほど寛容です。最初は誰しも苦労すると自分自身が一番良く知っているし、眼鏡祭はコスプレしてワイワイやれればそれで良い、という意見の持ち主ばかりでした。

最も、コスプレという「沼」にみんなおいで～と笑顔で手招きしているだけなのかもしれませんが。

有志によって作られる眼鏡祭

眼鏡祭は何らかのイベント会社が開催しているわけではありません。会場や飲食提供を除くと、その他はすべて有志によるものです。

その一例として、上記のように会場のテーブル・椅子の配置変更および元に戻す作業は有志によるものです。体力勝負的なものといえば、会場外での誘導、二次会会場への引率、更衣室の準備に入退室の管理。出席管理や配布用紙の作成など裏方の事務作業、金銭管理、宣伝用のイラスト制作……200人を動かすための労力は本当に頭が下がります。

象徴的な出来事として、今回会場内のアナウンス役が交代していました。眼鏡祭は有志それぞれが持っているそれぞれのスキルを持ち寄って作られているところがあり、見えるところも見えないところも毎回大なり小なり変化をしています。コミュニティは維持管理が無いと意外にも簡単に消滅します。眼鏡祭が長く続いているのは、参加者の支持はもとより、運営スタッフ陣の尽力にもあるのでしょう。

もし運営スタッフに興味があれば、随時募集をしている（と思う）ので手を挙げると歓迎されるでしょう。*1

眼鏡祭をポータルに色々行ってみる

これは私見ですが、眼鏡祭当日だけ、もしくは眼鏡祭一次会だけだと更に、交友関係を広げるのは至難の業です。コスプレを解くと誰が誰やらわからなくなる上に、これだけの人数なのでよほどのコミュニケーション強者でないと振る舞い方は難題です。

そのあたりは主催側もよく理解しています。そこで、当日後半に主催者も紹介していましたが、これからのイベントに顔を出すのが手っ取り早いです。

眼鏡祭の振り返り的な飲み会（コス無しのただの飲み会）の4/29 真・眼鏡祭おかわり会、4/29,30のニコニコ超会議後に足を運ぶ人も居るでしょう。5/3 アトラス作品CLUB EVENT｜Velvet Disco〈ベルベットディスコ〉は眼鏡祭の人も多くくるのでクラブに馴染みが無くても行きやすいと思います。2017年8月2日にあるらしいペルソナ大型ライブなど、公式で大き目なイベントは知り合い同志で誘い合わせて行っている人も多いです。

他、自分が最近顔を出しているものだと、プラモ今日知ろう（終了済）のガンプラ作る会、アトラス関係無いですがアイマスのクラブイベントCOLORS（終了済）*2、なんか良くわからないけど何かやるらしい8月開催 夏の盆（ぽん）まつりなど。

もちろん次回の眼鏡祭7/15予定もあります。

イベント情報の入手源については眼鏡祭主催のアカウントをとりあえずフォローしておくのがお勧めです。

最後に

最後になりましたが、主催のマソーさんはじめ運営スタッフの皆さん、参加者および一次会二次会で俺の話し相手になってくれた皆さん、この日記を書くためにtweetを引用させて頂いた方々、今回も非常に楽しい一日を過ごすことができました。他の今後のイベントや眼鏡祭本編でもよろしくお願いいたします。

その他

*1:https://twitter.com/autumn_j_frost/status/853595325298233344 にあるように勝手な判断で行動するとかえって混乱の元になるため、まずは主催やスタッフに相談や連絡をして下さい。

*2:次回は7月とかなんとか https://twitter.com/daibu_kuroto/status/835843775645679617

Apache Shiro Terminologyをテキトーに訳した

Java Apache Shiro テキトー翻訳

Apache Shiroのチュートリアルの一部で用語集に関する部分の https://shiro.apache.org/terminology.html をテキトーに訳した。

Apache Shiro Terminology

この用語集を読み終えるには2分程度ですが、Shiroではこれらの用語の理解は重要です。以下の用語と概念はドキュメント全般で使われているため、セキュリティ一般とShiroを素早く理解するのにこの用語集を活用してください。

セキュリティはそこで使われる用語が原因で大変混乱しやすいです。コアの概念を明確化にして理解しやすく整理したので、ShiroのAPIにその概念がどのように反映されているかを見てみてください。

  • 認証(Authentication)
    認証とは、サブジェクトのアイデンティティを検証するプロセスで、基本的には、ある人物が自分を誰であると言ってきているのかを確認するものです。認証の試行が成功すると、アプリケーションはそのサブジェクトをアプリケーションが期待するものである、として信頼します。
  • 認可(Authorization)
    認可、別名ではアクセス制御(Access Control)は、あるユーザ／サブジェクトに許可されるまたは許可されない何かを決定するプロセスです。このプロセスは通常、サブジェクトのロールやパーミッションを参照したり処理することで実行され、その後、リクエストされたリソースや関数に対するアクセスの許可もしくは拒否が行われます。
  • 暗号(Cipher)
    暗号は、暗号化または復号化を処理するアルゴリズムを指します。通常、アルゴリズムはキーと呼ばれる情報に依存します。暗号化はキーによって変化するため、複合化をキー無しで行うのは非常に難しくなります。
    暗号には色々なバリエーションがあります。ブロック暗号(Block Ciphers)は通常は固定サイズのシンボルのブロックを処理し、一方、ストリーム暗号(Stream Ciphers)はシンボルの逐次的なストリームを処理します。対称暗号(Symmetric Ciphers)は暗号化と複合化に同一のキーを使うのに対し、非対称暗号(Asymmetric Ciphers)は異なるキーを使います。また、非対称暗号のキーはもう片方からは生成出来ないので、公開鍵/秘密鍵のペアを生成して公開鍵を公開します。
  • クレデンシャル(Credential)
    クレデンシャルとは、ユーザ／サブジェクトのアイデンティティを検証するための情報です。プリンシパルと共にユーザ／サブジェクトはクレデンシャルをサブミットし、認証でそれを検証します。クレデンシャルはユーザと関連付けられています。クレデンシャルは、通常は個々のユーザ／サブジェクトだけが知る秘密事項で、パスワード・PGPキー・生体情報・などが挙げられます。
    プリンシパルとの関連では、唯一人だけがそのプリンシパルと'ペア'になる正しいクレデンシャルを把握しています。カレントのユーザ／サブジェクトがシステムに格納されているものと正しくマッチするクレデンシャルを与えられる場合、システムはカレントのユーザ／サブジェクトが自身を誰と言ってきてるのかを信頼します。信頼の度合いはよりセキュアなクレデンシャルを使うことで高まります（例えば、生体認証 > パスワード）。
  • 暗号化(Cryptography)*1
    暗号化は想定外のアクセスから情報を防御するもので、データを隠したり読めない形式に変換するなどします。Shiroには二つのコア要素があり、一つは公開鍵または秘密鍵でemailなどのデータを暗号化するciphersと、もう一つはパスワードなどのデータを不可逆的に暗号化するハッシュ（メッセージダイジェストなど）があります。
  • ハッシュ(Hash)
    ハッシュ関数は、片方向で、入力ソースの不可逆変換を行い、メッセージをエンコードしたハッシュ値はメッセージダイジェストと呼びます。ハッシュは、パスワード・デジタルフィンガープリント・基底バイト配列のデータ、に対して使うことが多いです。
  • パーミッション(Permission)
    パーミッションとは、少なくともShiroが解釈するものとしては、アプリケーションにおける最も細かい機能の記述の表明です。パーミッションはセキュリティポリシーにおける最も低レベルの構成要素で、アプリケーションが"何を"実行可能かのみ定義します。"誰が"そのアクションを実行可能かは記述しません。パーミッションは振る舞いの表明でしかありません。以下はパーミッションの例です。
    • ファイルをオープンする。
    • ‘/user/list'のwebページを閲覧する。
    • ドキュメントを印刷する。
    • ‘jsmith'ユーザを削除する。
  • プリンシパル(Principal)
    プリンシパルとは、アプリケーションユーザ（サブジェクト）の何らかの識別属性(identifying attribute)です。'識別属性'となりうるモノは、ユーザの姓名・社会保障番号・ユーザID、など、ただそれだけのモノです。
    Shiroはサブジェクトのプライマリープリンシパルと呼ばれるものを参照します。プライマリープリンシパルはアプリケーション全体でサブジェクトを一意に識別する何らかのプリンシパルです。理想的なプライマリープリンシパルはRDBMSのユーザーテーブルのプライマリキーとなるユーザ名やIDなどが該当します。あるアプリケーションにおいてユーザ（サブジェクト）のプライマリープリンシパルは一つだけしか存在しません。
  • レルム(Realm)
    レルムとは、ユーザ・ロール・パーミッションなどのアプリケーション固有のセキュリティデータにアクセスするコンポーネントです。セキュリティ用のDAO(Data Access Object)と言えます。レルムはアプリケーション固有のデータをShiroの形式に変換し、それから理解しやすい単一のサブジェクトAPIをShiroが提供します。このAPIの裏で動くものは、データソースの数やアプリケーション固有のデータの提供方法が何であっても構いません。
    レルムは通常は、RDB・LDAPディレクトリ・ファイルシステムやその他類似のリソースと1対1の関係を持ちます。そのため、レルムインタフェースの実装は認証データ（ロール・パーミッションなど）の取得にデータソース固有のAPI、例えばJDBC・ファイルIO・HibernateやJPAなどのデータアクセスAPI、を用います。
  • ロール(Role)
    The definition of a Role can vary based on who you talk to.*2 たいていのアプリケーションにおいて、暗黙的なセキュリティポリシー定義が関の山です。Shiroはロールをシンプルな名前のパーミッションのコレクションとして使うのを推奨します。言い換えると、アプリケーションは一つ以上のパーミッション宣言を集約したものに一意の名前を付けます。
    これにより、多数のアプリケーションで使われている暗黙的定義よりも明確な定義が作れます。Shiroが想定するデータモデルにすれば、セキュリティポリシーの運用をより強力なものにできるでしょう。
  • セッション(Session)
    セッションは一つのユーザ／サブジェクトと関連付けられるステートフルなデータコンテキストです。このユーザ／サブジェクトは、ある一定期間ソフトウェアシステムと相互作用を行います。サブジェクトがアプリケーションを使用している間、セッションからデータを追加・取得・削除可能で、それからアプリケーションは必要に応じてそのデータを使用可能です。ユーザ／サブジェクトがアプリケーションをログアウトあるいはタイムアウトするとセッションは終了します。
    HttpSessionを知っている人向けに補足すると、ShiroのSessionは同様な目的に使えますが、ShiroのセッションはServletコンテナやEJBコンテナが無い環境でも使用可能な点が異なります。
  • サブジェクト(Subject)
    サブジェクトは、基本的にはアプリケーションユーザをセキュリティ視点から見た'ビュー'を意味する、ちょっと格式ばった言い方のセキュリティ用語です。サブジェクトは常に人間である訳ではなく、アプリケーションを外部から呼び出す何らかのプロセスを意味します。また、ある一定期間ごとに何らかの処理を実行するデーモンシステムアカウント（cronジョブなど）の場合もあります。サブジェクトは基本的には、アプリケーションを用いて何らかの処理をするエンティティを指します。

Lend a hand with documentation

Apache Shiroで何かを作る際にこのドキュメントが役に立つことを願いますが、コミュニティが成長すればドキュメントも常に拡張していきます。もしShiroプロジェクトに興味がある場合、必要だと感じたドキュメントの追加・修正・収集をお願いしたいと思います。ほんの少しの助けであってもコミュニティは前進し、結果としてShiroも前進します。

ドキュメントをコントリビュートする最も簡単な方法はこのページ下のEditリンクをクリックしてプルリクエストをサブミットするか、User ForumあるいはUser Mailing Listに送信します。

*1:この用語集のみ読む限りでは、Cryptographyの一つにCipherがある、って感じらしい。俺自身セキュリティにはさして詳しくないんで、どっちも『暗号』にしてしまってます。

*2:よくわからん

Apache Shiro Architectureをテキトーに訳した

Java Apache Shiro テキトー翻訳

Apache Shiroのチュートリアルの一部でアーキテクチャ概要に関する部分の https://shiro.apache.org/architecture.html をテキトーに訳した。

Apache Shiro Architecture

Apache Shiroの設計目標は直感的で使いやすいようにアプリケーションセキュリティを単純化することです。Shiroのコア部分の設計は、人がアプリケーションセキュリティをどう捉えるかをモデル化しており、そのモデルはアプリケーションと相互作用する誰か（もしくは何か）という状況を背景に置いています。

通常、ソフトウェアアプリケーションはユーザーストーリーに沿って設計されます。つまり、開発者は、ユーザとソフトウェアが相互作用する（もしくは、すべき）方法に従って、ユーザインタフェースもしくはサービスAPIを設計していると思います。たとえば、"アプリケーションと相互作用するユーザはログイン後、そのユーザ自身のアカウント情報を参照可能なクリックできるボタンを表示する。未ログインの場合、サインアップボタンを表示する。"といった具合です。

上記の例文は、アプリケーションは主としてユーザ要求とニーズを満たすように作られる、ということを示しています。"ユーザ"が別システムの場合や、人間ではない場合でも、ソフトウェアがある時点で相互作用する誰か（もしくは、何か）を基点にした振る舞い を反映するようなコードを開発者は作成します。

Shiroはこうした思想を設計に組み込んでいます。開発者にとって直感的な概念に合わせることにより、Apache Shiroは直感的であらゆるアプリケーションに実用的な使いやすさを提供しています。

High-Level Overview

最上位の設計レベルにおいて、Shiroのアーキテクチャは三つの主要な概念、Subject, SecurityManager, Realmsで構成されています。以下の図はそれらのコンポーネントの相互作用の概要を示しています。各コンポーネントについては後で解説します。

図：https://shiro.apache.org/assets/images/ShiroBasicArchitecture.png

  • サブジェクト(Subject): チュートリアルにある通り、Subjectは基本的に現在実行中ユーザのセキュリティ視点での'ビュー(view)‘となります。'ユーザ(User)'という単語は人間を連想させますが、Subjectは人間以外に、サードパーティのデバイス、デーモンアカウント、cron jobなどが考えられ、要するにソフトウェアとその時相互作用する何か、になります。
    SubjectインスタンスはすべてSecurityManagerにバインドされています*1。Subjectと相互作用するとき、その相互作用はSecurityManagerを用いるサブジェクト固有の相互作用に変換されます。
  • セキュリティマネージャー(SecurityManager): SecurityManagerはShiroのアーキテクチャの中核で、ある種のアンブレラ(‘umbrella’)オブジェクトとして振る舞います。このオブジェクトは、内部的なセキュリティコンポーネントとの調整役となり、コンポーネントと共にオブジェクトグラフを形成しています。ただし、SecurityManagerと内部オブジェクトグラフを一度アプリケーションに設定したあとは、基本的にその設定を触ることは無く、アプリケーション開発者はSubjectAPI以外を使うことはほとんどありません。
    SecurityManagerに関する詳細は後ほど触れますが、Subjectと何らかの相互作用を行う場合、Subjectのあらゆるセキュリティ操作に対する、すべての重い処理の背後には実際にはSecurityManagerがいることを覚えておいて下さい。この処理の流れは上の図の通りです。
  • Realms(レルム): レルムの振る舞いはShiroとアプリケーションのセキュリティデータ間で"ブリッジ"あるいは"コネクタ"といったものになります。認証（ログイン）と認可（アクセス制御）の実行にユーザアカウントなどのセキュリティ関連データを用いて実際に相互作用する段階になると、Shiroはアプリケーションに設定されている一つ以上のレルムから様々なデータを参照します。
    その意味において、レルムは基本的にはセキュリティ固有のDAOと言えます。このDAOは、データソースへの接続詳細をカプセル化し、必要に応じて関連データをShiroで利用可能にします。Shiroの設定時には、認証もしくは認可の両方で使うためのレルムを少なくとも一つ指定する必要があります。SecurityManagerは複数のレルムを設定可能で、少なくとも一つのレルムが必要です。
    Shiroはいくつかのレルムを提供しており、LDAP, RDB(JDBC), INIライクのテキスト設定ソース, プロパティファイルなどのセキュリティデータソースに接続するためのレルムを用意しています。これらデフォルトのレルムが要求を満たさない場合、カスタムデータソースを記述する自前のレルム実装をプラグイン出来ます。
    他の内部コンポーネント同様に、ShiroのSecurityManagerは、Subjectに用いられるアイデンティティデータとセキュリティデータを取得するのに使われるレルムを管理します。

Detailed Architecture

以下はShiroのコアアーキテクチャを示す図です。

図：https://shiro.apache.org/assets/images/ShiroArchitecture.png

以下は個々の要素の概要です。

  • Subject(org.apache.shiro.subject.Subject))
    セキュリティ視点でのエンティティ（ユーザ・サードパーティサービス・cron・jobなど）の'ビュー'で、ソフトウェアと相互作用を行う。
  • SecurityManager(org.apache.shiro.mgt.SecurityManager)
    上述のように、SecurityManagerはShiroのアーキテクチャの中核要素です。SecurityManagerは基本的には配下の管理コンポーネント群をうまいこと動作させるための詳細を隠蔽しています。また、アプリケーションユーザごとのShiroのビューを管理しており、ユーザごとに必要となるセキュリティ操作も管理しています。
  • Authenticator(org.apache.shiro.authc.Authenticator)
    Authenticatorはユーザの認証（ログイン）要求に対する処理と反応を返すためのコンポーネントです。ユーザがログインをするとき、そのロジックはAuthenticatorが実行します。Authenticatorはユーザ／アカウント関連情報を格納している一つ以上のRealmsの処理を担っています。Realmsから取得するデータは、そのユーザが自分自身を誰だと言ってきているのかを保証するユーザ一意性(user’s identity)を検証するのに使われます。
    • Authentication Strategy (org.apache.shiro.authc.pam.AuthenticationStrategy)
      複数のRealmを設定する場合、AuthenticationStrategyは認証処理の成功と失敗を決定するためにRealms間の調整を行います（たとえば、もし一つのレルムが成功して他は失敗の場合、認証処理は成功とするのか？　すべてのレルムが成功しなければならないのか？　最初のみ成功でも通すのか？）。
  • SessionManager (org.apache.shiro.session.mgt.SessionManager)
    SessionManagerは、Sessionに関する堅牢なユーザ体験をあらゆる環境下で提供するため、ユーザSessionライフサイクルの作成と管理を担当します。セキュリティフレームワーク界隈においてこれはユニークな機能で、Web/ServletやEJBコンテナが利用可能でなくとも、Shiroはどんな環境でもユーザのSessionを管理する能力を有しています。デフォルトでは、Shiroは何らかの機構（Servletコンテナなど）が使えればそのセッション機構を使用しますが、それが無い場合、たとえばスタンドアローンアプリケーションや非web環境などでは、何らかの機構と同様の体験を提供するのにShiroに組み込まれているエンタープライズセッション管理を使用します。SessionDAOは何らかのデータソースがセッションを永続化するのを許可するために使います。
    • SessionDAO (org.apache.shiro.session.mgt.eis.SessionDAO)
      SessionDAOはSessionの永続化（CRUD）操作を実行するためのSessionManagerとのインタフェースです。このクラスを使うことで任意のデータストアをセッション管理インフラに組み込めます。
  • CacheManager (org.apache.shiro.cache.CacheManager)
    CacheManagerはShiroのコンポーネントが使用するCacheインスタンスのライフサイクルの生成と管理を行います。Shiroは多数のバックエンドデータソースにアクセスして認証・認可・セッション管理を行うため、キャッシュはフレームワーク内で主要機能であり、それらのデータソースを使用する場合のパフォーマンスを向上させるために存在します。高速かつ効果的なユーザ体験を提供するために、Shiroには最近のオープンソースまたはエンタープライズのキャッシュプロダクトを組み込むことが可能です。
  • Cryptography (org.apache.shiro.crypto.*)
    暗号化はエンタープライズのセキュリティフレームには当然存在してしかるべきものです。Shiroのcryptoパッケージには理解しやすく使いやすい暗号・ハッシュ（ダイジェスト）・コーデック実装が含まれています。このパッケージのすべてのクラスは使いやすく理解しやすくなるよう特に注意を払って設計されています。Javaの暗号化サポートを知る人であれば、野獣の調教に挑むような経験をしているでしょう。Shiroの暗号化APIは複雑なJavaのメカニズムを単純化して一般的な人類*2にとって使いやすい形にしています。
  • Realms (org.apache.shiro.realm.Realm)
    上述の通り、レルムはShiroとアプリケーションデータ間の'ブリッジ'あるいは'コネクタ'として振る舞います。認証（ログイン）と認可（アクセス制御）を処理するのにユーザアカウントなどのセキュリティ関連データと相互作用する段階になると、Shiroはアプリケーションに設定されている一つ以上のレルムから各種データを参照します。必要な数（通常はデータソースごとに一つ）のRealmsを設定可能で、Shiroは必要に応じて認証と認可でレルムを使用します。

The SecurityManager

ShiroのAPIはSubject中心のプログラミングアプローチを取っているため、SecurityManagerを直接触るのは、無くは無いですが、滅多にありません（ただしフレームーワーク開発者は直接SecurityManagerを見るのが良い場合があります）。しかし、SecurityManagerの動きを知ることは重要で、アプリケーションでこれを設定する場合には特に重要です。

Design

前述のとおり、アプリケーションのSecurityManagerはセキュリティ操作を実行し、すべてのアプリケーションユーザの状態管理を行います。ShiroのデフォルトSecurityManager実装には以下が含まれます。

  • 認証（Authentication）
  • 認可（Authorization）
  • セッション管理（Session Management）
  • キャッシュ管理（Cache Management）
  • レルム間調整（Realm coordination）
  • イベント伝播（Event propagation）
  • ‘Remember Me'サービス（'Remember Me’ Services）
  • サブジェクト生成（Subject creation）
  • ログアウトなど（Logout and more）

なお、上記の機能の多くは単一コンポーネントを管理しやすくするための機能です。また、単一の実装クラスにすべてを詰め込もうとすると、柔軟性を持たせてカスタマイズしやすくするのは難しくなります。

設定／プラグインを柔軟にして単純化するため、Shiroの実装は設計に高いモジュール性を設けています。このモジュール性により、SecurityManagerの実装（とそのクラス階層）がすべての処理を行うわけではありません。一枚岩にする代わりに、SecurityManager実装はいわゆるライトウェイトな'コンテナ'コンポーネントの振る舞いをし、ネストないしラップするコンポーネントに多くの振る舞いをデリゲートします。この'ラッパー'設計は上述のDetailed Architectureの図にある通りです。

デリゲート先のコンポーネントが実際にロジックを実行するので、SecurityManagerの実装は、何らかの振る舞いを行うコンポーネントをいつ・どのように実行するか、に責任を持ちます。

SecurityManagerの実装はJavaBeans互換のため、JavaBeans標準のgetter/setterメソッドでプラガブルなコンポーネントを簡単にカスタマイズできます。Shiroアーキテクチャのモジュール性は振る舞いをカスタマイズするための設定容易性に表れています。

Easy Configuration
JavaBeans互換のため、JavaBeansスタイルの設定をサポートするSpring, Guice, JBossなどで、カスタムコンポーネントによるSecurityManagerの設定を簡単に行えます。

設定については次のConfigurationを参照してください。

Lend a hand with documentation

Apache Shiroで何かを作る際にこのドキュメントが役に立つことを願いますが、コミュニティが成長すればドキュメントも常に拡張していきます。もしShiroプロジェクトに興味がある場合、必要だと感じたドキュメントの追加・修正・収集をお願いしたいと思います。ほんの少しの助けであってもコミュニティは前進し、結果としてShiroも前進します。

ドキュメントをコントリビュートする最も簡単な方法はこのページ下のEditリンクをクリックしてプルリクエストをサブミットするか、User ForumあるいはUser Mailing Listに送信します。

*1:Subject instances are all bound to (and require) a SecurityManagerが原文なんだけど(and require)が良く分かんなくて訳文には含めていない

*2:原文はnormal mortal human beingsで、マジメに訳せば、普通のいつか死ぬ人間だが、言うまでもなくシャレあるいは複雑なジャバに対する皮肉と思われるが、訳文は無難にしておいた。