2011年12月27日火曜日

[告知]カンターラ・イニシアティブ・セミナー2012 Winter

2/1にカンターラ・イニシアティブのセミナーをやります。

今回は、JNSA(日本ネットワークセキュリティ協会)のIDMワーキンググループとの共同開催ということで、両方にちょっとずつ絡んでいる私もパネルディスカッションに参加します。
テーマが「グローバル企業におけるID管理」ということで、純日本製SIerの私としては何を話そうか迷うところですが、、、

他にもJNSAのクラウド環境におけるアイデンティティ管理ガイドブックよりアイデンティティ管理プロジェクトにおける失敗事例のパターンの話や、特権管理ソリューションの話、マイナンバーの話など非常に幅広いテーマで講演があるので、月初という忙しい時期だとは思いますがよろしければ是非。

■告知ページ
http://kantarainitiative.org/confluence/pages/viewpage.action?pageId=57606150

■アジェンダ

13:30    受付開始
14:00    開会挨拶  カンターラ・イニシアティブ ジャパン・ワークグループ
14:05-14:35 講演  「アンチパターンから学ぶID管理」
           JNSA ID管理WGより NTTコムウェア 駒沢 健
14:40-15:20 講演  「特権ユーザ管理とは ~登場の背景と求められる機能」
           日本CA株式会社 楠木 秀明
15:30-16:00 講演  「共通番号制度・国民ID解説」
           株式会社NTTデータ 技術開発本部 小山 武士
16:00-16:50 パネルディスカッション 「グローバル企業におけるID管理」
        パネラー
         JNSA ID管理WGリーダー 宮川 晃一(日本ビジネスシステムズ株式会社)
         日本オラクル株式会社 下道 高志
         伊藤忠テクノソリューションズ株式会社 富士榮 尚寛(MS MVP)
17:00頃 終了予定


2011年12月19日月曜日

[FIM2010] R2 で強化されたパスワード管理機能 - その1


# 久しぶりに本業?の FIM の話題です。

ようやく RC 版がリリースされた FIM2010R2 ですが、今回は新しく追加されたパスワード管理機能について試してみます。

無印のころは Windows ログオン画面でのパスワードリマインダ機能だけでしたが、R2 からは Web ベースでのパスワード登録およびパスワードリセット機能が実装されています。

・無印のころのパスワードリセット画面


































この機能は Windows クライアントのみ、且つ全員がドメインに参加しているという状況下においては非常に有用な機能でしたが、非ドメインユーザなどには使えない、という欠点がありました。
(ドメインユーザであれば PC にログオンできない環境下でも使える、というのは運用上とても良い機能でした)


その点、R2 からは Web ベースでのパスワードリマインダが実装されているので、以下の様な流れで秘密の質問の登録およびリセットを行うことが出来ます。(設定方法はそれなりに手間がかかるので、別途まとめます)
ちなみに今回は AD と FIM のユーザを同期した状態、且つ AD MA のパスワード変更を有効にした状態がベースです。ですので、FIM でパスワードをリセットすると Active Directory のパスワードがリセットされます。

・パスワード(秘密の質問)の登録画面



























































































# ちなみに相変わらず秘密の質問の回答に日本語は使えません。。


続いてパスワードリセット画面です。こちらも Web 化されています。





これで、無事にパスワードがリセットされました。
一旦ログオフして、再度ログオンするときは新しいパスワードになっているはずです。


2011年12月13日火曜日

Windows Azure Active Directory


Azure 方面では大幅アップデートでお祭り状態?になっているみたいですが、ひっそりとアイデンティティ関連に関してもアナウンスがされています。
詳細はこれから徐々に出てくると思われますが、現状出ている情報から見えるところだけとりあえず。


まず、タイトルが「Windows Azure Active Directory」になっています。
http://www.windowsazure.com/en-us/home/tour/access-control/

少しずつ本文から抜粋します。
Windows Azure Active Directory is a cloud service that provides identity and access capabilities for applications on Windows Azure and Microsoft Office 365. Windows Azure Active Directory is the multi-tenant cloud service on which Microsoft Office 365 relies on for its identity infrastructure. 


