You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+8-1Lines changed: 8 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ This service combines some basic functionality of [Authelia](https://www.autheli
9
9
The process for login is:
10
10
11
11
1. A reverse proxy, such as HAProxy, gets a HTTP request from a user
12
-
2. This proxy performs a process to verify the authentiction of the user via a HTTP sub-requet to `/api/authz/forward-auth`
12
+
2. This proxy verifies the authentication of the user via a HTTP sub-requet to `/api/authz/forward-auth`
13
13
3. If the user is already authenticated the `/api/authz/forward-auth` returns a `HTTP 200 OK` response along with HTTP headers the proxy may use to identify the user
14
14
4. If no valid session is available, a redirect is returned to the proxy which should be returned to the user, which will start the SAML login process
--sp-claim-mapping stringToString Mapping of claims to headers (default [remote-user=urn:oasis:names:tc:SAML:attribute:subject-id,remote-email=mail,remote-name=displayName,remote-groups=role])
49
+
--sp-cookie Cookie Name set by Service Provider (default "token")
49
50
--sp-key string Service Provider Key
50
51
--sp-url string Service Provider URL (default "http://localhost:9091")
51
52
```
@@ -60,10 +61,16 @@ For this reason, the token only contains minimal data with the rest contained se
60
61
61
62
By default this store is a basic in-memory store, which means it cannot be shared among multiple instances of this service and also will be lost on restart. The loss of this data on restart is not particularly problematic as the only result will be that the SP will not be able to validate the user is signed in and force the login flow to the IdP.
62
63
64
+
If using muliple nodes however, using the in-memory store will cause unexpected re-authentiations if requests are handled by different instances.
65
+
63
66
When using multiple instances, it is possible to use a PostgreSQL database to store this content.
64
67
65
68
### Using the same database for multiple deployments
66
69
67
70
All instances of the same Service Provider should share the same configuration options, including the database store, however if seperate service providers are configured using the same database there is the chance incorrect claims may be returned.
68
71
69
72
To allow sharing of the same database between seperate Service Providers, the `db-prefix` option will ensure this data is stored in seperate tables.
73
+
74
+
### Cookie Name
75
+
76
+
The login "token" is stored as a JWT in a cookie named "token" by default. It is important to ensure that seperate SP's use distinct cookie names to ensure JWT's are correctly validated and not overwritten.
0 commit comments