Spring Security SAML ExtensionをSpring Bootと統合しようとしています。
この件については、完全なサンプルアプリケーションを開発しました。そのソースコードはGitHubで入手できます。
これをSpring Bootアプリケーション(SDK組み込みアプリケーションサーバーに対して実行)として実行することにより、WebAppは正常に動作します。
残念ながら、同じAuthNプロセスはUndertow / WildFlyではまったく機能しません。
ログによると、IdPは実際にAuthNプロセスUserDetails
を実行します。カスタム実装の指示は正しく実行されます。実行フローにもかかわらず、Springは現在のユーザーの権限を設定および保持しません。
@Component
public class SAMLUserDetailsServiceImpl implements SAMLUserDetailsService {
// Logger
private static final Logger LOG = LoggerFactory.getLogger(SAMLUserDetailsServiceImpl.class);
@Override
public Object loadUserBySAML(SAMLCredential credential)
throws UsernameNotFoundException, SSOUserAccountNotExistsException {
String userID = credential.getNameID().getValue();
if (userID.compareTo("jdoe@samplemail.com") != 0) { // We're simulating the data access.
LOG.warn("SSO User Account not found into the system");
throw new SSOUserAccountNotExistsException("SSO User Account not found into the system", userID);
}
LOG.info(userID + " is logged in");
List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>();
GrantedAuthority authority = new SimpleGrantedAuthority("ROLE_USER");
authorities.add(authority);
ExtUser userDetails = new ExtUser(userID, "password", true, true, true,
true, authorities, "John", "Doe");
return userDetails;
}
}
デバッグ中に、問題がFilterChainProxy
クラスに依存していることがわかりました。実行時の属性FILTER_APPLIED
にServletRequest
はnull値があるため、SpringはをクリアしSecurityContextHolder
ます。
private final static String FILTER_APPLIED = FilterChainProxy.class.getName().concat(".APPLIED");
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
boolean clearContext = request.getAttribute(FILTER_APPLIED) == null;
if (clearContext) {
try {
request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
doFilterInternal(request, response, chain);
} finally {
SecurityContextHolder.clearContext();
request.removeAttribute(FILTER_APPLIED);
}
} else {
doFilterInternal(request, response, chain);
}
}
上のVMwareのvFabric tcの断絶とTomcatの、すべてが完全に正常に動作します。この問題を解決することについて何か考えがありますか?
ところで、この動作は毎回ログインプロセスを無効にします。ASのソフトウェアを適切に構成するなどして、それを修正する方法はありますか?
—
vdenotaris 2014年
これが何を意味するのかわからない。どのような動作があり、ログインを無効にするにはどうすればよいですか?スレッドがリクエストの処理を完了したときにコンテキストをクリアすることは通常の動作です。スレッドローカルデータがスレッドプールにリークしないようにすることが重要です。その時点で、コンテキストは通常、ユーザーのセッションにキャッシュされます。したがって、ログインが無効になることはありません。
—
Shaun the Sheep
上記のように、SSOの後、アプリケーションサーバーはセッションデータと認証データをクリアします。これはWildflyでのみ発生します。同じコードがTomcatで正常に動作します。
—
vdenotaris 2014年
SecurityContextHolder.clearContext()
セッションデータは消去されません。ThreadLocal
スレッドを解放してスレッドプールに戻す前に、コンテキストのストレージを削除します。私のポイントは、これは常にリクエストの最後に発生するはずなので、表示されているのは正常であり、問題の原因である可能性は低いということです。
SecurityContextHolder
リクエスト後にをクリアする必要があります。そのコードの唯一の目的は、同じリクエスト中にフィルターチェーンが複数回適用される場合です(この場合、元のチェーンのみがコンテキストをクリアする必要があります)。だから私はそれが問題だとは思いません。