CloudServices/At a glance: Difference between revisions
Jump to navigation
Jump to search
m (Just project name.) |
|||
| Line 1: | Line 1: | ||
= | = TOKEN SERVER = | ||
== What does it do? ( | == What does it do? == | ||
This solution uses a token-based authentication system. When a user wants to connect to one of our service , they get an access token by asking a central server. | |||
== | ==System Requirements== | ||
* | *The system needs to support multiple services (not necessarily centrally) | ||
*The system needs to be able to assign users to different machines as a service scales out, or somehow distribute them | |||
*The system should consistently send a user back to the same server once they’ve been assigned | |||
*The system needs to give operations some level of control over how users are allocated | |||
*The system should provide some recourse if a particular node dies | |||
*The system that can handle exhaustion attacks. For example, I could set up an primary | |||
*The system should auto-approve any username, then loop through users until all nodes were full. | |||
* The system needs to support future developments like bucketed assignment | |||
*system that scales infinitely. | |||
==Assumptions== | |||
*A Login Server detains the secret for all the Service Nodes for a given Service. | |||
*Any given webhead in a cluster can receive calls to all service nodes in the cluster. | |||
*The Login Server will support only BrowserID at first, but could support any authentication protocol in the future, as long as it can be done with a single call | |||
*All servers are time-synced | |||
*The expires value for a token is a fixed value per application. For example it could be 30 minutes for Sync and 2 hours for bipostal. | |||
*The Login Server keeps a white list of domains for BID verifications | |||
== Resources == | == Resources == | ||
* Server https://github.com/mozilla-services/tokenserver | |||
=== Specs and Docs: === | === Specs and Docs: === | ||
*[https://docs.services.mozilla.com/token/apis.html Token Server API v1.0] | |||
*[https://docs.services.mozilla.com/token/user-flow.html User Flow] | |||
*[https://docs.services.mozilla.com/token/history.html History] | |||
Revision as of 10:42, 15 December 2015
TOKEN SERVER
What does it do?
This solution uses a token-based authentication system. When a user wants to connect to one of our service , they get an access token by asking a central server.
System Requirements
- The system needs to support multiple services (not necessarily centrally)
- The system needs to be able to assign users to different machines as a service scales out, or somehow distribute them
- The system should consistently send a user back to the same server once they’ve been assigned
- The system needs to give operations some level of control over how users are allocated
- The system should provide some recourse if a particular node dies
- The system that can handle exhaustion attacks. For example, I could set up an primary
- The system should auto-approve any username, then loop through users until all nodes were full.
- The system needs to support future developments like bucketed assignment
- system that scales infinitely.
Assumptions
- A Login Server detains the secret for all the Service Nodes for a given Service.
- Any given webhead in a cluster can receive calls to all service nodes in the cluster.
- The Login Server will support only BrowserID at first, but could support any authentication protocol in the future, as long as it can be done with a single call
- All servers are time-synced
- The expires value for a token is a fixed value per application. For example it could be 30 minutes for Sync and 2 hours for bipostal.
- The Login Server keeps a white list of domains for BID verifications