許可されていないユーザーから保護する必要がある Web サービスがあります。ユーザー名とパスワードに基づいて、ユーザーを承認する Web サービス操作を公開する必要があります。ユーザー検証要求への応答には、セキュリティ トークンが含まれている必要があります。そのセキュリティ トークンには、クライアント アプリケーションが使用できるいくつかの埋め込みユーザー プロパティが含まれていますが、暗号化されている場合は、後続の Web サービス操作の認証にも使用されます。暗号化されていないトークンは次のようになります。
UID=444; DTE=2012-06-01T14:01:54.9571247Z; GID=1; WID=00:1C:B3:04:85:11; SID=lit3py55t21z5v55vlm25s55;
キーはクライアントとサーバーの間の共有シークレットになる可能性があるため、対称キーアルゴリズムを使用できます (両方を制御します)。SHA1 と 256 のキー サイズを使用して、次のRijndael の例を実装しました。
このコードはインターネット上でよく引用されますが、Microsoft 自身は Rijndael に関連して次のように述べています。
Rijndaelクラスは、Aesアルゴリズムの前身です。Rijndaelの代わりにAesアルゴリズムを使用する必要があります。詳細については、.NET セキュリティ ブログのエントリー「Rijndael と AES の違い」を参照してください。
セキュリティ上の懸念事項はありますか? もしそうなら、サンプルコードをどのように変更しますか、または誰かがより良い、より安全な例を提供できますか?
最後に、別の方法として、Windows Azure アクセス コントロール サービスを使用して、独自の ID プロバイダーに対してセキュリティ トークンを発行し、そのトークンを使用してユーザー アカウント データを別の呼び出しとして取得することを検討しています。アプリケーションは Azure で実行されているため、これはより適切な実装でしょうか? このようなアーキテクチャに ACS を使用した経験を共有したい人はいますか?
ところで: クライアント アプリケーションは iOS 5 です。