問題タブ [gssapi]

JavaでGSSを使用してS4Uプロトコルを実装しています。Java 7 はこのプロトコルをサポートしていないため、Java には同等のものがない C の gss api メソッドに JNI ラッパーを作成する予定です。

この一環として、http://k5wiki.kerberos.org/wiki/Projects/Services4User#gss_acquire_cred_impersonate_name で説明されているように、gss_acquire_cred_impersonate_name で JNI を作成してい ます。

このメソッドは、以前に設定された入力資格証明ハンドル (gss_cred_id_t) を取り、出力資格証明ハンドルを作成します。私の Java コードでは、gss_cred_id_t の形式で C 関数に渡す必要がある GSSCredential を作成し、さらに使用するために出力資格情報ハンドルを gss_cred_id_t から GSSCredential に変換する必要があります。

C 関数と通信するために、GSSCredential オブジェクトをバイト配列に、またはその逆にエクスポートするにはどうすればよいですか?

ありがとう

Kerberos 認証用のキータブがあるサービス間モデルがあります。

このモデルでは、ログイン構成を次のように定義しました:-

このログイン構成は、jaas.conf の代わりとして機能します。

今、機能している LoginContext のログイン メソッドを試しています。それから私はそれから主題を取得しています。

この件名を使用して、私は特権的な行動をとります。

これは失敗します。関連するログ（ログシステムのプロパティを設定した後に掘り出しました）：-

今、本当に困惑しているのはこれです:-

最初の部分は createCredential 自体のためのものです。ただし、2 つ目はメカニズム ファクトリ関連の呼び出し (この場合は kerberos) のようです。この後、ファイルベースの資格情報キャッシュ認証が開始されます。

0010: 43 4f 4d COM

これはどういうわけかメカニズム ファクトリが間違った値を取得していることを意味します。

IBM jar (ibmjgssprovider.jar) を逆コンパイルしてみましたが、内部のクラス名が文字化けしているようです (a、b、xy などに置き換えられています)。

これは最終的に次のようになります:- java.io.IOException: プライマリ プリンシパルが一致しません

私はプロプライエタリなので、IBM の振る舞いを理解するのに苦労しています。OpenJdk はあまり役に立ちません。

誰か助けてくれませんか。このような動作を引き起こす可能性があるのは、製品が設定しているシステム プロパティですか?

実行時に考えられるすべてのシステム プロパティを確認しようとしています。他に何か必要な場合はお知らせください。

また、誰かがIBM JDK Securityフォーラムも指摘できますか? この問題もそこに投稿したいと思います。

私が理解しているように、

• SPN は、Windows サービスの認証ツールです。
• Kerberos はユーザー認証サービスです
• SPNEGO-GSSAPI は、これらのサービスを利用できるサードパーティ API です。
• SSPI : SPNEGO から SPN サービスにリクエストを送信するニュートラル レイヤーです。

私は完全に迷っていますか？

それがどのように機能するかを理解しようとしていますが、情報は正確すぎるか、十分ではありません。

gss_export_name を使用して名前をエクスポートする際に問題が発生しました。名前がエクスポートされたら、それを印刷するだけでよいはずですが、文字通り EXPORTED NAME: , EXPORTED NAME LENGTH: 47 を空白にしています。

これが私のコードです

わかりやすくするために、チェックを含めないことにしましたが、major_status が常に == GSS_S_COMPLETE であることも確認します

過去数年間、ケルベロス認証のためにHeimdal / MIT Gssapiと「散発的に」作業する必要がありました。Linux ボックスで実行される Web サービスとして使用されるアプリケーションを構築し、Windows や Linux デスクトップおよびワークステーションで実行されるブラウザーなどのクライアント アプリケーションを提供する必要がありました。確かに、飼いならすのが最も簡単な獣ではありません。最終的に、自分の仕事を要約すると、多次元での課題が原因で困難が生じたことを記録することができました。gssapi プログラミングを始めるのは、ドキュメンテーションが貧弱で、チュートリアルが実質的に存在しないという理由だけで、本当に困難です。グーグル検索は、ほとんどの場合、ケルベロスとは何かについての理論的な議論につながるか、特定のセマンティックの問題以外はすべて知っているという前提で書かれたコンテンツにつながります。

これまでこのような wiki を実際に作成したことはありませんでした。また、私は GSSAPI や Kerberos の権威ではありません。親切にお願いしますが、それ以上に貢献して私の間違いを修正してください。サイト編集者の皆さん、魔法をかけてくれることを期待しています ;)

プロジェクトを成功させるには、次の 3 つのことを正しく行う必要があります。

1. テスト環境のセットアップ
2. ライブラリのセットアップ
3. あなたのコード

すでに述べたように、そのようなプロジェクトは獣です。3 つすべてが同じページにまとめられていないからです。

では、最初から始めましょう。

