問題タブ [spring-security-oauth2]

ユーザー登録とログインフローを実装しようとしています | Spring Security Oauth 2.0 と Google を認証プロバイダーとして使用する SSO。

• 登録とログインの流れをどのように開始すればよいですか? どのフィルターを適用する必要がありますか?

• 登録フローでは、成功した認証応答の一部であるユーザーの詳細 (名前、電子メール) をローカル データベースに保持する必要があります。どうすればそれを処理できますか？

• oauth2:client id="oauth2ClientFilter" の目的は何ですか?

これは私のアプリケーションコンテキストファイルがどのように見えるかです:-

編集

Spring Security OpenID を使用して同じユースケースを実装しました:-

1. exchange 属性が設定された openid:form タグの宣言
2. ここで説明されているように UserDetailsS​​ervice を拡張します。

Oauth 2.0 の同等の構成を探しています。

現在、Spring OAuth 2.0 In Memory Token Store を使用するアプリケーションがあります。Spring Security OAuth 2.0 JAR を変換して、サーバーの再起動時にアクセストークンが有効であることを確認するために、メモリ内ではなく永続化されたファイルを使用する必要があります。Spring OAuth 2.0 JAR は、JdbcTokenStore メソッドを使用して MYSQL データベースをサポートするルーチンを提供しますが、サポートされている Jdbc メソッドを利用するためにデフォルト構成 (InMemoryTokenStore メソッドを使用) を変更する方法を説明するドキュメントを見つけることができません。

Spring Security OAuth 2.0 JdbcTokenStore メソッドを実装し、そのために必要な構成の例を提供してくれる人、またはプロセスを説明するドキュメントを教えてくれる人からの連絡をお待ちしています。インターネット上で高低を検索しましたが、そのようなドキュメントは見つかりません。

Token Store 用の Spring Security OAuth 2.0 スキーマ ファイルを既に見つけました。興味のある方は、Test Resource ディレクトリにしかありません。その存在は、どの Pivotal ドキュメント Web サイトでも文書化されていません。必要に応じて、残りの Pivotal ソース コードを読むこともできますが、このパスを使用する必要がなくなることを誰かが助けてくれることを願っています。

ご協力いただきありがとうございます。

アプリケーションに Spring を使用して OAuth2 用の API の作成に取り組んでいますが、仕様 ( https://www.rfc-editor.org/rfc/rfc6749 ) にも Spring OAuth2 ドキュメントにも、クライアント シークレットの生成方法については何も書かれていません。

誰にもアイデアはありますか？

重複する URL に対して異なる ROLE を指定するように春のセキュリティを構成する方法がわかりません。

このユーザーにユーザー ROLE_ADMIN がなくても、/app/ws** でロール ROLE_WEBSERVICE を持つユーザーを受け入れる必要があります。

ドキュメントの正しい場所を教えていただけますか? 私はそれを見つけることができませんでした。ありがとう。

SpringMVC アプリケーションから Struts2 アプリケーションに OAuth2 構成を移行する際に考慮すべき点は何ですか?

この SpringMVC アプリケーションの例に従って、Struts2 アプリケーションに OAuth2 を実装しようとしています。

例をさらに単純にするためにコードを削除してきましたが、それらの唯一の違いorg.springframework.web.servlet.DispatcherServletはサンプル アプリケーションにあります。

両方のアプリケーションの OAuth 構成が同じであることに加えて、私のアプリケーションは次の例外をスローし続けます。

org.springframework.security.oauth2.client.resource.UserRedirectRequiredException: ユーザーの承認を得るにはリダイレクトが必要です

サンプル アプリケーションの実行時。

Spring Security を使用して中央認証/承認サーバーをセットアップし、そこから JWT トークンをフェッチして、別の Spring Security バックアップ REST サーバー上の制限付きリソースにアクセスするために使用できるようにしたいと考えています。

これが私のフローです：

1) HTML JS / モバイルなどのクライアントは、認証サーバーで認証して JWT トークンを取得します 2) クライアントは、HTTP ヘッダーでこのトークンを REST サーバーに送信して、保護されたリソースへのアクセスを取得します

関連するすべてのデータを含めることができ、REST サーバーは完全にステートレスで、トークンをデコードするだけで REST サーバー上の必要なすべてのデータ (ロール、クライアント ID、電子メールなど) を取得できるため、このシナリオには JWT が最適だと思いました。

これに対してOauth2は正しい選択ですか?もしそうなら、誰かが親切に私を正しい方向に向けることができますか? JWTが適切でない場合、私は他の解決策を受け入れます:)私の場合、RESTサーバーのデータベースからクライアント情報をロードすることも可能であることに言及する必要がありますが、ユーザーの認証を担当するべきではありません(つまり、ユーザー名/パスワードのチェックはなく、トークンのデコード/検証のみです...)