Windows Azure 上のアプリケーションおよび Office365 用のアイデンティティ&アクセス機能を提供、とあります。
これまで、似たようなサービスではありましたが、全く別の基盤として稼働してきた AppFabric ACS と Office365 のアイデンティティ・プラットフォームでしたが、ついに統合?されることになりそうです。(単なるブランド統合だけかもしれませんが)

【参考】
これまでの Office365 のアイデンティティ・プラットフォーム。
ACS と同様に AD FS2.0 とのフェデレーションが出来ましたがあくまで Offce365 専用。

































こんな記述もあります。
You can enable single sign-on, security enhanced applications, and simple interoperability with existing Active Directory deployments using Access Control Service (ACS), a feature of Windows Azure Active Directory

AppFabric ACS の位置づけが明確に Windows Azure Active Directory の一機能とされています。

こんな記載もあるので、やれることとしては既存の Active Directory と一緒に使うことによって SSO などを実現、とあるのでそれほど変わらないのかと。
You can quickly extend your existing on-premises Active Directory authentication to your cloud applications through ACS. By using your existing user directory as the authoritative identity provider, users are authenticated to your cloud applications with their existing accounts.   


標準技術への対応に関する記述は以下の通り。OpenID 2.0 との記載は以前からありましたが、OpenID Provider の追加は非サポートでした。今後はどうなるのかちょっと期待。
Integrated and customizable Home Realm Discovery so users can choose their identity provider with support for Windows Live ID, OpenID 2.0, Google, Yahoo, Facebook, and enterprise providers such as Windows Active Directory.


その他ですが、最近の Azure 界隈はかなり OSS に寄っている気がします。以下の記述を見ても Ruby の記述があるあたりが OSS 開発者を強く意識しているのかな?と思います。
ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby, and has out-of-the-box support for popular web identity providers including Windows Live ID, Google, Yahoo!, and Facebook. 


今回はまだリリースされている情報が少ないので、機能面ではあまり見えておらず、単なるリブランディングなのか?とも思えますが、引き続き要ウォッチです。

A Guide to Claim-Based Identity and Access Control 2.0 の eBook 版がリリース


以前のポストでも紹介したとおり、先日第2版もリリースされたお馴染み Claims Guide ですが、このたび eBook 版がリリースされています。
MSDN のサイトで公開されていたものです)

PDF でダウンロード出来るのでお手元のモバイル端末へ入れておくのが吉かと。
http://www.microsoft.com/download/en/confirmation.aspx?id=28362



2011年12月11日日曜日

[AD FS2.0]属性ストアへのアクセス権限について


前回に引き続き AD FS2.0 の属性ストアに関するネタです。

AD FS2.0 の属性ストアとして設定可能なのは、
・SQL Server
・LDAP
・カスタム
があることは前回紹介しましたが、各属性ストアへのアクセス権限については注意が必要です。

そもそも AD FS2.0 のサービスから各属性ストアへのアクセスはどのようなセキュリティ・コンテキスト(ユーザ)で実行されるのか?について理解しておくことが必要ですので、どんなユーザでアクセスが発生しているのかをカスタム属性ストアのコードの中にデバッグコードを書いて見てみました。
少々ベタですが、Initialize メソッドの先頭に以下の様に System.Environment.UserName (ユーザ名)、SystemEnvironment.UserDomainName (ドメイン名)をファイルへ出力するようにコードを書いてみます。

