タグ

2019年2月27日のブックマーク (5件)

  • Spring Security SAMLとKeycloakの連携 - Qiita

    はじめに 昨年に引き続き今年もNRI OpenStandiaのメンバを中心にAdvent Calendarを書きます。昨年はKeycloakを中心とした構成としましたが、今年度はKeycloakに限定せず、オープンソースという枠で書いていきます(1日目はKeycloakが登場しますが。。)。それでは宜しくお願いします。 今回実現したかったこと 皆さん、最近アプリケーションは何で作っていますか?認証はどう作っていますか?昨今いろんな選択肢があると思います。今回私が関わったプロジェクト要件は下記のようなものでした(最近のエンタープライズ案件ではよくありそうな構成かと思います)。 Spring Framework 5によるアプリケーション開発が想定されている 既存の認証サーバに認証情報、属性情報が保管されている 既存の認証サーバはSAMLに対応しておりアプリケーションへの認証連携はSAMLを利用

    Spring Security SAMLとKeycloakの連携 - Qiita
  • Spring Security SAMLを使ってSAML認証にチャレンジしたメモ

    こんにちは。まーやです。つい最近までSAML認証の処理について実装にちょっぴり携わっていたので自分のメモがてら、ブログしておきたいと思います。細かい設定についてはさておきざっくりと流れだけね。私自身まだ知識があいまいなところもたくさんあるし、間違って覚えてることもたくさんあるかもなので、間違いあったらぜひご指摘ください。 SAML認証とは いきなりですが詳しい話は「SAML とは」でぐぐってほしい・・・。こんなページとかあります↓ https://boxil.jp/mag/a2950/ Security Assertion Markup Languageの略で、要するにシングルサインオン(以後SSO)の規格です。XML形式で認証情報のやり取りを行います。このSAMLを使う認証システムの代表格としてはMicrosoftアカウントを利用した認証(Active Directory/ Azure

    Spring Security SAMLを使ってSAML認証にチャレンジしたメモ
  • JDBC setFetchSize() ではまった話 | TECHSCORE BLOG | TECHSCORE BLOG

    JDBCのsetFetchSizeメソッドはご存知でしょうか? 通常、クエリの結果はResultSetにすべてロードされます。このため、大量のレコードを取得するようなクエリではOutOfMemoryErrorが発生してしまいます。 このような場合に有効なのがsetFetchSizeです。 たとえば、クエリ発行の前にsetFetchSize(1000)とすると、1000件ずつResultSetにとりこまれるようになり、OutOfMemoryErrorを回避することが可能です。 (もちろん、搭載メモリ量、1レコードあたりのサイズによります!) しかし、ここに罠がありました。。。 setFetchSizeを使用しているにもかかわらず、全件がResultSetにロードされてしまう場合があるのです。 JDBCドライバごとにsetFetchSizeの挙動がかなり違っているので、はまりどころです。 今回

    JDBC setFetchSize() ではまった話 | TECHSCORE BLOG | TECHSCORE BLOG
  • ECMAScriptの浮動小数点数の丸め仕様がスゴい - hnwの日記

    ECMAScriptの浮動小数点数の丸め関数である Number.prototype.toFixed() について調べてみたところ、浮動小数点数をわかっている人が作った硬派な仕様だと感じたので、解説してみます。 浮動小数点数の丸めの善し悪しについて 私はプログラミング言語の浮動小数点数の丸め処理に興味があり、過去に関連記事を30以上書いています。こうした活動から得られた知見として、良い丸め関数には次のような性質があると考えています。 仕様がシンプルで直感的であること 仕様が抜け漏れなく文書化されていること バグを作り込みにくい仕様であること どれも良い関数の一般論のような話ですが、丸め処理に限って言えば簡単な話ではありません。そもそも浮動小数点数の性質が人の直感に反するため利用者にとっても実装者にとっても罠が多く、結果として上の条件を満たせないことが多いのです(私が面白いと感じるポイント

    ECMAScriptの浮動小数点数の丸め仕様がスゴい - hnwの日記
  • Red Hat Enterprise Linux 8 での暗号強度設定を統合するcrypto-policies - 赤帽エンジニアブログ

    暗号化スイートおよびプロトコルの設定 暗号はだんだん弱くなる 適切な設定は何か? crypto-policiesによる設定 crypt-policiesによるデフォルト設定はどう実装されているの? openssh serverの場合 openssl の場合 crypto-policies の注意点 まとめ 関連リンク 暗号化スイートおよびプロトコルの設定 TLSによる暗号化、sshでの暗号化、ストレージの暗号化 など、 RHELの中には「暗号化」を扱う場面が多数あります。これらで利用される暗号化のアルゴリズムやプロトコルをセキュリティポリシーにあわせて適切に設定するには専門知識が必要になります。 一言で「暗号化」と言いましたが、たとえばTLSは通信相手の認証も含むため、鍵交換、データの暗号化、署名、ハッシュといったステップがあり、それぞれにアルゴリズムの選択肢があります。これらをまとめた「

    Red Hat Enterprise Linux 8 での暗号強度設定を統合するcrypto-policies - 赤帽エンジニアブログ