CodeForPhilly / CodeForPhilly/codeforphilly-ng

saml: capture + diff legacy assertion for NameID continuity

オープン
#52 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
TypeScript
スター
1
フォーク
1
平均マージ
5日 3時間
マージ済み PR(30日)
9

説明

Capture a real assertion emitted by the legacy laddr emergence-slack code in production, and diff against the assertion the new IdP would emit for the same user.

Surfaced by the saml-idp plan's closeout (PR #49). Per [plans/saml-idp.md#risks--unknowns](plans/saml-idp.md), this is "the single highest-stakes thing in this plan" — the v1 IdP claims to preserve NameID stability for every existing Slack account through cutover. The way to actually prove that is:

1. Browser-side: capture a laddr-emitted SAMLResponse during a real /Slack/Login flow (browser devtools → Network tab → look at the POST to slack.com/sso/saml — the SAMLResponse is in the form body, base64-encoded)
2. Decode the XML
3. For the same Person, build the v1 IdP's response (via /api/saml/slack/launch) and decode
4. Diff field-by-field. Acceptable diffs: timestamps, IDs. Unacceptable: NameID.Value, NameID.Format, NameQualifier, SPNameQualifier, attribute names.

If the diff turns up a NameID delta for any user, we need to fix migration before cutover.

Out of band of the v1 PR; needs:
- Access to a logged-in legacy laddr account
- Coordination with that user

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

plans/saml-idp.md の「Risks & Unknowns」セクションを読み、ブラウザーの DevTools を使って、実際の /Slack/Login フローから SAMLResponse を取得します。それをデコードし、同じ Person に対する /api/saml/slack/launch のデコード済みレスポンスとフィールドごとに比較します。完了の条件は、タイムスタンプと ID だけが異なり、NameID フィールド、修飾子、属性名が同一であること、または修正すべき移行上の問題が特定されることです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
typescript
領域
api, authentication
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
明確に書かれている
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。