アーカイブ

Archive for 2010年9月

LightSwitchの裏側を探る:ユーザー認証とアクセス許可

2010年9月25日 コメントを残す

前の記事で動作を確認したユーザー認証とアクセス許可の裏側をのぞいてみます。

まずユーザー認証に使われるデータベースですが、これはASP.NETに組み込まれているユーザー認証の仕組みをそっくり使っているようです。
テーブル/ビュー/ストアドプロシージャ等見慣れたものが並んでいます。
また、ServerGeneratedフォルダにあるWeb.configを見ると、メンバーシップ/ロール/プロファイルを利用するための設定が記述されており、これもASP.NETそのものです。
プロファイルとしてFullNameというプロパティが設定されていますが、これがユーザー登録画面で「氏名」として使われているようです。

パーミッションについては、ApplicationDefinition.lsmlに以下のように設定されています。

<Permission Name="一般">
    <Permission.Attributes>
        <DisplayName Value="一般" />
    </Permission.Attributes>
</Permission>
<Permission Name="管理者">
    <Permission.Attributes>
        <DisplayName Value="管理者" />
    </Permission.Attributes>
</Permission>

やはりLightSwitchのキモとなるのはApplicationDefinition.lsmlファイルのようですね。

それからログイン画面、ユーザー画面、役割画面ですが。。。

ログイン画面については情報が見つけられていません。

ユーザ画面、役割画面についてはMicrosoft.LightSwitch.Client.dll の中に
・Microsoft.LightSwitch.Security.Client.Implementation.UsersScreen
・Microsoft.LightSwitch.Security.Client.Implementation.RolesScreen
というクラスが存在しています。
多分このクラスがそれぞれの画面なのではないかと思われます。

なお、前の記事では言及していませんが、アプリケーションのプロパティでScreen NavigationをみるとUsers、Rolesという画面があらかじめ用意されていることがわかります。

 image

Access ControlにはあらかじめSecurityAdministrationというパーミッションが用意されているので、このパーミッションを付加してデバッグを実行するとユーザー画面や役割画面を見ることができます。

image_3

ただし、ここでユーザーや役割を登録してみたところで開発中は必ず「testuser」になってしまうため、意味はなさそうです。

少し触ってみて不満に思うことは、この作り付けのユーザー画面に拡張性がなさそうな部分です。
例えばログインしているユーザのメールアドレスを保持しておいて、なにか処理したときに確認メールを送信したい、といった機能は容易に想像されるのですが、これを実装するためにログインユーザーとメールアドレスを簡単に関連づけするための方法が見つけられていません。
どうもログインユーザーを保持しているテーブルに直接アクセスする方法もなさそうですし。
ログイン画面に対しても何も手を入れることができないようなので、独自に用意したテーブルを使ってユーザー認証を行う、というのもできなさそうなんですよねぇ。。。

今のLightSwitchの実装だとユーザー認証のための情報は本当にログインするためだけにしか使えないようになっていると考えています。
もうちょっと柔軟にいろいろ使えるようになるといいんですけどねぇ。
まぁ、現在の実装ではユーザ情報を修正することさえできない(フォーラムで次のバージョンで実装予定という記述があったような)状態なので、今後良い方向に発展してくれることを期待したいと思います。

カテゴリー:LightSwitch, Silverlight

LightSwitch:ユーザ認証とアクセス許可

2010年9月25日 コメントを残す

注)この記事の記述はベータ版の仕様に基づいています。今後機能に変更が加わる可能性があります。

LightSwitchにはユーザ認証の機能が組み込まれています。
データベースやWeb.Configの設定を見ると、ASP.NETと同じものをベースにユーザ認証を実装しているものと思われます。
ただし、このユーザ認証ですが、開発中に利用することができません。
作成したアプリケーションを配置してはじめてユーザ認証を利用することができるようになっています。
では、ログインするユーザによって画面の表示/非表示を切り替えるのにはどうするか。
この答えはパーミッション(アクセス許可)を利用する、ということになると思われます。

○動作確認用の画面を作成する

アクセス許可の動作を確認する準備として、まずは画面を作成します。

LightSwitchのアプリケーションを新規に作成し、アプリケーションのプロパティでCultureをJapaneseに設定、Application Typeが「Desktop client, 2-tier deployment」になっていることを確認します。
2-tierのタイプに設定しておくのは、とりあえず動作を確認するための配置の作業が簡単だからです。

次にScreenを追加します。
とりあえず Search Data Screenを選択し、Screen Dataの設定をせずに、Screen Nameを「一般表示用画面」として作成します。

 image

同様に「管理者表示用画面」も作成します。

「一般表示用画面」で「Add Data Item…」をクリックしてUserNameというローカルプロパティを追加します。

 image_3

画面エディタ内のAddボタンをクリックし、UserNameを表示するラベルを追加します。

 image_4

Write Code ドロップダウンリストから「一般表示用画面_Loaded」を選択します。

image_5

コードエディタが表示されるので、以下のとおりに記述します。
このコードは認証されているユーザがいる場合、そのユーザ名を表示するためのコードになります。

