ZOZOMETRYでのマルチテナントシステム設計のアプローチ 〜テナント間分離の変遷〜 - ZOZO TECH BLOG
目次 目次 はじめに 我々のチームについて ZOZOMETRYについて ZOZOMETRYでのBtoB開発で取り入れたこと プールモデルによるマルチテナント管理 Cognito+DBによるユーザー情報の管理 RLSによる行単位でのデータアクセス制御 RLSの利用を見送った理由 理由1 : コネクションプールの管理 理由2 : O/RマッパーでのRLSの利用 DDDにおけるテナントのアクセス制御 MySQLを採用した理由 AWS Auroraとの互換性 PostgreSQL独自の機能の不使用 チームの経験と学習コスト 計測プロダクトとの整合性 PostgreSQLを採用したいケース Gitの運用フロー まとめ 最後に はじめに こんにちは。計測プラットフォーム開発本部バックエンドブロックの髙橋です。 先日、ZOZOMETRYという新規サービスをローンチしました。 corp.zozo.com
インボイス管理サービス「Bill One」の認証を内製認証基盤に置き換えて認証基盤のコストを削減した話 - Sansan Tech Blog
Bill One Engineering Unit 共通認証基盤チームの樋口です。 Bill Oneでは昨年までAuth0を認証基盤として利用してきましたが、認証基盤を内製化することでコストを大幅に削減しました。 この認証基盤は、昨年12月に無事リリースされ、Bill Oneの認証を支えています。 今回は認証基盤の内製化に至った経緯と設計、移行プロセスについて紹介します。 Bill Oneについて 認証基盤に関する課題 解決方法の検討 IDaaS（Identity as a Service）について 設計とシステム構成について 認証基盤の設計 システム構成 アカウントの移行について メールアドレス・パスワードでのログインを利用しているユーザーの移行 SSO（Single Sign-On）の移行 振り返りと今後 ドメイン変更による問い合わせの増加 内製化によって体験の改善がスムーズに Bil
SaaS 認証: Amazon Cognito ユーザープールを使ったアイデンティティ管理 | Amazon Web Services
Amazon Web Services ブログ SaaS 認証: Amazon Cognito ユーザープールを使ったアイデンティティ管理 この記事は、SaaS authentication: Identity management with Amazon Cognito user pools を翻訳したものです。 Amazon Cognito は、数百万人のユーザーにスケールできるカスタマーアイデンティティおよびアクセス管理 (CIAM) サービスです。Cognito 開発者ガイドでは利用可能なマルチテナンシーモデルについて詳しく説明されていますが、どのモデルを使うべきかを判断するのは時に難しい場合があります。このブログ記事では、各モデルを使う際のガイダンスを提供し、お客様の意思決定に役立つよう、長所と短所を確認します。 Cognito の概要 Amazon Cognito は、Web
Amazon Cognito Identity Poolの外部プロバイダとしてFirebase Authenticationを使う - Sweet Escape
はじめに AWSには認証・認可のサービスとしてAmazon Cognitoというものが存在します。ややこしいのですが、認証のためのコンポーネントがAmazon Cognito user pools(以下、user pool)で認可のためのコンポーネントがAmazon Cognito identity pools (以下、identity pool)です。ちなみにidentity poolのほうはfederated identityと表記されている場合もあります。 そのうち、今回はidentity poolの話です。 identity poolは認証機構は持たず、大雑把にいうと任意のログインプロバイダで認証されたユーザに対してIAMロールが設定されたidを紐付けた上でテンポラリのAWSクレデンシャルを提供するといったサービスです。 この任意のログインプロバイダとしてFacebook、Twit
Amazon Cognito Hosted UIで、署名付きURLを使用し認証ユーザーごとにプレフィックス分けてS3バケットにアップロードする | DevelopersIO
Amazon Cognito Hosted UIで、署名付きURLを使用し認証ユーザーごとにプレフィックス分けてS3バケットにアップロードする はじめに 本記事では、Amazon Cognito Hosted UIを利用して、単一のS3バケットに対して署名付きURLを用いて、認証済みユーザーごとにプレフィックスを分けたアップロード方法を解説します。 この手法により、各ユーザーのファイルを効率的かつセキュアに管理することが可能になります。 以前、クライアントからEC2インスタンス経由でS3バケットにファイルをアップロードする方法を紹介しました。しかし、この方式では、大容量ファイルのアップロード時にEC2インスタンスに過度な負荷がかかるという課題がありました。 今回は、署名付きURLでクライアントから直接S3にファイルをアップロードする方式で試してみます。 S3の署名付きURLは、S3バケット
Amazon Cognito でSMSによるMFAを追加 | iret.media
はじめに メールアドレス ＋ パスワードでサインインしている既存Cognitoユーザーに対しMFA（多要素認証）を適用するフローを記載します。 前提 ・Cognito ユーザープール emailをエイリアス属性として設定 emailが検証済みのユーザーが既存の状態 ・Node v20.9.0 ・AWS SDK for JavaScript v3 Cognitoユーザープールの設定変更 CognitoでMFAを使用可能にする為にマネージメントコンソールで設定していきます。 ・MFAを有効化 サインインエクスペリエンス タブで多要素認証を編集します。MFAの強制でオプションを選択し、MFAの方法でSMSメッセージにチェックを入れます。 MFAの強制は必須にもできますが、ユーザーがSMSを受信することが義務付けられる形になります。ユーザビリティなども考慮し、今回はユーザーにMFAを適用する・しな
Cognitoの3種類トークンの違いは何だ？（ID、アクセス、リフレッシュ）
Amazon Cognitoを理解したいと思ってログイン画面を実装していると、ログイン成功時に以下の3種類のトークンを返されることに気づいた。 idToken accessToken refreshToken これら3つの使い分けを調べたので、記事に残そうと思う。 idTokenとは idTokenがいわゆる「トークン」であり、認証成功後に使いまわすアレである。 accessTokenとは accessTokenはいまいちピンとこないトークン。 AWSの公式ドキュメントを調べたところ、以下のように書いてあった。 アクセストークンの目的は、ユーザープール内のユーザーのコンテキストでの API 操作を承認することです。例えば、アクセストークンを使用して、ユーザーにユーザー属性を追加、変更、または削除するアクセス権を付与することができます。 アクセストークンの使用 この説明だけを見ていると「アク
Amazon Cognito、マシンツーマシン (M2M) 利用の階層化された料金を導入
Amazon Cognito では、継続的な成長をより適切にサポートし、機能を拡張するために、マシンツーマシン (M2M) 認証の料金が導入されています。Amazon Cognito のユーザーベースの料金 (月間アクティブユーザーまたは MAU) に変更はありません。現在 Amazon Cognito を M2M ユースケースに使用しているお客様のアカウントは、12 か月間料金が免除されます。M2M の料金は、M2M 認証用に構成されたアプリケーションクライアントの数と、それらにリクエストされたトークンの数に基づいています。詳細については、料金ページをご覧ください。 Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションに認証、認可、ID 管理機能をより簡単に追加するサービスです。Cognito の M2M 認証では、人間の ID がサポートされるだけでなく、
Amazon Cognito User Pool を用いたWebサービスにおけるユーザー管理・運用の事例 | Fintan
はじめに ほとんどのWebサービスにおいて、ユーザの認証機能は必要です。 ここでいう認証機能とは以下の機能群を指します。 サインアップ サインイン・サインアウト パスワード変更 パスワード初期化 昔のWebサービスは、これら認証機能を各サービスごとに独自に実装していました。 しかしパスワードのような秘匿情報を各サービスごとに保持することはセキュリティリスクを高めます。また認証機能を各サービスごと開発することは開発コストの増加につながります。さらにユーザーはサービスごとに使用しているアカウントを把握する必要がありますので利便性が低下します。 その結果、認証機能を外部システムに移譲したい、すでにある認証基盤を流用したい、などの要求がありました。 これらの要求に応えるように、OAuth 2.0やOpenID Connectなどのフェデレーション認証方式の確立やシングルサインオン等、認証機能に関わ
【セッション資料・動画】CognitoでWebアプリケーション（not SPA）に ログインさせたい時、何を作らなくてはならないのか？ #devio2023 | DevelopersIO
AWS事業本部 モダンアプリケーションコンサルティング部の北野です。 2023/07/07-08に日比谷本社でDevelopersIO 2023のオフラインイベントが開催されました！ DevelopersIO 2023 〜GETだけじゃもったいない、PUTしてPOSTする2日間〜 写真とツイートで振り返る『DevelopersIO 2023』 #devio2023 | DevelopersIO DevelopersIO 2023のオフラインイベントは順次各地方で開催されていきす！ そして実はひそかに、オンラインでもYoutubuによるビデオセッションが毎日公開されています！ 新着セッションのチェックに、ぜひYouTubeチャンネルの登録をお願いいたします。 クラスメソッド - YouTube そのビデオセッションの一つとして、「CognitoでWebアプリケーション（not SPA）に ロ
「Cognitoと他の認証は協調できる？」「環境を分けた場合の振り分けは？」 AWSソリューションアーキテクトが回答する認証・認可のQ＆A
Cognitoと他の認証を協調させるような作り方はできるか 清水崇之氏（以下、清水）：視聴者のみなさんから1つ質問がきています。「Cognitoと他の認証を協調させるような作り方はできますか」という質問について、いかがですか？ 福井厚氏（以下、福井）：はい。これもCognitoがフェデレーションの機能を持っています。例えばFacebookやGoogle ID、あとはSAM認証をサポートしているような他のIdPと連携させて認証することができるようになっています。そういう複合というか、組み合わせで認証させることも可能です。 清水：ありがとうございます。 中村航也氏（以下、中村）：Deletion Policyの話に関係しますが、Cognitoのユーザー情報、DynamoDBに退避させておいて、いざという時に復旧できるようなアプローチがあるとしたら、そのDynamoDBはCognitoのスタック
Cognito でユーザープールベースのマルチテナンシーを選択した際に、API Gateway で複数ユーザープールを許可する Lambda オーソライザーを作成してみた | DevelopersIO
Cognito でユーザープールベースのマルチテナンシーを選択した際に、API Gateway で複数ユーザープールを許可する Lambda オーソライザーを作成してみた いわさです。 Amazon Cognito では認証要件に応じていくつかのマルチテナント分離戦略を取ることが出来ます。 最も分離性が高いものはテナントごとにユーザープールを分離するパターンです。ユーザープールごとに共通設定となるもの（パスワードポリシーとか）をテナントごとに違うもの設定する場合などはこの戦略が取られることがあります。 そうした時に Cognito から取得されるトークンをどのように検証したら良いでしょうか。 Cognito オーソライザーを使う場合は、オーソライザーに対象のユーザープールを複数関連付けすることが出来ます。 これは以前次の記事で紹介させて頂きました。 しかし、Cognito ユーザープールで
Security practices in AWS multi-tenant SaaS environments | Amazon Web Services
AWS Security Blog Security practices in AWS multi-tenant SaaS environments Securing software-as-a-service (SaaS) applications is a top priority for all application architects and developers. Doing so in an environment shared by multiple tenants can be even more challenging. Identity frameworks and concepts can take time to understand, and forming tenant isolation in these environments requires dee
Amazon CognitoのUser Groupを利用した権限管理について本気出して考えてみた。 - Qiita
パーソルプロセス＆テクノロジー株式会社のAdvent Calendar 19日目の記事です。 Azureの記事が多い中ですが、堂々とAWSの記事を書いていこうと思います。 今回は何番煎じかわかりませんが、Amazon Cognitoを利用して役職や階級の概念を持つサービス内の権限管理を行います。 順を追って構築していくので、記事を読み終わった際に 権限管理が可能な環境が構築できる状態 になっていただければ幸いです。 あくまで『権限管理を行う』が目的です。個々の解説は適当なので、公式のドキュメントを合わせて読んでみてください。 不明点あれば質問いただければ返答します(正しい答えが返ってくるとは言っていない。) 最初に Cognitoは、認証認可、またユーザーの管理なども兼ね備えたフルマネージドなサービスです。 GoogleやFaceBookを利用したソーシャルログインも実現することもできます
新機能 – Amazon Cognito グループ、およびきめ細かなロールベースのアクセス制御 | Amazon Web Services
Amazon Web Services ブログ 新機能 – Amazon Cognito グループ、およびきめ細かなロールベースのアクセス制御 アプリケーションの構築における課題の 1 つは、ユーザー認証と管理に関する事柄です。この課題に直面しても、多くの開発者はアプリケーション用の別のユーザー ID と認証システムを構築したいとは考えていませんし、必要な場合を除いてユーザーにさらに別のアカウントを作成させたいとも思っていません。Amazon Cognito では、アプリケーションのデータとバックエンドシステムにアクセスするために、開発者がユーザーの ID、認証、および権限を簡単に管理できるようになっています。それに加えて、開発者がアプリケーションの異なるユーザーに異なる権限を割り当てるのを簡単にするサービス機能があればどんなによいでしょう。本日、Cognito ユーザープールがグループを
「Cognitoユーザープールグループの扱い方・IAMロールについてを解説します😎」低コストなモダナイズ開発の実践 | Ragate
実施のユースケースで言うと フロントエンドから AWS SDK でバシバシ AWS サービスを呼び出すような構築を行う場合は ID プールによる認可トークンが有効AppSync, API Gateway の呼び出しに認証制限をかけたい場合はユーザープールによる認証制限が有効 となります。 私たちの経験上ですが、ID プールトークンによる認可の方が少し開発が複雑になるような印象があります。（各種リソースごとに、誰に、どのようなアクションを許可するのか設計する必要があります） AppSync→Lambda、あるいは API Gateway→Lambda によるリソースアクセスで十分であれば、ID プールを利用せずLambda に対しての IAM 付与だけで構築をすることを推奨します。（認証系は最も複雑化しやすく開発者が疲弊しやすいのでシンプルにしておいた方が良いですね） ユーザープールグループ
API GatewayのオーソライザーにCognitoを使用してみた | DevelopersIO
事業本部Delivery部のアベシです。 こちらの記事では、API GatewayにCognitoのオーソライザーによる認証認可機能を導入する方法について紹介します。 構築にはCDKを使用しました。 Cognito ユーザープールをAPI Gatewayのオーソライザーとする場合の認証の仕組み ① クライアントがCognitoユーザープールにユーザー名とパスワードを渡して認証のリクエストする。 ② 認証されたらCognitoユーザープールがIDトークンをクライアントに返す。 ③ クライアントがAPIを叩く。その際にIDトークンをヘッダーに乗せてAPI Gatewayに渡す。 ④ API GatewayのオーソライザーのCognitoがトークンを検証する ⑤ 検証が成功したらAPIの利用を許可する(認可の部分) ⑥ 後続のLambda関数が実行される 実行環境 以下の環境で構築と動作確認して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to use Amazon Cognito user pools with custom UI and also OIDC
Fine-grained access control in API Gateway with Cognito access token and scopes
Fine-grained access control in API Gateway with Cognito groups & Lambda authorizer