thequux/ipasso
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Successfully fetch login status

Browse Source
This commit is contained in:
TQ Hirsch
2023-10-27 01:17:30 +02:00
parent d5af575e74
commit 6498a8bd06
8 changed files with 181 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/auth-flow.md
View File

@@ -1,6 +1,7 @@
# Authorization flow
Current authorization state is passwd around via a signed cookie containing authorization details in JSON.
Current authorization state is passed around via an opaque session ID in a cookie.
This cookie is stored in duplicate: once on the SSO domain and once on the protected domain (for use by RPX's)
Most pages do not have any form of authorization, and simply depend on the cookie.
However, in order to log in, more complex flow is necessary.
@@ -26,7 +27,7 @@ The user may also submit the form with blank username/password, in which case au
These steps are performed in sequence, each returning the same data as `/login/status`.
The process completes when the state is `VALID` or `EXPLICIT_LOGOUT`.
1. Fetch `/login/spnego` via XHR GET.
1. Fetch `/login/krb5` via XHR GET.
2. Fetch `/login/x509` via XHR GET.
Upon successful login, a redirect is performed to the page in the hidden field.
@@ -36,23 +37,8 @@ The process completes when the state is `VALID` or `EXPLICIT_LOGOUT`.
In addition to the `/login` endpoint, there exist several other useful endpoints:
* `/logout`: Set cookie to indicate logged-out state
* `/status`: Fetch a representation of user's info.
* `/login/status`: Fetch a representation of user's info.
If `Accept` requests `application/json`, this is JSON.
Otherwise, this is an HTML page
* `/sigkey`: Fetch the current signing key. This is an Ed25519 key.
* `/refresh`: Refresh the user data cookie given the refresh token.
# Two cookies
In the above description, the login token was described as a single cookie.
It is, in fact, two cookies:
* A short-lived (~seconds) user data cookie
* A longer-lived (~8 hour) refresh token, tied to an auth server
If the user data cookie expires, the refresh token can be fed to `/refresh` to update the user data cookie.
The purpose of the user data cookie is solely to reduce the load on the SSO server; the resources fetched by a page will
generally be fetched within a few seconds of the initial request.
It is the reverse proxy's responsibility to refresh the user data cookie and translate it into headers or FCGI environment variables for the backend server.
This task can be assisted by ipasso-rpxagentd (to be specified).
An OAuth interface is also available on **TODO**