今までは動作の流れはチェックできたが Spring Security が用意した単なるお試し機構を使っていただけなので、 実用性がまったくゼロである。

ここで独自の認証機構を使いたい。

柔軟性を持たせるためなのかなんなのかわからないが、この辺から唐突に Spring Security が難しくなるのでじっくりいく。

ここでいろいろ登場人物が多くなるのでまとめる。 はっきり言って無駄に柔軟に出来ていて、Java の設計の悪い部分がモロに出てしまっていると思う。 (非常に柔軟にはできているのだが、現実問題組み合わせはそんなに無くてアホみたいにレイヤーとかクラスを大量に組み合わせないと実装できない)

AuthenticationToken というモノ、もしくはこれを実装、拡張したモノが登場するがこれはログインに必要な情報を保持しつつその認証の進行を状態を保持しているもの。

画面からの入力をこいつがまず受け取ることになる。

こいつが↑のAuthenticationTokenを生成し認証を開始する。

処理は次の認証そのものに進む

AuthenticationFilter の次に来るやつで、認証の Controller を担当するような感じ

何のデータを元に認証するかを決めるやつ

これは何でもいいが認証用の DAO みたいなモノである。

これも条件さえ整えばなんでもいいのだが、後にユーザー情報として保持されるモノになる。 UserDetailsSerivce から取得される。