認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
【レポート】Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~ | DevelopersIO
本記事は、2019年8月21日に行われたmerpay社の主催するイベント、「Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~」の参加レポートです。 Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~ レポート セッションの概要 メルペイ社の認証基盤チームの担当している 外部向けに提供しているOIDCなどの認可の仕組み 内部のマイクロサービス間通信の認証の仕組み のうち、後者についてのお話を聞いてきました。セッションのスライドはこちらで公開されています。 チームがやっていること 認証基盤チームではユーザーアカウント管理とかログインはやってない 従業員の管理とかはやってない セキュリティについてはセキュリティチームと相談しながらやっている それ以外の認証認可を認証基盤チームがやっている 現状のアーキテクチャ
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
Web APIにおける認可の現状確認 2019 春 - 解せぬ日記
最近Web APIの認可について思いを馳せる機会があったのだけど、どの方法で認可を実装するのがスタンダードなのか、そもそもそんなものは最初からないのか、よく分からなくなったので自分なりの考えをまとめることにした。 ファーストパーティのアプリが使うWeb API（プライベートなWeb API）の場合はセッションを使うケースもあるだろうが、セッションを使うケースでは悩むことも少なかったので、ここではアクセストークンを用いた認可にフォーカスして考えてみたい。ケースとしてはユーザー毎にアクセストークンが発行され、Browser-BasedアプリやNativeアプリからWeb APIが叩かれることを想定している。 追記 2019/03/04 認証や認可周りについてよく拝見させてもらっている方にブログで言及していただきました。合わせて読むことをお勧めします。 ritou.hatenablog.com
認可と認証技術についてのスライドを書きました - ngzmのブログ
認可と認証技術 OAuth 1.0、OAuth 2.0 および OpenID Connect に関するスライドをアップしました。 アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect - from Naoki Nagazumi www.slideshare.net 開発している Web アプリで、OAuth 1.0 や OAuth 2.0 および OpenID Connect の認可と認証技術を組み込んだ時に、あれこれ調査して知り得た技術をまとめたものです。 130ページくらいの力作です！ぜひご覧ください。 デモ これのデモはこちらにあります AuthsDemo デモのソースコードはこちらです。 GitHub - ngzm/auths-demo: This is a demo program with using OAuth
Account authentication and password management best practices | Google Cloud Blog
13 best practices for user account, authentication, and password management Editor's note: This post includes updated best practices including the latest from Google's Best Practices for Password Management whitepapers for both users and system designers. Account management, authentication and password management can be tricky. Often, account management is a dark corner that isn't a top priority f
Row Level Securityの変更 - Qiita
はじめに にゃーん この記事は、PostgreSQL 10全部ぬこ Advent Calendar 2017 の23日目のエントリです。 Row Level Security(RLS)とは Row Level Security(RLS)というのは、名前のとおり行レベルでの権限制御を行うもの。 RLSを使うことで、上の図にあるように、ユーザ別にアクセス可能な行を指定することが可能になった。 この機能はPostgreSQL 9.5から使えるようになった。 通常のデータベースオブジェクトに対する権限制御は、GRANT/REVOKEコマンドを使うが、RLSはCREATE/ALTER/DROP POLICYコマンドを使う。 「別にRLSを使わなくても、ユーザ別にVIEWを定義すれば同じようなことはできるんじゃあないか？」という話もあるが、RLSではポリシー定義という考え方で、操作別/ロール別に細かく
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
Rubotyの認可認証機能を作った話 【SpeeeKaigiレポート#2】 - Speee DEVELOPER BLOG
こんにちは！ ヌリカエ / 開発基盤エンジニアの @selmertsx です。 chatopsを導入しているチームで、chatops使える人と見れるだけの人を分けたいってことありますよね。 今回はそのための機能をご用意しました。 その機能を SpeeeKaigiで話したところ、ぎりぎり３位入賞をもらえましたので、 今回はそのお話をしたいと思います。 SpeeeKaigi自体については、こちらを御覧ください。 tech.speee.jp トークテーマ Rubotyで認可認証 & Deploy機能を作った話 キーワード chatops ruboty 認可認証 deploy 発表スライド 作成した gemはこちら。 https://github.com/selmertsx/ruboty-capistrano https://github.com/selmertsx/ruboty-authoriz
RFC7662として発行されたOAuth Token Introspectionとは - r-weblife
こんばんは、ritouです。 今回紹介する仕様は、RFC7662 OAuth Token Introspectionです。 RFC 7662 - OAuth 2.0 Token Introspection ざっくり言うと Token Introspectionとかいうと、Token置換攻撃対策としてのClient-AuthZ Server間のAccess Token検証を想像する方もいるかもしれませんが、この仕様はそれとはあまり関係ありません。 この仕様はOAuthのProtected Resourceのための仕様です。 RFC 6749 - The OAuth 2.0 Authorization FrameworkのRoleのところには、resource serverがprotected resourceをホストしていて、 access tokenを用いたリクエストを受ける、とあります。
BigQuery IAM roles and permissions | Google Cloud
Send feedback Stay organized with collections Save and categorize content based on your preferences. BigQuery IAM roles and permissions This document provides information on Identity and Access Management (IAM) roles and permissions for BigQuery. IAM lets you grant granular access to specific BigQuery resources and helps prevent access to other resources. IAM lets you apply the security principle
IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO
さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ
Basic認証とOAuth - Qiita
Basic認証とOAuthとその辺の情報について整理しておく。OAuthや認証・認可について説明しようとすると、1文字記述するたびに誤りが含まれてしまう可能性があるので、本当に緊張感を持って記述しなければならない。それでもなお、この文章にはたくさんの誤りが含まれている。 UsernameとPasswordを受け取って認証する形式の認証方法。UsernameにはEmailを使うこともある (要は全ユーザの中で一意なことが保証されていてかつ他の人がその値を知っていても特に問題がないという情報であればOK)。Passwordは本人しか知り得ない情報。 OAuthという仕様に則って提供される認可方法。古いOAuth 1.0と、OAuth 1.0の複雑なところなどを改善したOAuth 2.0がある。一般的にはOAuth 2.0を使うことが多いが、例えば幾つかのサービスの提供している認可方法はOAut
AWS SDK for RubyでS3へのアクセス認証付きURLを生成する - プログラマでありたい
Amazon S3のアクセスコントロール(Access Control)には、次の5タイプがあります。 IAMのポリシーを使った制御(Using IAM Policies) バケットポリシーを使った制御(Using Bucket Policies) ACLを使った制御(Using ACLs) ACLとバケットポリシーを併用した制御(Using ACLs and Bucket Policies Together) 認証付きクエリーを使った制御(Using Query String Authentication) 用途に応じて上記の方法を使い分けるのですが、この中で面白いのが認証付きクエリーを使った制御です。要は、一時的に使用権を与えたURLを発行するという方法です。有効期限等を設定出来るので、期間限定のURL等を発行出来ます。キャンペーンで使用するといった方法や、アプリケーションから安全にア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kyuden/banken: Simple and lightweight authorization library for Rails
GitHub - CanCanCommunity/cancancan: The authorization Gem for Ruby on Rails.
はてなブックマークにおけるアクセス制御 - 半環構造に基づくモデル化
GitHub - songkick/oauth2-provider: Simple OAuth 2.0 provider toolkit
SDKを利用しない場合 - Yahoo!デベロッパーネットワーク