image_6

とりあえずここで一度デバッグ実行してみます。
一般表示用画面と管理者表示用画面を持ったアプリケーションが表示されます。

 image_7

○パーミッションを設定する

パーミッションの設定はアプリケーションのプロパティのAccess Controlタブから行ないます。
Form認証を有効にし、「一般」と「管理者」というパーミッションを作成します。

image_8

○アクセス権限の設定

「一般表示用画面」のWrite Code ドロップダウンリストから「CanRun一般表示用画面」を選択します。

image_9 

コードエディタに以下のように記述します。
このコードは認証されているユーザが「一般」権限を持っているときに表示する、という意味になります。

image_10

同様にして、「管理者表示用画面」を「管理者」権限を持っているユーザだけが表示できるようにします。
アプリケーションのプロパティのパーミッションの作成画面に戻り、「一般」と「管理者」パーミッションのGranted for debugチェックボックスにチェックをつけてアプリケーションをデバッグ実行してみましょう。

image_11

ここでチェックをつけたパーミッションがデバッグの実行時ユーザに付加されるので、上記のように2つのパーミッションにチェックが入っていれば、画面は2つとも表示されます。
管理者のチェックをはずし、一般のみチェックした状態で実行すると、下記のように「一般表示用画面」のみが表示されることになります。

image_12

ここで画面の表示をよくみると、UserNameとして「TestUser」が表示されていることに気づきます。
開発中は必ずこの「TestUser」としてログインしているものとして実行されてしまうようです。
とりあえずここまでで動作確認用のアプリケーションの構築を終了し、アプリケーションを配置してみることにします。

○アプリケーションの配置

アプリケーションの配置はBuildメニューのPublishから実行します。

image_13

最初に配置パターンが2-tierでよいか確認がはいります。
そのままNextボタンをクリックします。

image_14

次に発行場所とデータベースをどう設定するかの確認がはいります。
とりあえずこのままNextボタンをクリックします。

image_15 

データベースとの接続文字列の確認が行われます。
特に変更せずに続けていくと、開発マシンに直接データベースを発行して利用するような設定になります。

image_16

次にデフォルトの管理ユーザを作成する画面になります。
パーミッションの作成をした画面で説明していなかったのですが、あらかじめ全体を管理するためのパーミッションが一つ設定されています。
ここで作成するユーザはそのパーミッションを使ってアプリケーションの全体を管理するユーザになります。

image_17

次は配置に必要なモジュール等の設定になります。
とりあえずこのまま先にすすみます。

image_18

接続設定の確認、となりますが、このままPublishボタンをクリックします。

image_19

ここまでを実行すると、データベースが開発マシン内に構築されます。
SQL Server Management Studioで確認すると、アプリケーション名(ここではApplication4)と同名のデータベースが作成されていることがわかります。

image_20 

また、アプリケーションのソースが含まれているフォルダ内に「Publish」フォルダが追加されています。

image_21 

○アプリケーションのインストールと実行

Publishフォルダ内のsetup.exeを実行します。

image_22 

セキュリティの警告がでますが、ここで「インストール」を実行します。

image_23

アプリケーションがインストールされ、ログイン画面が表示されます。

image_24

○ロールとユーザーの作成

配置作業のウィザードの中で作成した管理ユーザのユーザ名/パスワードを入力し、ログインします。
Administrationメニューとしてユーザーの管理画面と役割(ロール)の管理画面が表示されます。

image_25 

ロールとして「一般ユーザーロール」を追加し、そのアクセス許可に「一般」を追加します。
また、「管理ユーザーロール」を追加し、そのアクセス許可として「一般」と「管理者」を追加します。

image_26 

ユーザーを作成します。
「user1」には「一般ユーザーロール」を、「user2」には「管理ユーザーロール」を追加します。

image_27

LightSwitchにはログアウトの機能はないようです。
ユーザーを変更するには一度アプリケーションを終了させる必要があります。

インストールしたアプリケーションは[スタート]-[すべてのプログラム]から実行することができます。

image_28

○ユーザー(ロール)に付加したアクセス許可の動作の確認

user1でログインすると、一般表示用画面だけが利用できます。

image_29

user2でログインすると、管理者表示用画面も利用できることが確認できます。

image_30 image_31

○まとめ

いろいろ調べていてわかりにくかったのが、ユーザー認証の仕組みはしっかり組み込まれているのに、開発時にはその仕組を利用できない、という部分でした。
普通に考えると、例えば画面の表示/非表示は役割(ロール)によって制御するものだと思い込んでいましたから。

アクセス許可の仕組みがユーザー認証とは別に存在し、開発時にはアクセス許可の状態を自由に設定して動作の確認ができることが理解できてみると、アクセス許可として細かい設定を多く作成しておきロールはそのアクセス許可を組み合わせたものとすることでより柔軟な制御が可能になるな、と納得しているところです。

アクセス許可が利用できるのは画面の表示/非表示だけではないようなので、そのあたりもう少しつっこんで調べていきたいと思います。

カテゴリー:LightSwitch, Silverlight