Launch HN: SSOReady (YC W24) - SAML SSOをシンプルかつオープンソースで実現する技術
(github.com/ssoready)- SSOReadyは、製品にSAMLベースのEnterprise SSOとSCIMベースのEnterprise Directory Syncを追加するためのオープンソースツールで、顧客が自分でオンボーディングできるホスト型設定UIも提供する
- どのアプリケーションスタックでも使えるように、HTTP APIをベースに据え、TypeScript・Python・Go・Java・C#・Ruby・PHP向けSDKを薄いラッパーとして提供する
- SAMLログインはリダイレクトURLの生成とアクセスコードの交換で構成され、SCIMは組織の外部IDでユーザー一覧を取得する方式で、実装フローを単純化する
- SSOReadyは認証ミドルウェア層として動作し、ユーザーを保持せず、既存のユーザーデータベースの変更も要求せず、クラウドホスティングまたはセルフホスティングを選択できる
- Enterpriseプランはカスタムドメイン・ブランディング、Management API、SLAサポートを提供し、MITライセンスは価格引き上げへの牽制手段としてフォークの可能性を開いている
SSOReadyが提供する機能
- SSOReadyは、製品にSAMLとSCIMサポートを追加するためのオープンソースプロジェクト
- 主な構成は3つ
- SSOReady SAML: 製品にSAML、つまりEnterprise SSOを追加するために必要な機能
- SSOReady SCIM: 製品にSCIM、つまりEnterprise Directory Syncを追加するために必要な機能
- Self-serve Setup UI: 顧客がSAMLまたはSCIM設定を自分でオンボーディングするためのホスト型UI
- クイックスタート文書はSAML QuickstartとSCIM Quickstartに分かれている
- READMEでは、ほとんどのユーザーがSAMLとSCIMを半日ほどで実装でき、必要なコードは2行だけだと説明している
スタック非依存性とデプロイ選択肢
- SSOReadyは特定のアプリケーションスタックに縛られず、言語別SDKは直感的なHTTP APIの上に載る薄いラッパーとして提供される
- 提供されるSDKは以下の通り
- SSOReadyは認証ミドルウェア層として動作し、ユーザーを保持せず、既存のユーザーデータベースの変更も要求しない
- デプロイ方式は、クラウドホスティングインスタンスの利用またはセルフホスティングから選択できる
- Enterpriseプランはクラウドとセルフホスティングの両方に対してSLAサポートを提供する
SAML実装フロー
- SAML、つまりEnterprise SSOは2段階で構成される
- ユーザーを会社のIdentity Providerへリダイレクトする開始段階
- ユーザーが誰かを確認したうえでログインさせる処理段階
- ログイン開始にはGet SAML Redirect URLエンドポイントを使う
organizationExternalIdには、組織、ワークスペース、チームなど、製品で使う任意のIDを入れられる- そのIDはSSOReady内で設定され、SSOReadyがその組織のSAML・SCIM設定の追跡を処理する
- ログイン処理にはRedeem SAML Access Codeエンドポイントを使う
/ssoready-callbackのハンドラでsamlAccessCodeを交換し、emailとorganizationExternalIdを受け取る- 製品側は、返されたメールアドレスでその組織内のログインを行えばよい
/ssoready-callbackエンドポイントURLはSSOReadyで設定する
SCIM実装フロー
- SCIM、つまりEnterprise Directory Syncは、顧客の従業員一覧をオフラインで取得する方式として紹介されている
- 顧客の従業員を取得する際にはList SCIM Usersエンドポイントを使う
- リクエストには
organizationExternalIdを使い、レスポンスにはscimUsersとnextPageTokenが含まれる - 各SCIMユーザーには
email、deleted、attributesのような値が含まれ、製品側はこれをもとにユーザーを作成したり処理したりできる
Enterprise機能とプロジェクト哲学
- Enterpriseプランでは拡張機能を利用できる
- Custom Domains & Branding: ユーザーが管理するドメイン上でSSOReadyを実行し、SAML・SCIM体験をブランドに合わせて調整
- Management API: SAMLとSCIM関連作業をプログラムから大規模に自動化
- Enterprise Support: セルフホスティング環境を含むSLAサポート
- プロジェクトの前提には、ビジネス向けソフトウェアを販売するすべての製品がEnterprise SSOをサポートすべきであり、それが顧客に大きなセキュリティ上の利点をもたらすという考えがある
- 既存のオープンソースSAMLライブラリには文書化不足で分かりにくいという問題意識があり、SSOReadyは明確でデフォルトで安全な実装体験を目指している
- セキュリティソフトウェアの価格を恣意的に大幅引き上げするのは受け入れられないという立場から、SSOReadyはMITライセンスで提供される
- セキュリティ問題は
security@ssoready.comへ報告するよう案内している
1件のコメント
Hacker Newsの意見
幸運を祈るしかない。以前自分で IdP を作って、シングルサインオン、シングルログアウト、ユーザープロビジョニングなどいろいろ実装したが、実際に動くと本当に魔法みたいで笑ってしまう
さまざまなサービスプロバイダや別のIdPとも連携し、機能も良かったが、一つだけ言えるのは決して 苦痛のない作業 ではなかったということ
世界最高のIdPを作っても相手側はブラックボックスなので、ペイロードがどこかへ送られたあと、なぜ処理されたのか分からないことが多い
しかも連携先がSAMLのフロー、ペイロード、自分たちのスタックにあるSAML機能すら理解していないことも多く、相手に教えながら同時にそのシステムも学ばなければならない
署名やフォーマットの心配より、ブラックボックス診断や終わりのない証明書管理のブラックホールのような作業が大半だった
特にIPSecは傷が深く、VPNトンネルが生きているか確かめるためのTCP接続ひとつ開けない「ネットワークエンジニア」と一緒に仕事をしながら、「向こうと本当に連携できるのか？」と気をもんだ
結局はできるだけ早く相手のシステムを理解して、設定が正しいか判断し、避けられない連携の問題を見つけるしかなかった。ほぼ毎回どこかの ファイアウォール が原因だった
エンタープライズ機器が標準用語を自分たち独自の新しい言葉に置き換えて呼ぶのも問題で、学習の大半は相手の「アプライアンス」がその用語や別の用語を何と呼ぶかという頭の中のロゼッタストーンを作ることになる
きちんと受け入れてくれるメールサーバーもあれば、奇妙なポリシーや厳しいブロックリストを運用し、ドメインや送信者ごとのレピュテーションを別々に管理しているところもある
おそらく売上につなげたい意図なのだろうし、それ自体は構わないが、次は表現を少し整えた方がよさそうだ
良さそうに見える。SAMLを実装したことがある立場からすると本当に苦痛だったが、このツールはずっと 楽そうに見える
ただ、価格が少し気になる。このツールの上に自分たちのシステムを積み上げることになるので、後で会社が潰れたり価格政策が変わって不利になったりすると、SSOを書き直す大きなエンジニアリング作業が突然発生する
ホスティング製品を無料で提供するなら、結局は潰れるか価格を変える可能性がかなり高そうに見える
今後6〜12か月以内に現在のプロジェクトへSSOを組み込まなければならない立場としては、「今は無料」と「よく分からないのでメールしてくれ」以外に、持続可能に見える 有料プラン があるとチームを説得しやすい
選択肢の一つが「創業者に電話すること」だという点も忘れてはいけない
そういう現実を踏まえると、会社でSAMLが必要な人なら、単一のSaaSアプリでこの機能ひとつに払う費用の半分程度は払ってもよいのかもしれない
[1]: https://sso.tax/
オープンソースで堅実なビジネスを作れないという意味ではない。Red Hatはそれを成し遂げたが、そのモデルで進むべきであって、シード段階のVC資金モデルではないと思う
商業的な論理として説得できないかもしれないが、潤沢な無料提供が長期的には利益になるという 計算された賭け をしている
この製品が開発者の信頼を築き、将来は効率的な配布チャネルになると考えている。初期に収益化しない商用オープンソース戦略はかなり一般的だ
幸い、人気のある商用オープンソース製品を持つ会社を喜んで支援するベンチャー投資家も一部にはいる
まだ初期段階の会社であり、既存製品をより深く育て、時間をかけて新製品も提供していく予定だ。新機能と新製品には課金するつもりで、意味のある売上やキャッシュフローまで数年かかっても問題ないと考えている
オープンソースとして公開し、使いやすいサービスを出したのは称賛に値する
副次的には、これが人気と品質のある実装になれば、ほかのサービスプロバイダにとってもこのソフトウェアの利用者と連携しやすくなるかもしれない
Fortune 500向けのSSO連携を何度もゼロから実装したが、それぞれ独自に作り込まれていて、「SAML」と言っても必ずしも相互運用できるわけではなかった。こういうソフトウェアならデフォルトで動くかもしれない
無料のホスティングSSOを提供するとき、顧客がそこ経由で侵害されないよう、どれだけうまく セキュリティ を維持できるのか気になる
また、全顧客にとって単一障害点にもなるはずで、無料層にも稼働時間保証があるのか気になる。ホスティングは欲しいがSLAが必要なスタートアップ向けに、手の届く価格で提供できるのかも気になる
SOC2についてはOneleetと協力しており、SOC2のかなりの部分が出来レースだというのは皆分かっているが、かなり徹底した ペネトレーションテスト も進めている。希望があれば結果をメールで送れる
現実的に、私たちはこうしたことをきちんとやらなければならない会社だ
無料層の稼働時間保証はケースごとに合意する予定で、必要な内容によって変わる。保証はかなり真剣に受け止めているので、約束には慎重だ
私たちはサービス事業をやりたいわけではなく、「プレミアムサポート」でお金を稼ぎたいわけでもない。ただしSLAが必要なら所定の料金はある
「クラウドプロバイダがこのソフトウェアを使う顧客を奪うのか」という質問は、もう少し言い換えてもらえると助かる
最近のSAMLの最大の障害は、SaaS製品との連携だと思う。サポートチームとメールを何度もやり取りしなければならない場面をよく経験したし、ベンダーによってはSSO設定だけを扱った204ページのPDFをそのまま送ってきたこともあった
属性マッピングはいまだにひどい状態で、ユーザー体験がまだここまで悪いのには驚かされる
ちょうどこの問題のための機能をリリースした。204ページのPDFを作る代わりに、SSOReadyで設定URLを生成して顧客に渡せば、顧客はそのURLにアクセスして、自社製品とのSAML接続をセルフサービスUIで設定できる
https://ssoready.com/docs/idp-configuration/enabling-self-se...
最も大きな難しさの一つは、ユーザーが実際にSSOシステムを所有している別部署を巻き込まなければならない点で、その部署には急いで動かすインセンティブがあまりないため、チケットが長引きがちだった
顧客から特定の情報をもらう必要があるせいで、こちらの印象が悪く見えることもあった
すばらしい。「複雑な要求がある大企業向けの追加機能を作って将来的に収益化する計画」という部分が気になる
YC応募の過程では、この程度でも合格に十分だったのか、投資のためにビジネスモデルがどれほど重視されたのか気になる
気前のいい無料提供に抵抗がない理由の一つは、SaaS企業がSAMLログインをサポートできるよう支援すること自体が、そこまで大きな市場ではないという基本的な事実があるからだ。どうせ別の製品で収益を上げなければならない
「追加機能による収益化」は現在提供しているSAML製品についての話だが、ほかの製品もリリースする予定だ
長期的な目標は、Auth0に似ているが、オープンソースで開発者フレンドリーな会社を作ることだ
WorkOSより費用対効果の高い代替を探していたので、タイムリーだ。エンタープライズ向けのデータ検証ポータルを作っていて、一度試してみるつもりだ
Entra IDと連携する際にすぐ参照できるガイドがあるのか気になる。本当にAPIエンドポイントさえあればいいのか?
その通り。書くコードはすべてのIdPをカバーし、IdPごとの差異は各顧客の設定値で処理される
例えば、少し前にEntra専用のドキュメントを整備した: https://ssoready.com/docs/idp-configuration/guides-for-commo...
必要な内容がこれで満たせるか気になる
従量課金ユーザー向けには自動ボリュームディスカウントがあり、年間プランやカスタム契約ではさらに低価格も可能だ。初期段階の企業には無料クレジットも提供している
話してみたければ mg@workos.com まで連絡してほしい
現在、多くのスタートアップを含む数百社がWorkOSを使っている: https://workos.com/startups
前の会社でSSO連携を実装したが、SAMLがあまりにつらそうだったのでOIDC2だけにした
今もそうかは分からないが、しばらくの間Oktaは、SCIMを使うOkta連携でSSO用のOIDCを許可しておらず、SSOにはSAMLを使う必要があった
私たちは、SSO用とSCIM用でOkta連携を2つ別々に作ることで回避した。顧客のIT部門に説明するのはいつも面倒だったが、誰も問題にしなかったのでSAMLを実装する必要はなかった
良さそう。SCIMを追加する予定があるのか気になる
SAMLも良いが、経験上、大企業顧客がSSOを望む主な理由の一つは、従業員が退職したときにすべてのアプリで一括してアクセス権を外せる自動プロビジョニング解除だ。それにはSCIMが必要になる
SAMLに加えてSCIMまで、あるいはSCIMの小さなサブセットだけでもあれば、ほとんど迷わず選べそうだ。ほかのサービスはクローズドで法外に高く、自前実装は大きな苦痛だ
正直、IETFはSCIM自体についてはかなりうまく設計した。SAMLのように奇妙ではない。経験上、SCIM連携で最も難しい部分はIdPごとの設定を合わせることだ
SAMLと同じく、Okta、Microsoft、OneLoginがまったく同じものを完全に異なる用語で呼んでいる状況がある
期待している機能の一つは、顧客に渡す設定リンク生成ボタンだ。そのリンクを通じて、顧客がSAML+SCIM構成をセルフサービスで設定できるようにする
これは今すでにSAMLでは動作していて、各製品の妙な用語や独特なUIを説明するIdP別ドキュメントを個別に書かなくて済むのが良い
ローンチおめでとう。BoxyHQのSAML Jackson[1]と比べるとどうか?
[1]: https://github.com/boxyhq/jackson
私たちが自分たちのアプローチを好む理由は、基本的に2つある
第一に、BoxyHQはSAML-over-OAuthを前提としている。私たちも特にNextAuth互換性のためにこれをサポートしているが、常に有益だとは限らないと考えている
第二に、私たちのサービスのほうが使いやすいと思っている。ユーザーや顧客から最もよく聞く不満は複雑さなので、SAMLを明確でシンプルにするためにかなり努力してきた。最終的にその基準を満たしているかどうかは、ユーザーが判断することだ
Microsoft の B2C IdP 向けの最初の カスタム ポリシー を書いているところだが、苦痛な作業だ
認証と SSO の苦痛が減れば、実際に世界はより良くなるはずだ。アプリはより安全になり、人々は使うときの苛立ちが減り、私のような人間のストレスも減る
http://id.atlassian.com