Security/Reviews/BigTent
From MozillaWiki
Please use "Edit with form" above to edit this page.
Item Reviewed
| Identity Project BigTent | |||||||||
| Target |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); |
||||||||
The given value "
| ID | Summary | Priority | Status |
|---|---|---|---|
| 742809 | Security review for new Identity Project BigTent | -- | RESOLVED |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);
" contains strip markers and therefore it cannot be parsed sufficiently.Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- BigTent makes it easier for Gmail, Hotmail, and Yahoo users to use Persona by simplifying account verification with Mozilla's fallback Identity Provider at login.persona.org.
- Instead of proving account ownership by clicking on a link in an email, BigTent asks users to directly authenticate with their provider via OpenID or OAuth. If successful, the fallback IdP continues on and provisions the user as per normal.
- The current solution involves standing up three new subdomains microsoft, google, and yahoo.login.persona.org and running a separate, domain-specific fallback IdP on each of these.
- At launch, these subdomains would share the private key for login.persona.org due to spec / data format constraints. Once the spec is updated, a separate keypair will be used for each domain, rather than sharing the main login.persona.org keypair.
What solutions/approaches were considered other than the proposed solution?
- cert chaining
- Turned out to be too complicated, didn't want to rush implementation
- launching with support for all 3 IdPs at once
- monolithic bigtent server (hosting gmail, yahoo, hotmail)
- roll our own OpenID RP library
- caching OpenID associations in memcache
- Reduce moving parts for v1, perf optimization only
Why was this solution chosen?
It was the best mix of what is technically feasable with acceptable risk. It introduces the fewest moving parts, and allows for incremental improvements in security as spec and data format changes happen.
Any security threats already considered in the design and why?
`
Threat Brainstorming
'
- Property "SecReview feature goal" (as page type) with input value "* BigTent makes it easier for Gmail, Hotmail, and Yahoo users to use Persona by simplifying account verification with Mozilla's fallback Identity Provider at login.persona.org.
- Instead of proving account ownership by clicking on a link in an email, BigTent asks users to directly authenticate with their provider via OpenID or OAuth. If successful, the fallback IdP continues on and provisions the user as per normal.
- The current solution involves standing up three new subdomains microsoft, google, and yahoo.login.persona.org and running a separate, domain-specific fallback IdP on each of these.
- At launch, these subdomains would share the private key for login.persona.org due to spec / data format constraints. Once the spec is updated, a separate keypair will be used for each domain, rather than sharing the main login.persona.org keypair." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview alt solutions" (as page type) with input value "*cert chaining
- Turned out to be too complicated, didn't want to rush implementation
- launching with support for all 3 IdPs at once
- monolithic bigtent server (hosting gmail, yahoo, hotmail)
- roll our own OpenID RP library
- caching OpenID associations in memcache
- Reduce moving parts for v1, perf optimization only" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Action Items
| Action Item Status | In Progress |
| Release Target | ` |
| Action Items | |
* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)
|
|
