SpringSecurityダイジェスト認証
1. 概要
このチュートリアルでは、Springを使用してダイジェスト認証を設定、構成、およびカスタマイズする方法を示します。 基本認証をカバーする前の記事と同様に、Spring MVCチュートリアルの上に構築し、SpringSecurityが提供するダイジェスト認証メカニズムでアプリケーションを保護します。
2. セキュリティXML構成
構成について最初に理解することは、Spring Securityはダイジェスト認証メカニズムを完全にサポートしていますが、このサポートは名前空間に基本認証ほど統合されていないことです。
この場合、セキュリティ構成を構成する生のBean を手動で定義する必要があります– DigestAuthenticationFilterおよびDigestAuthenticationEntryPoint:
<beans:bean id="digestFilter"
class="org.springframework.security.web.authentication.www.DigestAuthenticationFilter">
<beans:property name="userDetailsService" ref="userService" />
<beans:property name="authenticationEntryPoint" ref="digestEntryPoint" />
</beans:bean>
<beans:bean id="digestEntryPoint"
class="org.springframework.security.web.authentication.www.DigestAuthenticationEntryPoint">
<beans:property name="realmName" value="Contacts Realm via Digest Authentication" />
<beans:property name="key" value="acegi" />
</beans:bean>
<!-- the security namespace configuration -->
<http use-expressions="true" entry-point-ref="digestEntryPoint">
<intercept-url pattern="/**" access="isAuthenticated()" />
<custom-filter ref="digestFilter" after="BASIC_AUTH_FILTER" />
</http>
<authentication-manager>
<authentication-provider>
<user-service id="userService">
<user name="user1" password="user1Pass" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>
次に、これらのBeanを全体的なセキュリティ構成に統合する必要があります。この場合、名前空間はまだ十分に柔軟であり、それを実行できます。
この最初の部分は、カスタムエントリポイントBeanを指します。 エントリポイント-ref メインの属性
2番目の部分は、新しく定義されたダイジェストフィルターをセキュリティフィルターチェーンに追加することです。 このフィルターは機能的にBasicAuthenticationFilterと同等であるため、チェーン内で同じ相対位置を使用しています。これは、 Spring SecurityStandardFilters全体のBASIC_AUTH_FILTERエイリアスによって指定されます。 。
最後に、ダイジェストフィルターが次のように構成されていることに注意してください。 ユーザーサービスBeanを指す –ここでも、名前空間は、によって作成されたデフォルトのユーザーサービスのBean名を指定できるため非常に便利です。
<user-service id="userService">
3. 保護されたアプリケーションの消費
curlコマンドを使用して、セキュリティで保護されたアプリケーションを使用し、クライアントがアプリケーションと対話する方法を理解します。
ホームページをリクエストすることから始めましょう–リクエストでセキュリティクレデンシャルを提供せずに:
curl -i http://localhost/spring-security-mvc-digest-auth/homepage.html
予想どおり、 401Unauthorizedステータスコードで応答が返されます。
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=CF0233C...; Path=/spring-security-mvc-digest-auth/; HttpOnly
WWW-Authenticate: Digest realm="Contacts Realm via Digest Authentication", qop="auth",
nonce="MTM3MzYzODE2NTg3OTo3MmYxN2JkOWYxZTc4MzdmMzBiN2Q0YmY0ZTU0N2RkZg=="
Content-Type: text/html;charset=utf-8
Content-Length: 1061
Date: Fri, 12 Jul 2013 14:04:25 GMT
この要求がブラウザによって送信された場合、認証チャレンジは、単純なユーザー/パスワードダイアログを使用してユーザーに資格情報の入力を求めます。
ここで、正しい資格情報を提供し、リクエストを再度送信しましょう。
curl -i --digest --user
user1:user1Pass http://localhost/spring-security-mvc-digest-auth/homepage.html
–digestフラグを介してcurlコマンドのダイジェスト認証を有効にしていることに注意してください。
サーバーからの最初の応答は同じです– 401 Unauthorized –しかし、チャレンジは2番目の要求によって解釈され、実行されます– 200OKで成功します。
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=A961E0D...; Path=/spring-security-mvc-digest-auth/; HttpOnly
WWW-Authenticate: Digest realm="Contacts Realm via Digest Authentication", qop="auth",
nonce="MTM3MzYzODgyOTczMTo3YjM4OWQzMGU0YTgwZDg0YmYwZjRlZWJjMDQzZWZkOA=="
Content-Type: text/html;charset=utf-8
Content-Length: 1061
Date: Fri, 12 Jul 2013 14:15:29 GMT
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=55F996B...; Path=/spring-security-mvc-digest-auth/; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Content-Length: 90
Date: Fri, 12 Jul 2013 14:15:29 GMT
<html>
<head></head>
<body>
<h1>This is the homepage</h1>
</body>
</html>
この相互作用に関する最後の注意点は、クライアントが最初の要求で正しい承認ヘッダーをプリエンプティブに送信できるため、サーバーのセキュリティチャレンジと2番目の要求を完全に回避できることです。
4. Mavenの依存関係
セキュリティの依存関係については、 SpringSecurityMavenチュートリアルで詳しく説明されています。 つまり、spring-security-webとspring-security-configをpom.xmlの依存関係として定義する必要があります。
5. 結論
このチュートリアルでは、フレームワークのダイジェスト認証サポートを活用して、単純なSpringMVCプロジェクトにセキュリティを導入します。
これらの例の実装は、 Githubプロジェクトにあります。これはEclipseベースのプロジェクトであるため、そのままインポートして実行するのは簡単です。
プロジェクトがローカルで実行されている場合、ホームページのhtmlにアクセスできます(または、最小限のTomcat構成では、ポート80で)。
http:// localhost:8080 / spring-security-mvc-digest-auth / homepage.html
最後に、アプリケーションが基本認証とダイジェスト認証のどちらかを選択する必要がある理由はありません – クライアントが選択できるように、同じURI構造で両方を同時に設定できますWebアプリケーションを使用するときの2つのメカニズムの間。