Authentication in Avatar
Legacy Java EE Home The Java EE project has been contributed to Eclipse Foundation and has been renamed to Jakarta EE. All active work is taking place at this new location https://projects.eclipse.org/projects/ee4j https://jakarta.ee/specifications The following legacy archives are available for anyone who wishes to browse the extensive history, prior to contribution to Eclipse. Key Java EE resour
JavaServlet : コンテナの機能を使わずにBASIC認証を行う
BASIC認証はほとんどのWebサーバー、Webブラウザが対応しており、簡単に使えることが特徴ですが、パスワードはクリアテキスト(平文)で送られます。 実際はE-Mailの添付ファイルでよく使われるBASE64という形式でエンコードされていますが、暗号化されているわけではないのでデコードして改ざんすることも容易です。 ですから、多くの場合はSSLとあわせて暗号化して用いられます。 Tomcat等のサーブレットコンテナにも、このBASIC認証(基本認証)を行う機能が付いています。「web.xml」ファイルで認証方式等を指定し、 コンテナで実際の認証処理を行います。この方法で簡単に認証を実装できるコンテナもありますが、当然ながらコンテナに依存してしまいます。 たとえば、Tomcat用に作ったものは、そのままではWebSphereやWebLogicでは動作しないでしょう。 これが問題になる場合(
まずはGAE/J＋slim3でOpenID、そしてOpenID認証とTwitter認証両方に対応してみる - 何度やっても同じ
管理画面で設定 まずは管理画面の「Application Settings」で「Authentication Options」を変更する。初期状態で「Google Accounts API」となっているのを「Federated Login」に変更して、保存。 ログインが必要なページのURLをweb.xmlに記述 この設定変更を行った上で、web.xml に次のように記述してページを保護すると、未ログイン状態で保護されたページにアクセスしたときに、Googleのログイン画面ではなく、/_ah/login_required というURLに自動的にリダイレクトされるようになる。ただし、開発サーバではリダイレクト先は /_ah/login となり、おなじみのやる気のないログイン画面が表示されるので、開発サーバでOpenIDを使った認証のテストはできそうにない。URL直打ちで /_ah/login_
Spring Security でアカウントロック機構を実現する - 倖せの迷う森
アカウントロック機構は、パスワード認証をともなうWebアプリケーションの開発ではしばしばセキュリティ要件として盛り込まれることがあります。また、Webサービスのユーザーとしても馴染みのある機能のひとつでしょう。今日は、この機能を Spring Security の認証の枠組みの中で実現する方法について紹介します。なお、本記事は Spring Security 3.0.4 をベースに書かれています。 いきなりですが、 Spring Security では、アカウントロック機構は提供されていません。アカウントをロックするのは認証サービスが行うべきことであり、認証サービスとアプリケーションをつなぐためのフレームワークである Spring Security には、そのような義務はありません。また、アカウントロックの実現方式についても、認証サービスに強く依存します。ですので、アプリケーションへの要求
第20回 Javaアプリケーション向けの認証フレームワーク「Apache Shiro」 | gihyo.jp
使いやすい認証機構を実現する「Apache Shiro」 今回取り上げる「Apache Shiro」は、Javaアプリケーション向けに開発された認証と承認のためのオープンソースのフレームワークです。Shiroを使うことで、ログインなどの認証の仕組みや、アクセス管理、セッション管理などといった機構を、容易にアプリケーションに付け加えることができるようになります。 JDKにはJAAS（Java Authentication and Authorization Service）という認証・承認サービスが用意されていますが、JAASで提供されるAPIはあまり使い勝手が良くなく、わかりにくいという意見が大多数を占めていました。ShiroはJAASよりも理解しやすく、簡単に利用できる認証・承認の仕組みを提供する目的で開発されました。Shiroを利用するメリットとしては次のようなものが挙げられています。
サーブレット仕様の認証を使わずにgetRemoteUserやisUserInRoleを使う。 - NullPointer's
JavaのWebアプリでユーザ認証を行う場合、サーブレット仕様で決められた認証機能を使うか、独自の認証機構を実装するか、いずれかであると思う。 サーブレットの認証機能を使うとHttpServletRequestのisUserInRoleやgetRemoteUserが有効になるのが地味に嬉しい。Strutsフレームワークのロールによるアクセス制御も有効になるのでサーブレットの認証機能は結構使える。一方、独自の認証機構を使うと自由にログイン処理を記述できる代わりにHttpServletRequestのgetRemoteUserやisUserInRoleは使えない。 しかし独自の認証でもHttpServletRequestWrapperとFilterを組み合わせれば、getRemoteUserやisUserInRoleを有効にできる。 まず、認証時にユーザ名とロールを適当な名前でセッションに格納
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - philipsorst/angular-rest-springsecurity: An example AngularJS Application that uses a Spring Security protected Jersey REST backend based on Hibernate/JPA
Modules
IBM Developer
http://blogs.sun.com/shioda/entry/q_a_opends_hot_topic