public void Initialize(Dictionary<string, string> config)
{
   System.IO.StreamWriter sw = new System.IO.StreamWriter(@"C:\temp\adfs.txt",false,System.Text.Encoding.GetEncoding("shift_jis"));
   sw.Write("ユーザ名 : " + System.Environment.UserName);
   sw.WriteLine();
   sw.Write("ドメイン名 : " + System.Environment.UserDomainName);
   sw.Close();

結果、ファイルには以下の様な文字列が書き込まれました。

ユーザ名 : IDP$
ドメイン名 : ADFS20
※コンピュータ名が IDP 、ドメイン名が ADFS20.LOCAL の環境下。

これは、AD FS2.0 のサービスを起動しているユーザ(シングル構成だとデフォルトで Network Service)を指しています。証拠にサービスの構成でサービス実行ユーザを Administrator に変更すると、以下の様に書き込まれる値が変わります。

ユーザ名 : Administrator
ドメイン名 : ADFS20


さて、これは
各属性ストアへ AD FS2.0 起動ユーザへのアクセス権限を与える必要がある
ということを意味します。(AD FS2.0 で認証されたユーザの権限ではないところがポイント)

MSDN の属性ストアに関連する記述を見るとデフォルトで設定できる、SQL Server および LDAP について以下の様な記述があります。(ポイントのみかいつまんでいます)
URL : http://technet.microsoft.com/en-us/library/adfs2-help-attribute-stores(WS.10).aspx

■SQL Server
1. SQL Server 属性ストアを設定するときは「Server=CONTOSOSRV01;Database=UserAttributes;Integrated Security = True」という様な接続文字列を AD FS2.0 の属性ストアに設定する必要がある。

2. マイクロソフトとしては、SQL Server へのアクセスは Windows 統合認証を使うことを推奨する。もし SQL Server 認証を使う場合はユーザ名およびパスワードに関する情報が AD FS2.0 の構成データベースの中にクリアテキストで保持されることになる。


解説すると、接続文字列の中の「Integrated Security = True」の部分は SQL Server へのアクセスを Windows 統合認証で行うことを指しています。
もちろん、「Server=CONTOSOSRV01;Database=UserAttributes;User Id=MyUser; password= P@ssw0rd」という形で接続文字列を設定することも可能ですが、属性ストアのパラメータとしてそのまま AD FS2.0 に設定されてしまうので、パスワード部分が丸見えになってしまうので推奨しない、ということです。

ただ、Windows 統合認証を使う場合は上記で述べたように AD FS2.0 を実行しているユーザで SQL Server へアクセスしてしまうので、あらかじめ SQL Server 側で当該ユーザへのログオン許可および必要なロールの割り当てを行っておく必要があります。

■LDAP
1. LDAP 属性ストアを設定するときは RFC 2255 に記載されているような LDAP URL をパラメータに指定する必要がある。
(例:ldap://localhost:56000/cn=AdfsUsers,o=Microsoft,c=US)

2. LDAP 属性ストアへのアクセスは Windows 統合認証を使用する必要がある。


ポイントは SQL Server の場合と異なり、LDAP へのアクセスにはバインドユーザとパスワードを指定することが出来ないので、 Windows 統合認証をサポートする LDAP サーバ(実質 AD LDS くらいしかない?)を用意しておく必要がある、というところです。



上記を踏まえてカスタム属性ストアを作成する場合は以下の考慮が必要です。

・Windows 統合認証でアクセスできる場合は、属性ストア側に AD FS2.0 実行ユーザへの権限を与えておく必要がある
・独自の認証を使う場合は、AD FS2.0 側のパラメータとして設定を行うことは可能だがクリアテキストで保持されてしまうので注意が必要である


MSDN フォーラムなどを見ていると LDAP を使いたいけど Windows 統合認証が必須、というあたりに引っかかっている人が結構いそうなので、OpenLDAP 対応のカスタム属性ストアなどを作って公開したらヒーローになれるかも、、です。

2011年12月7日水曜日

[AD FS2.0]カスタム属性ストアを作成する


AD FS2.0はその名の通り初期状態では、参加している Active Directory ドメイン上の情報(属性)をクレームとして発行します。

例えば、

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"), query = ";userPrincipalName;{0}", param = c.Value);

といった形で要求記述言語を記載すれば Active Directory 上のユーザの userPrincipalName 属性を NameIdentifier タイプのクレームとして発行します。


他にも、AD FS2.0 の属性ストアとして利用できるのは標準で
・LDAP
・SQL Server
があります。

それらの標準で用意されている属性ストアにない情報をクレームとして発行したい、という場合はどうすればよいのか?というと、「カスタム属性ストア」を自分で作って(コーディングして)利用することが出来ます。


ここで少しおさらいですが、 SAML IdP の一般的な構造に従い、AD FS2.0 は以下の様な構造になっています。




























ここで注意なのですが、AD FS2.0 の属性ストアはあくまで属性オーソリティが参照する先のレポジトリである、という点です。つまり、AD FS2.0 の構成要素である認証オーソリティが参照する先はあくまで Active Directory である、という点です。
残念ながら認証オーソリティの参照先を別のシステム(LDAP や他のレポジトリ)に変更することは AD FS2.0 ではできません。(2要素認証などを含むカスタム認証を行う場合は、AD FS2.0 のログインページをカスタマイズすることである程度は対応可能です)

ですから、クレームに含まれる属性を SQL Server や LDAP や今回紹介するテキストファイルから取得することはできますが、これはそれらのシステムで認証を行うわけではなく、認証を行った後に属性を取得することが出来るだけである、ということになります。


前置きが長くなりましたが、早速実装してみます。

細かいところは MSDN の記載を参考にするとして、今回は基礎編として MSDN にサンプルとして記載されているカスタム属性ストアを組み込んでみます。
http://msdn.microsoft.com/en-us/library/ee895358.aspx

紹介されているサンプルはテキストファイルに記載されている属性情報をクレームとして発行する、というものです。


■レポジトリとなるテキストファイルの用意

まずは、元となるテキストファイルを作成します。(C:\temp\data.txtとして保存します)
EmployeeID,EmployeeName,Age,Department,Role
1,John,33,HR,Manager
2,Jane,25,Sales,Vendor
3,Tim,45,Marketing,Evangelist
4,Leann,33,IT,Administrator


■カスタム属性ストア用のライブラリの作成

次に、AD FS2.0 サーバ上に Visual Studio 2010 をインストールし、MSDN のページにあるサンプルコードをコピペして、DLL を作成します。プロジェクトの種類はクラスライブラリを選択します。
# ここで注意なのですが、.NET Framework は3.5を選択する必要があります。.NET Framework 4.0 で作成した DLL だと 3.5 でビルドされている AD FS2.0 から参照できません。 
# Microsoft.IdentityServer.ClaimsPolicy.dll という AD FS2.0 のライブラリを参照する関係で AD FS2.0 がインストールされている環境に Visual Studio をインストールします。(ライブラリをコピーすれば他の環境でもビルドできるとは思いますが、試していません)
# もちろん、WIF SDK もインストールしておく必要があります。

コードは先ほどの MSDN のページのサンプルをそのままコピー&ペーストしますが、その前に参照設定を行う必要があります。
必要なのは、
・Microsoft.IdentityModel
・Microsoft.IdentityServer.ClaimsPolicy
です。



























Microsoft.IdentityServer.ClaimsPolicy については AD FS のインストールフォルダ直下にあるので直接参照します。





























コンパイル出来たら作成した DLL ファイルを「 %Program Files%\Active Directory Federation Services 2.0 」以下にコピーしておきます。


■作成したライブラリを AD FS2.0 のカスタム属性ストアとして登録する

最後は AD FS2.0 に作成したカスタム属性ストアを認識させる作業になります。

まず、AD FS2.0 管理コンソールを起動し、[信頼関係]-[属性ストア]を選択して右クリックして出てくる[カスタム属性ストアの追加]メニューを起動します。





























表示名に「FileAttributeStore」、カスタム属性ストアのクラス名に「CustomAttributeStores.FileAttributeStore,CustomAttributeStores」を設定します。






































次にパラメータを設定します。
今回のサンプルでは
・パラメータ名:FileName
・値:c:\temp\data.txt
と設定します。






















ここまで出来るとカスタム属性ストアを使用する準備が整うので、あとは適当なアプリケーションから利用してみます。


■アプリケーションから利用する

通例に従い、証明書利用者信頼(Relying Party)を作成します。
要求規則ルールにカスタムルールを設定し、以下の様なルールを記載します。
例では、要求規則のルールに age が 45 の人の name と role 属性を取得し、クレームとして発行する、というルールとなっています。











































後は、実際にアプリケーションにアクセスしてみます。
今回のアプリケーションではわたってきたトークンからクレーム・タイプが role の値を取得して表示する、というロジックを記載しているので、以下の様に Evangelist という文字列が表示されます。























詳しくはサンプルで使ったソースを読むとわかるのですが、BeginExecuteQuery メソッドの中で渡されたパラメータに従い、ストアの中から任意の値を返す、というロジックを記載さえできればどんなレポジトリでも属性ストアとして登録することが可能です。

海外には PowerShell の実行結果をクレームとして発行するための PowerShell Attribute Store を作って公開している強者もいたりします。
以下、参考までに。
http://www.theidentityguy.com/articles/2011/11/19/powershell-attribute-store-for-ad-fs-20.html

2011年12月6日火曜日

[Office365] ディレクトリ同期ツールの64bit版はFIM2010のビルド5.x


先日のエントリで 64bit 版のディレクトリ同期ツールがリリースされたことを書きましたが、ようやくインストールする時間が取れたので少し構造を見てみました。

やり方としては非サポートですが、前回ベータ版で行った方法(Synchronization Server の管理コンソールを直接起動)です。

ベースとなっている物のバージョンですが、前回は Identity Lifecycle Manager 2007 FP1 がベースでしたが、64bit 化に伴い、 Forefront Identity Manager 2010 がベースになっています。

ビルドを見てみると、ビルド番号は 5.0.227.2 となっています。





































ん?5.x
これまで FIM2010(Synchronization Service)のビルドは 4.x (無印は 4.0.x、R2 は 4.1.x)でした。

参考)現状の FIM2010 のビルド一覧
4.0.2592.0 RTM
4.0.3531.2 http://support.microsoft.com/kb/978864
4.0.3547.2 http://support.microsoft.com/kb/2028634
4.0.3558.3 http://support.microsoft.com/kb/2272389
4.0.3561.2 http://support.microsoft.com/kb/2443871
4.0.3573.2 http://support.microsoft.com/kb/2417774
4.0.3576.2 http://support.microsoft.com/kb/2502631
4.0.3594.2 http://support.microsoft.com/kb/2520954
4.1.1906.0 R2 RC


ちなみにこれは歴史を振り返ると
・Zoomit VIA (マイクロソフトによる買収前) / 流石にビルドバージョンは知らない。。。
・Microsoft Metadirectory Server 2.x (日本未発売) / Build 2.x
・Microsoft Identity Integration Server 2003 / Build 3.x
・Identity Lifecycle Manager 2007 / Build 3.x
・Forefront Identity Manager 2010 / Build 4.x
という形で内部バージョンを持っていました。

ここで 5.x が本流の FIM とは別の流れで出てしまった、という事実は次の FIM のメジャーバージョンアップに何か影響があるのでしょうか。。。
まぁ同期のアーキテクチャは既に10年以上もほぼ変わっていないので、そろそろ別のものに??もしくは打ち止め??などと想像してしまいます。

2011年12月4日日曜日

Tao of Attributes - 属性之道 於京都 に参加してきました


11/30 の Internet Week および 12/1 の OpenID Summit Tokyo に引き続き 12/2 は京都にて「Tao of Attributes - 属性之道 於京都」が開催されました。

私は OpenID Summit Tokyo と Tao~ に参加したのですが、 OpenID Summit 側にはプレスも入っていましたし、他にもまとめてくれている人がいる(これとかこれ)ので、今回は Tao~ について少し書いておきたいと思います。

といっても当日参加された方はご存じだとは思いますが、かなりカオスな感じ(良い意味で)で進んだワークショップだったのではっきり言って理解&メモしきれていません。(全編英語でしたし)

まぁ一番の収穫?はこの分野で世界的にもトップを走っている方々でもまだまだ整理がしきれていないんだな、という妙な安心感?が得られたこと。。です。

アジェンダの順に徒然とメモを書いておきます。

Session 1 Tao of Attributes

1. Tao of Attributes / Ken Klingenstein, Internet2

 ・ロールとは何か?
  →属性、クレームをまとめたもの
  →誰がまとめるのか。コミュニティ、会社、属性プロバイダ・・・など
  →動的に変化するもの
  →それっていわゆる「アイデンティティ」だよね?

 ・メタデータの重要性
  →相互フェデレーションを可能とする

 ・メタデータの新しい要素
  →LoA(Level of Assuranse)※前日の OpenID Summit でも属性単位の LoA の話が出ていた
  →グラフィカルなアイコン
  →サービス属性、、など
  →ユーザの同意が必要

 ・属性オーソリティ(発行元)のタイプ
  ・企業:従業員コードとか
  ・政府機関、自治体:パスポート番号とか
  ・一時的なもの:位置情報とか
  ・コミュニティ
   ・フォーマル:バーチャルな組織
   ・インフォーマル:うわさ
  ・自分自身:使用する言語とか

 ・PII(Personal Identifiable Information)の分類(かっこないは例)
  ・個人を特定しない属性(ePSA)
  ・プライバシのために設計された間接的な識別子(ePTID)
  ・プライバシのために設計されていない間接的な識別子(IPアドレス)
  ・直接の識別子(名前、住所)
  ・メールアドレスとFAX番号
  ・位置情報(携帯電話)
  ・センシティブ情報(健康状態、人種、宗教)


2. Attribute Exchange within eduGain Members and Scheme / ValterNordh, eduGAIN

 ・eduGain のサービスの紹介
  ・http://www.geant.net/service/edugain/pages/home.aspx
  ・フェデレーション間の接続サービス(インターフェデレーションサービス)
  ・ディスカバリサービス
  ・メタデータサービス(MDS)

 ・メタデータのやり取りの方法
  ・フェデレーションからMDSへのメタデータの送付(アップストリーム)
  ・フェデレーションがMDSよりメタデータの取得(ダウンストリーム)

 ・属性リリース問題
  ・IdP管理者はどの属性が他のフェデレーションへ渡されているのかを知る必要がある
   (eduGainではメタデータの中のスキーマで工夫)


3. Attribute Verification Methods / Kick Willemse, OpenID Foundation

 メモれず・・・
 属性の分類と必要に応じて対象の属性が保証されていることが必要、という話。
 (さすがに資料なしのチョークトーク、且つカオスな感じにはついていけず)


4. Good Practice in Japan: Credit Mutual Exchange in Kyoto eLearning Consortium / Toyokazu Akiyama and Koji Ozaki, Kyoto Sangyo University

 ・eラーニングシステムをコンソーシアム参加大学の間で共有するために Shibboleth を導入した
  ・コンソーシアムには50の大学が参加
  ・生徒が自身で登録して利用するシステムだったため、各大学の事務局が各登録を確認していたが手間が大かった
  ・Shibboleth を導入して各大学の IdP と連携出来る様に。


5. Scope of SCOPE for OpenID Connect / Nat Sakimura, OpenID Foundation

 時間切れでスキップ



Session 2 Level of Assurance

6. GakuNin LoA Story / Hiroyuki Sato, University of Tokyo

 時間切れでスキップ


7. Challenge at Kyoto University / Yasuhiro Nagai, Kyoto University

 ・LoA は「利用頻度 x セキュリティレベル」の2軸で考えている
 ・各セキュリティレベルに応じて以下の認証レベルを導入している
  Level 1 ) フェース to フェース の認証なし
  Level 2 ) 静的パスワード+ICカード
  Level 3 ) 静的パスワード+ICカード+動的パスワード(ワンタイムパスワード)
  Level 4 ) 静的パスワード+ICカード+電子証明書
 ・電子証明書は学生証(Felica)に最初から入れてある


