|
|
|
# Federation
|
|
|
|
|
|
|
|
There has been a lot of talk lately in the Federated vs Distributed environments.
|
|
|
|
|
|
|
|
I therefore created a [page](Federated_vs_Distributed) to try to explain why a Federated environment is usually (but not always) better than a completely distributed one, the strengths and weaknesses of both architectures.
|
|
|
|
|
|
|
|
The short version is: today "distributed" means non-interoperable, slow and lack of control. While this can be good for systems that seek anonymity, it is be very bad for other applications, especially commercial ones.
|
|
|
|
|
|
|
|
This does **not** mean that Fenrir can not be used to build distributed systems. The flexibility of this protocol allows you to build non-federated, distributed protocols.
|
|
|
|
|
|
|
|
Again, much more is explained in the [Federated_vs_Distributed](Federated_vs_Distributed) page.
|
|
|
|
|
|
|
|
# Details
|
|
|
|
|
|
|
|
Once you have read the [Authentication Details](Auth_Details), you can understand how Fenrir creates secure channels.
|
|
|
|
|
|
|
|
But what is the data that is exchanged, and how do federated environments interact?
|
|
|
|
|
|
|
|
When needed we will use these abbreviations:
|
|
|
|
* **AS**: Authentication Server
|
|
|
|
* **S**: Service
|
|
|
|
* **C**: Client
|
|
|
|
|
|
|
|
In our federated examples, the client from **example.org** will connect to **example.com** (note the different TLD)
|
|
|
|
|
|
|
|
## 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 128 or 256bit, used to authenticate to other federated domains.
|
|
|
|
* authorization types: one per token: 1 byte to limit actions of the users.
|
|
|
|
|
|
|
|
## The Authorization
|
|
|
|
|
|
|
|
Fenrir supports authentication, but how is authorization different?
|
|
|
|
|
|
|
|
Authorization defines the set of privileges that a user can have.
|
|
|
|
|
|
|
|
Usually when we login somewhere we have complete access to the action that user can do -- This is authentication without authorization.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
# Introducing the Authorization Lattice
|
|
|
|
|
|
|
|
The new concept introduced in Fenrir is that of an **authorization lattice**: we use a Lattice to group the possible privileges in a hierarchal way, so that a user can always limit himself, but can not get higher authorization than what he was given.
|
|
|
|
|
|
|
|
Take this authorization lattice for example:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Recall that in a client device we find a Fenrir Client and the applications. The Fenrir Client 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.
|
|
|
|
|
|
|
|
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").
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
# Auth
|
|
|
|
|
|
|
|
The whole authentication works more or less like this:
|
|
|
|
|
|
|
|
## Same-domain authentication
|
|
|
|
|
|
|
|
In a successful communication setup this happens:
|
|
|
|
* **C** sends to **AS**:
|
|
|
|
* authentication data (token, user/pass, other...)
|
|
|
|
* client id
|
|
|
|
* authorization type
|
|
|
|
* **AS** verifies the information and sends to the Service:
|
|
|
|
* new client keys, id, ip
|
|
|
|
* new client authorization type
|
|
|
|
* **AS** sends to the client:
|
|
|
|
* client keys
|
|
|
|
* Service ip, port etc...
|
|
|
|
* the client can now connect to the service.
|
|
|
|
|
|
|
|
## different domain authentication
|
|
|
|
|
|
|
|
Assuming **C** and **AS** are in the same domain, and **AS2** and **S2** are in a different domain:
|
|
|
|
|
|
|
|
* **C** asks to his **AS** new tokens for the service **S2**, which is in an other domain.
|
|
|
|
* **AS** gives back a token
|
|
|
|
* **C** uses the token to authenticate with **AS2**, in the other domain, asking for service **S2**
|
|
|
|
* **AS** and **AS2** verify the token, **AS2** might send the service lattice to **AS**
|
|
|
|
* **AS2** sends the service data to **C**
|
|
|
|
* **C** can connect to the **S2**
|
|
|
|
|
|
|
|
# The downside
|
|
|
|
|
|
|
|
This lattice management means that the service has to synchronize the authorization lattice with all the Authentication Servers that play a role in the authentication and with the client.
|
|
|
|
|
|
|
|
While this is not a big problem intra-domain, it can be a little problem in intra-domain setups.
|
|
|
|
|
|
|
|
## Lattice size
|
|
|
|
|
|
|
|
The lattice will be transferred as a list of:
|
|
|
|
* one byte: lattice version
|
|
|
|
* one byte: number X of nodes (max:64)
|
|
|
|
* X 64 bit bitmask to represent connections between nodes
|
|
|
|
* X null-terminated strings (max: 25 char?) as node label
|
|
|
|
|
|
|
|
This means that a full lattice weights 2+8**64+64**25 = 2114 bytes, which is 2 packets at maximum.
|
|
|
|
|
|
|
|
## Lattice synching
|
|
|
|
|
|
|
|
The problem of lattice versions is taken care of with the "lattice version" byte, although I still have to think about how to **convert** a token from one lattice version to the other. (suggestions?)
|
|
|
|
|
|
|
|
The lattice distribution is done the first time a client connects to a service. Since it is the first time, we can authenticate and assume that the user has full access ("top"), but as soon as we have authenticated we transfer the lattice to the client.
|
|
|
|
|
|
|
|
|
