11

当社では、CAS サーバーを使用した SSO によって保護された複数の Web アプリケーションを展開しています。ユーザーはアプリケーションの URL を要求し、まだ認証されていない場合は、CAS サーバーのログイン ページにリダイレクトされます。認証が成功した場合、ユーザーは最初に要求された URL にリダイレクトされます。一般的なワークフローであり、完全に機能します。

ただし、CAS サーバーを使用して REST API を保護する必要もあります。好ましいフローは次のとおりです。

  • ユーザーがアプリケーション REST API のトークンを作成する
  • このトークンを使用して、ユーザーは一時的なアクセス トークン (CAS トークンなど) を要求できます。
  • REST Api への各要求で、ユーザーは一時アクセス トークンを HTTP ヘッダーまたは要求パラメーターとして含めます。
  • REST Api アプリケーションは、提供された一時トークンの有効性を CAS サーバーに対してチェックします。

CAS サーバーがサポートする OAuth のように聞こえますが、ユーザーはいつでも資格情報を求められることはありませんが、サービス、つまり API を呼び出す他のアプリケーションにも認証を提供したいと考えています。

  • 開発者が REST Api トークン (CAS ユーザーに関連付けられている) を要求する
  • アプリケーションは、Api トークンを使用して一時的なアクセス トークンを要求します
  • API への追加のリクエストには、一時的なアクセス トークンが HTTP ヘッダーまたはリクエスト パラメータとして含まれます。
  • REST API アプリケーションは、有効性について CAS サーバーに対して一時アクセス トークンをチェックします

REST Api アプリケーションは、ユーザー資格情報について何も知らず、ユーザー データベースにアクセスすることさえできません。これは、アプリケーションを使用する人間にとっては問題なく機能します (CAS ログイン ページにリダイレクトします)。

CAS サーバーを大幅にカスタマイズし、この動作を自分で実装することなく、このフローを実装する方法がわかりません。

Google はServer to Server Applications の OAuth 2.0 にJWT を使用しています。

誰かが（CASサーバーに）ヒントや代替手段を提供できれば幸いです。誰かがすでに CAS サーバーを使用してこのパターンを実装しており、この問題に関する情報を提供できる可能性があります。

よろしく、マルコ

4

2 に答える 2

11

最後に、簡単な方法で機能するようになりました。

CAS サーバーで:

  • 特定のservice-urlにclientIdとclientSecretを提供することで、クライアントがCAS サービス チケット STを取得できるようにする REST エンドポイントを実装しました。clientIdとclientSecretは、それぞれユーザー名とパスワードと見なされます。
    • REST エンドポイントは新しいカスタムTokenBasedAuthenticationCredentialsオブジェクトを作成し、それをCentralAuthenticationServiceに渡してTGT と ST を付与します ( STが付与されるサービス URLはclientIdとclientSecretのペアに関連付けられており、たとえば user-データベースclientId|clientSecret|serviceUrl )。
  • TokenBasedAuthenticationCredentialsのみをサポートする新しいAuthenticationHandlerとCredentialsToPrcincipalResolverを実装しました。

REST エンドポイント/cas/../tokenは JSON オブジェクトを返します。

{ serviceTicket: 'ST-ALKSJDFLSJDFLKJ-Ljksdf-sdflkjsf' }

(Spring ベースの) CAS クライアント (保護されたリソース) で:

  • 有効化されたauthenticateAllArtifacts
<bean id="serviceProperties" class="org.springframework.security.cas.ServiceProperties">
    <property name="service" value="${cas.service.url}" />
    <property name="sendRenew" value="false" />
    <property name="authenticateAllArtifacts" value="true"/>
</bean>
  • CasAuthenticationFilterを拡張し、 obtainArtifact(request)をオーバーライドして、HTTP Authorization-HeaderからSTを取得します。

これで、保護されたリソースにアクセスしたいクライアントは、

  • CAS サーバーからSTを取得し、
  • 保護されたリソースへの各要求でSTをAuthorization-Headerとして提供する
GET /rest/foo/bar HTTP/1.1
ホスト: www.example.com
承認: CUSTOM_SCHEME ST-ALKSJDFLSJDFLKJ-Ljksdf-sdflkjsf

CAS クライアントCasAuthenticationFilterはリクエストごとにアーティファクト (つまり、ST ) を取得するため、クライアントは単一のリクエストで認証されます。

さらに、CAS サーバーでは、n回の要求 (CAS クライアントがCAS サーバーでserviceValidate url を要求する回数)に対してのみ有効になるようにSTを構成できます。

これは、CAS サーバーとクライアントを大規模にカスタマイズする必要がなく、その後重大なセキュリティ上の欠陥を作成する必要がない、非常に良い方法だと思います。

于 2014-08-26T13:49:09.877 に答える
0

サービス券は1回限りの利用ではないのですか?

于 2014-11-21T14:40:47.033 に答える