[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

>> Sorry for inactivity, I was struggling with a lot of school stuff.
>>
>> I've summed up the main goals, do you agree on them or should I
>> add/remove any?
>>
>>
>> GOALS
>> ===========================================
>> Create Hub and Consumer types of replica with following features:
>>
>> * Hub is read-only
>>
>> * Hub interconnects Masters with Consumers or Masters with Hubs
>>     or Hubs with other Hubs
>>
>> * Hub is hidden in the network topology
>>
>> * Consumer is read-only
>>
>> * Consumer interconnects Masters/Hubs with clients
>>
>> * Write operations should be forwarded to Master
>>
>> * Consumer should be able to log users into system without
>>     communication with master
> We need to define how this can be done, it will almost certainly mean
> part of the consumer is writable, plus it also means you need additional
> access control and policies, on what the Consumer should be allowed to
> see.
>
>> * Consumer should cache user's credentials
> Ok what credentials ? As I explained earlier Kerberos creds cannot
> really be cached. Either they are transferred with replication or the
> KDC needs to be change to do chaining. Neither I consider as 'caching'.
> A password obtained through an LDAP bind could be cached, but I am not
> sure it is worth it.
>
>> * Caching of credentials should be configurable
> See above.
>
>> * CA server should not be allowed on Hubs and Consumers
>
> Missing points:
> - Masters should not transfer KRB keys to HUBs/Consumers by default.
>
> - We need selective replication if you want to allow distributing a
> partial set of Kerberos credentials to consumers. With Hubs it becomes
> complicated to decide what to replicate about credentials.
>
> Simo.
>

Can you please have a look at this draft and comment it please?


Design document draft: More types of replicas in FreeIPA

GOALS
=================================================================

Create Hub and Consumer types of replica with following features:

* Hub is read-only

* Hub interconnects Masters with Consumers or Masters with Hubs
   or Hubs with other Hubs

* Hub is hidden in the network topology

* Consumer is read-only

* Consumer interconnects Masters/Hubs with clients

* Write operations should be forwarded to Master

* Consumer should be able to log users into system without
   communication with master

* Consumer should be able to store user's credentials

* Storing of credentials should be configurable and disabled by default

* Credentials expiration on replica should be configurable

* CA server should not be allowed on Hubs and Consumers

ISSUES
=================================================================

- SSSD is currently supposed to cooperate with one LDAP server only

- OpenLDAP client and its support for referrals

- 389-DS allows replication of whole suffix only

- Storing credentials and allowing authentication against Consumer server


POSSIBLE SOLUTIONS
=================================================================

389-DS allows replication of whole suffix only:

* Rich said that they are planning to allow the fractional replication 
in DS to
   use LDAP filters. It will allow us to do selective replication what 
is mainly
   important for replication of user's credentials.

______________________________________

Forwarding of requests in LDAP:

* use existing 389-DS plugin "Chain-on-update" - we can try it as a proof of
concept solution, but for real deployment it won't be very cool solution 
as it
will increase the demands on Hubs.

* better way is to use the referrals. The master server(s) to be referred
   might be:
    1) specified at install time
    2) looked up in DNS records
    3) find master dynamically - Consumers and Hubs will be in fact master
       servers (from 389-DS point of view), this means that every 
consumer or hub
       knows his direct suppliers a they know their suppliers ...
   ISSUE: support for referrals in OpenLDAP client

* SSSD must be improved to allow cooperation with more than one LDAP server
_____________________________________

Authentication and replication of credentials:

* authentication policies, every user must authenticate against master 
server by
default
   - if the authentication is successful and proper policy is set for 
him, the
     user will be added into a specific user group. Each consumer will 
have one
     of these groups. These groups will be used by LDAP filters in 
fractional
     replication to distribute the Krb creds to the chosen Consumers only.

   - The groups will be created and modified on the master, so they will get
     replicated to all Hubs and Consumers. Hubs make it more complicated 
as they
     must know which groups are relevant for them. Because of that I 
suppose that
     every Hub will have to know about all its 'subordinates' - this 
information
     will have to be generated dynamically - probably on every change to the
     replication topology (adding/removing replicas is usually not a very
     frequent operation)

   - The policy must also specify the credentials expiration time. If 
user tries to
     authenticate with expired credential, he will be refused and 
redirected to Master
     server for authentication.

ISSUE: How to deal with creds. expiration in replication? The replication of
     credential to the Consumer could be stopped by removing the user 
from the
     Consumer specific user group (mentioned above). The easiest way 
would be to
     delete him when he tries to auth. with expired credentials or do a 
regular
     check (intervals specified in policy) and delete all expired creds. 
Because
     of the removal of expired creds. we will have to grant the Consumer the
     permission to delete users from the Consumer specific user group 
(but only
     deleting, adding users will be possible on Masters only).

Offline authentication:

* Consumer (and Hub) must allow write operations just for a small set of
   attributes: last login date and time, count of unsuccessful logins 
and the
           lockup of account

   - to be able to do that, both Consumers and Hubs must be Masters(from
   389-DS point of view). When the Master<->Consumer connection is 
broken, the
   lockup information is saved only locally and will be pushed to Master
   on connection restoration. I suppose that only the lockup information 
should
   be replicated. In case of lockup the user will have to authenticate 
against
   Master server only.

Transfer of Krb keys:

* Consumer server will have to have realm krbtgt. This means that we 
will have
   to distribute every Consumer's krbtgt to the Master servers. The 
Masters will
   need to have a logic for using those keys instead of the normal krbtgt to
   perform operations when user's krbtgt are presented to a different 
server.
____________________________________

-- 
Regards,

Ondrej Hamada
FreeIPA team
jabber: ohama at jabbim.cz
IRC: ohamada