8. The University PKI Architecture in Japan and the LoA / Yasuo Okabe, Kyoto University

 ・3つのレイヤーで PKI を構築/利用
  ・Open Domain PKI / SMIMEなど外部とのやり取りに利用
  ・Campus PKI / キャンパス内システムに利用
  ・Grid PKI / コンピューターグリッドに利用

 ・UPKIの仕様は以下のURLより
  https://upki-portal.nii.ac.jp/upkispecific/specific


9. Discussion

 時間切れ、というより各セッション内で。。。


10. Dinner

 がんこ
 絶景でした。山縣有朋の別邸だったそうです。


2011年12月1日木曜日

OAuth 2.0 仕様書の翻訳版リリース!

AppFabric ACSv2 や WIF を使ったり、facebook をはじめとするソーシャル API を使おうとすると避けて通れないのが OAuth です。

これまでも OpenID Technight などで仕組みの解説がありましたし、一部当ブログでも紹介しましたが、厳密に知ろうと思うと原文のスペックを読むしかなく、ハードルが高かったのが現状です。

そんな方に朗報です!
OpenID Foundation Japan の翻訳ワーキンググループの活動で OAuth 2.0 core draft 22 および Bearer draft 11 の仕様書の日本語版がリリースされました。
(私も一部お手伝いをさせていただきました)

http://openid-foundation-japan.github.com/

ぜひ、一度ご覧いただければと思います。