ひよっこ。

I want to…

    広告
  • つぶやき。。。

    • 間違って違うワークスペースでヘルプを出してしまった。怖... 19 hours ago
    • うーん、notificationなどで利用するComponent内で限定した(Reactで言う)stateを持ちたいんだけど...。素直にhyperappのstateで保持するか。 1 day ago
    • ふと気になって調べてみたら、ESNextの OptionalChainingはstage1にはいるのか。 github.com/tc39/proposal-… 2 days ago
    • @JorgeBucaran ありがとうございます。ちょっと試してみます。ondestroyのログは取れてたので、 > This event is not called in its child elements. が原因かなと思ってました。 2 days ago
    • SlackってNGOや教育割り引きあったのか。おおよそ85%オフとのこと get.slack.help/hc/ja/articles… 2 days ago
  • archive

  • ジャンル

  • tag

SpringSecurityのMethodSecurityとFilterSecurityではまる

Posted by hikaruworld : 2011 1月 10

結論は、Interceptorを行うFIlterの実装が異なっていた事でした。

現在SpringSecurityを使って設定する場合には、
階層構造定義を以前設定したように行っています。

ROLE_ADMIN > ROLE_LEADER
ROLE_LEADER > ROLE_USER

ただ、この設定でメソッドレベルアノテーションに@Securedを設定した場合に、
上手く行きませんでした。

@Secured(value = "ROLE_LEADER")
public String hoge() {
	return "hoge";
}

ロギングを有効にして(org.springframework.security -> debug)確認してみると、
org.springframework.security.access.vote.RoleHierarchyVoterと、
org.springframework.security.access.vote.RoleVoterがなぜか呼ばれています。

RoleHierarchyVoterは自信で階層構造を設定しているので、
利用されていて当然なんですが、RoleVoterが謎。

ちょっとデバッグしてみると、
FilterSecurityInterceptorとMethodSecurityInterceptorに注入されています。

つまり、Filterレベル(主として認証)の実装は指定した物を参照しているが、
Methodレベル(主として認可)の実装がデフォルト値が利用されているということでしょうか。

というわけで、こんな感じに設定したら解決しました。

<!-- accessDecisionManagerは任意に設定したアクセス管理のインスタンス -->
<global-method-security secured-annotations="enabled" access-decision-manager-ref="accessDecisionManager"/>

うーん。Springの空気読みっぷりを読まなかった自分が悪いなぁと、痛感。

以上です。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

 
%d人のブロガーが「いいね」をつけました。