ログアウトコントローラーでは、コードの組み合わせをたくさん書いてみました。今私はこれを持っています：

ただし、コード実行トークンを提供した後も有効です。

私は何を間違っていますか？最終的にトークンを取り消す方法は?

前もってお詫び申し上げます。春のセキュリティを使用するのはこれが初めてです。

オープン シフト jbossews スプリング コンテキストが起動に失敗するという問題がありますが、スタンドアロンの tomcat サーバーでは完全に動作します。トークン認証を使用して API と通信し、ユーザーの基本的なフォーム認証を使用しようとしています。さらに情報が必要な場合はお知らせください。

Tomcat では、Web サーバーを表示し、curl を取得してトークンを取得し、/api/** でサービスを呼び出すことができます。

スタックトレース

web.xml

oauth-context.xml

security-Context.xml

servletApp-context.xml

Spring Integration Yoda が登場

私は、JSF アプリケーションから起動された JavaScript ウィジェットへの REST Web サービス呼び出しを有効にすることに取り組んでいます。サービスの実装は REST easy に既に存在し、OAuth 2.0 セキュリティは含まれていません。目標は、セキュリティ ゲートウェイを介してすべての JS 呼び出しを渡しながら、サービスをそのままにしておくことです。

目標を達成するために、Mule Enterprise で最初のプロトタイプを作成し、Spring セキュリティの OAuth 拡張と HTTP インバウンド/アウトバウンド エンドポイントを使用しました。これは Mule が提案したアプローチでした。

その後、私の 2 番目のプロトタイプは、Spring Security/Spring の統合に関するものです。そして、本質的に同じ OAuth 2.0 プロバイダー、セキュリティ ルール、および HTTP インバウンド/アウトバウンド ゲートウェイです。春のサポートで作業しているときに、これはうまくいかないと言われました（理由は以下）。私の理解では、Mule と SI は非常に似ており、1 つの「接着剤」を別の接着剤に置き換えることができるはずです。これは SI の想定された用途ではないかもしれません。まだ使用できるかどうかを検証したいと思います。

また、基本的にパイプを作成してオーバーヘッドを削減するゲートウェイの構成は何ですか?

私の理論を検証または反証するために時間を割いていただきありがとうございます。

イレナ

構成コードの抜粋:

サポートの返信:

SI はおそらくこの種の機能には適していません。理由は次のとおりです。

• spring 統合は、メッセージに「メッセージ」タイプを使用します。チャネルに入るすべてのものは、タイプが「メッセージ」である必要があります。これは事実上、すべての HttpRequest を SI メッセージに変換する必要があり、その逆も同様であることを意味します。HttpResponse も同様です。

• spring 統合は HttpRequest オブジェクトを直接公開しません。むしろ、リクエスト処理を簡素化する SI で暗黙的に内部的に処理されます。つまり、リクエストパラメーター、ヘッダー値、パス変数への簡単なアクセス...しかし、あなたの場合、これは複雑です。そして複雑さは、インバウンド ゲートウェイの構成で見ることができます。

• 特に大規模なリクエスト (ファイルのアップロードなど) の場合は、より一般的な問題が後で発生する可能性があります。このようなリクエストはすべて、プロキシのメモリ内で内部的に処理されるため、問題が発生する可能性があります

• すべてのリクエストが個別のスレッドで処理されるため、同時実行パフォーマンスの問題が発生する可能性がありますが、この問題は SI 固有ではありません

代理目的で SI を使用することを再考する理由をいくつか挙げました。この決定を下した理由はわかりませんが、これに関する例、チュートリアル、またはブログ投稿を見たことがありますか? はいの場合はお知らせください。確認します。

今後どのような決断を下すかは、あなた次第です。しかし同時に、これは技術サポートの範囲を超えているため、代わりに何を使用するかについては何も考えていません. しかし、ご興味がありましたら、当社の技術担当者に連絡し、コンサルティング サービスを手配することができます。

認証とトークンの生成に Spring セキュリティ Oauth2 を使用して、Java で 1 つの RESTEasy サービスを作成しました。すべてが正常に機能していますが、サービスにアクセスしてブラウザ REST クライアントからトークンを生成しようとすると、資格情報が要求されて失敗しますが、同時に Java の HTTPClient で同じサービスにアクセスすると機能します、

JavaのHttpクライアントは機能しますが、ブラウザーの残りのクライアントでは資格情報を要求し、不正な要求を返します

なぜそれが起こるのですか？

私の構成、