カスタム Credential Provider の開発

Windows Vista以降の OS のログインは従来の GINA方式 から Credential Provider 方式になっています。

1. GINA では、GINA　DLL からエクスポートする関数が決められていて、その関数を実装しました。

2. GINA 方式では、カスタム GINAがすべてを機能を実現することは不可能でした。 Windows 標準の msgina に依存しなければならない機能があり、エクスポート関数から msgina 内の同じエクスポート関数を呼び出す必要がありました

3. CP は COM になりました。Windows 標準の CP に依存することなく、カスタム CP ですべての機能を実装できるようになりました。


カスタム CP は、マイクロソフト提供の CP　サンプルをもとに作成することが推奨されてます。

このブログと同じタイトルの Japan Platform SDK Support Team Blog の記事が以下 URL にあります。

http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2011/04/22/credential-provider.aspx

この記事の内容を参考にしながら、CP サンプルをカスタマイズして独自 CP を開発していくことになるはずです。

弊社では CP サンプルをもとに MxLogon / GAuthLogon を作成していますが、１つ教訓を得ました。それは、CP のサンプルのコードは鵜呑みにしない、コードを確認しないまま使わないで、どのような処理をしているのか、そして、それが正しく処理されているかをある程度確認てから使うようにしないと、最後までバグに悩まされるということです。

Web には CPサンプルのバグが指摘している記事がいくつか見つかります。どこにも書かれていない問題点も存在するようです。

カスタム CP 作成のできるだけ早い段階で CP サンプルコードを確認することを勧めたいと思います。

CP V1 / V2 の２つのバージョンがありますが、V2 を先に開発すると V1 は V2のコードに V1/V2専用のコードを define 追加することで、容易に１つのコードベースから V1/V2 のどちらでも生成できるようになると思われます。

MxLogon は USBキーを利用した CP でUSBキーの抜き差しを検知して動作を決めます。ハードウェアの抜き差しを検知して動きを変える CP 開発は、ハードウェアと使わない CP と比較すると格段に難しくなるという印象があります。 その理由の１つは、CP が同時に２つ実行されることがあるからだと思います。サンプルのコードは同じ CP が同時に複数実行されることを想定していないようなので、カスタム CP ではそれを想定してカスタマイズする必要があります。

最初はソフトだけで完結する フルCP から作成して、その後ハードウェアを使う CP に手をつけたほうが、長期的には早道になるような気がします。