ゴール：
Jenkins ジョブをトリガーし、Crowd サーバーに対してユーザーを認証するアプリケーションを作成したいと考えています。Jenkins での操作を許可するには、ユーザーが別のクラウド グループに属している必要があります。
設定：
Crowd2 プラグインを使用して、Atlassian Crowd 2.1 サーバーに対して Jenkins ユーザーを認証しています。
私の考え：
現在、Jenkins には 2 種類のリモート実行があります。
Jenkins REST API (認証にユーザーごとのトークンを使用)
ビルドは、次のような方法で「TOKEN」を使用してこの呼び出しを介してトリガーできます:
JENKINS_URL/job/JOBNAME/build?token=TOKENJenkins CLI (認証に SSH キーを使用)
ビルドは、SSH 秘密鍵を使用してコマンド ライン ツールを介してトリガーし、ユーザーを認証できます。
トークンアプローチ（REST API）...
... アプリケーションが API トークンを知る必要があります。
API トークンの制限を回避するにはどうすればよいですか?
Crowd 内に API トークンを保存しますか?
Crowd2 Jenkins プラグインは、Jenkins API トークンを群衆属性 (群衆ユーザー ディレクトリ内に格納できるユーザー定義のプロパティ) として格納できますが、これは 1 つの方法です。Crowd に登録されている他のすべてのアプリケーションから属性が取得される可能性があるため (これにより、ユーザーに代わって Jenkins ジョブを実行できるようになります)、これはセキュリティ上の欠陥である可能性があると思います。
Q:適切なアプローチと十分な安全性はありますか? 私の意見では、これは十分に安全ではありません。
Jenkins に対してアプリケーション クラウド トークンで認証しますか?
また、Crowd の API を介してクラウド トークンを生成し、Jenkins クラウド 2 プラグインが渡された Crowd トークンを Crowd に対して検証することを期待して、そのトークンを Cookie として Jenkins REST API を要求しようとしました。しかし、それは機能しません (私のブラウザーから群衆トークンを使用する場合、Firefox でページ情報を調べることによって、もちろん機能します)。
このアプローチ (crowd2 プラグインが渡されたトークンをチェックするかどうか) にセキュリティ上の欠陥があるかどうか、そしてクラウド トークン メカニズムがそのように機能するように設計されているかどうかはわかりません。ただし、すべての API リクエストでトークンが有効かどうかを確認する必要があるため、Jenkins のパフォーマンスに悪影響を与える可能性があると確信しています。
Q:良いアプローチと可能性は?
CLIアプローチ...
...Jenkins に登録されている SSH 秘密鍵をアプリケーションが認識している必要があります。
Jenkins が SSH キーの追加をサポートするなら、それは良いアプローチでしょう。私のアプリケーションは、SSH キー ペア (ランダム) のパスワードを生成し、ユーザーに代わって公開キーを Jenkins 内に自動的に保存できます。
Jenkins とおそらく認証プラグインを拡張する必要がありますが、これは正しい方法だと思います。
Q:このアプローチは可能で、十分に安全ですか?
Q:他のアプローチはありますか?
Jenkins は認証用の OAuth エンドポイントを実装するか (Crowd プラグインの場合は、Crowd に認証を委任する必要があります)、ユーザー管理をコアから完全に切り離す必要があると思います。私が間違っている？
必要に応じて、この質問の改善にご協力ください。私は 2 つの問題を混ぜ合わせており、目標を十分に明確に説明していなかったと想像できます。
注:この質問は、作成後 1 時間以内に編集されました (最初のコメントを参照してください)。