初心者にとって避けられない理論 GSSAPI は、クライアント アプリケーションが、サーバーがユーザーを正式に識別するための資格情報を提供するのに役立ちます。サーバーアプリケーションは、必要に応じて、ユーザーの要求に応じて、提供される応答を調整できるため、非常に便利です。したがって、当然のことながら、クライアント アプリケーションとサーバー アプリケーションの両方を kerberized にするか、kerberos 対応にする必要があります。

Kerberos ベースの認証では、クライアント アプリケーションとサーバー アプリケーションの両方が Kerberos レルムのメンバーである必要があります。KDC (Kerberos ドメイン コントローラー) は、レルムを支配する指定機関です。Microsoft の AD サーバーは、KDC の最も一般的な経験のある例の 1 つですが、もちろん *NIX ベースの KDC を使用することもできます。しかし、確かに KDC がなければ、Kerberos ビジネスはまったくあり得ません。ドメインに参加しているデスクトップ、サーバー、およびワークステーションは、すべてがドメインに参加している限り、お互いを識別します。

最初の実験では、クライアント アプリケーションとサーバー アプリケーションを同じレルムにセットアップします。ただし、Kerberos 認証は、これらのレルムの KDC 間に信頼を作成するか、相互に信頼していない異なる KDC からのキータブをマージすることによって、レルム全体で使用することもできます。このような異なる複雑なシナリオに対応するためにコードを変更する必要はありません。

Kerberos 認証は、基本的に「チケット (またはトークン)」を介して機能します。メンバーがレルムに参加すると、KDC は各メンバーに「トークンを付与」します。これらのトークンは一意です。時間と FQDN は、これらのチケットにとって重要な要素です。

コードの最初の行について考える前に、次の 2 つが正しいことを確認してください。

落とし穴 #1開発およびテスト環境をセットアップするときは、すべてがテストされ、FQDN としてアドレス指定されていることを確認してください。たとえば、接続を確認する場合は、IP ではなく FQDN を使用して ping を実行します。したがって、言うまでもなく、それらは必然的に同じ DNS サービス構成を持っている必要があります。

落とし穴 #2すべてのホスト システム (KDC、クライアント ソフトウェア、サーバー ソフトウェアを実行している) が同じタイム サーバーを持っていることを確認します。時間の同期は忘れるものであり、多くの頭を悩ませたり頭をぶつけたりした後、間違っていることに気付きます!

クライアント アプリケーションとサーバー アプリケーションの両方に kerberos キータブが必要です。したがって、アプリケーションを *NIX ホストで実行し、Microsoft ドメインの一部にする場合は、gss プログラミングの残りの準備手順を確認する前に、kerberos キータブを生成する必要があります。

Kerberos 5 (krb5 1.0) の相互運用性に関するステップバイステップ ガイドは、絶対に読む必要があります。

GSS-API プログラミング ガイドは優れたブックマークです。

*NIX ディストリビューションに応じて、コードをビルドするためのヘッダーとライブラリをインストールできます。ただし、ソースをダウンロードして自分でビルドすることをお勧めします。はい、一度に正しく理解できないかもしれませんが、苦労する価値は確かにあります。

落とし穴 #3アプリケーションが Kerberos 対応環境で実行されていることを確認してください。私はこれを本当に難しい方法で学びましたが、おそらく私はそれほど頭が良くないからです. gssapi プログラミングの苦労の初期段階で、アプリケーションを kerberos 対応にするためには kerberos キータブが絶対に必要であることを発見しました。しかし、これらのキータブをアプリケーションにロードする方法については何も見つかりませんでした。あなたが理由を知っている？！！そのようなAPIは存在しないため!!! 理由: アプリケーションは、キータブを認識する環境で実行されます。わかりました、これを簡単にしましょう: GSSAPI / Kerberos を実行することになっているアプリケーションは、キータブKRB5_KTNAMEを保存したパスに環境変数を設定した後に実行する必要があります。したがって、次のようなことを行います。

または、gssapi を使用するコードの最初の行が実行される前に、アプリケーションで十分にsetenv設定するために使用します。KRB5_KTNAME

これで、アプリケーションのコードで必要なことを行う準備が整いました。

アプリケーションを作成してテストするために、アプリケーション開発者がレビューしなければならない側面が他にもかなりあることは理解しています。重要な環境変数をいくつか知っています。

誰かがそれについてもう少し光を当てることができますか?

windows-xp は、kerberos プロトコルを理解するサーバーに認証ヘッダーの SPNEGO トークンを送信します。サーバーアプリケーションは、java が提供する gss-api を使用して実装されます。

私たちのコードは、spnego トークンから upn 名を抽出し、LDAP ストアに対して検証します。upn 名に ASCII 文字のみ (127 未満) が含まれている場合、すべて正常に動作します。

ただし、ユーザー名にASCII以外の文字(アイルランドのファダなど)が含まれている場合、Java gss-apiは何らかの理由でそれらをジャンク文字として解釈しています。

Java7 GSS 名に非 ASCII 文字を含めることができるかどうかを知りたいですか?