... | ... | @@ -27,11 +27,12 @@ In our federated examples, the client from **example.org** will connect to **exa |
|
|
## Client data
|
|
|
|
|
|
each client must have:
|
|
|
* authentication data (token or user/pass)
|
|
|
* client id: 128bit, randomly generated by the client only once on its very first setup, then saved somewhere.
|
|
|
* tokens: random 128bit, used for authentication and authorization.
|
|
|
* authorization type: one per token: 1 byte to limit the users' privileges.
|
|
|
|
|
|
The tokens (one per device/service) will be given by the **AS** to the client manager after the first login.
|
|
|
|
|
|
## The Authorization
|
|
|
|
|
|
Fenrir supports authentication, but how is authorization different?
|
... | ... | @@ -42,7 +43,8 @@ Usually when we login somewhere we have complete access to the action that user |
|
|
|
|
|
In OAuth and other protocols the concept of authorization is introduced to limit what the user can do with that authenticated connection.
|
|
|
|
|
|
If we apply the authorization to a scenario where the client can connect multiple times with multiple applications or devices, we can easily imagine that we might want one application to have some rights (example: read-only), while an other might have full access. Think about giving your bank account details to your phone.
|
|
|
If we apply the authorization to a scenario where the client can connect multiple times with multiple applications or devices, we can easily imagine that we might want one application to have some rights (example: read-only), while an other might have full access.
|
|
|
Think about your bank account: you might want full access on your computer, but your phone might be better off with just read-only data, as it is easily lost.
|
|
|
|
|
|
# Introducing the Authorization Lattice
|
|
|
|
... | ... | @@ -55,11 +57,17 @@ Take this authorization lattice for example: |
|
|
|
|
|
Recall that in a client device we find a Client Manager and the applications. The Client Manager manages the tokens, the applications only receive connection data.
|
|
|
|
|
|
When a client is issued a token, each token is tied to an authorization. Let's consider a token which is tied to the "Modify" authorization in the lattice above.
|
|
|
When a client is issued a token, each token is tied to an authorization.
|
|
|
Let's consider a token which is tied to the "Modify" authorization in the lattice above.
|
|
|
|
|
|
Since a token is bounded to the "modify" authorization, during authentication the client can say he has this token for the "modify" authorization, but he wants a limited authorization a lower level of the lattice ("read" or "bottom" in the example).
|
|
|
|
|
|
After checking that the token is valid and the client isn't asking for more authorization that his token can grant, the **AS** proceeds with authorizing the connection.
|
|
|
|
|
|
Since a token is bounded to the "modify" authorization, during authentication the client says he has this token for the "modify" authorization, but he wants a limited authorization a lower level of the lattice ("read" or "bottom" in the example).
|
|
|
This means that the user will be able to limit the maximum privilege usable by a device, and then the Client Manager can further limit the privilege before authorizing the application.
|
|
|
By this system we can force an application down to a certain privilege. Without this system the most we could do would be to hope that the application automatically limits itself and does not do more than we asked.
|
|
|
|
|
|
After checking that the token is valid and the client isn't asking for more authorization that his token can grant, the Auth.Serv. simply proceeds with authentication.
|
|
|
And the management of the privileges will all be in the hands of the end user, not on a third party or a developer.
|
|
|
|
|
|
# Auth
|
|
|
|
... | ... | @@ -86,6 +94,11 @@ In a successful communication setup this happens: |
|
|
* authorization type
|
|
|
* the application can now connect to the service.
|
|
|
|
|
|
### Backup trust / hack safety
|
|
|
|
|
|
This is a simplified view. The full algorithm includes shared secrets between **C** and **AS** and between **C** and **S**.
|
|
|
These shared secrets act as a backup safety for the user. If the authentication server is compromised, the shared secret between the **C** and the **S** will ensure the safety of the user data. If the trust system (in our case, DNSSEC) is somehow compromised, the shared secret between the **C** and the **AS** will make it impossible for the attacker to MITM the connection or impersonate the **AS**
|
|
|
|
|
|
## different domain authentication
|
|
|
|
|
|
Assuming **C** and **AS** are in the same domain, and **AS2** and **S2** are in a different domain:
|
... | ... | |