[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

On 03/08/2012 04:54 PM, Dmitri Pal wrote:
> On 03/06/2012 01:30 PM, Ondrej Hamada wrote:
>> On 03/06/2012 05:47 PM, Dmitri Pal wrote:
>>> On 03/06/2012 10:59 AM, Simo Sorce wrote:
>>>> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote:
>>>>> [...]
>>>>>> For a read-only KDC we need to investigate what's the better
>>>>> solution.
>>>>>> There are many ways we can handle the issue, one of the simplest is
>>>>>> probably to allow the RO KDC to use a special LDAP Extended
>>>>> operation
>>>>>> against a full R/W server to get the user keys to sign,
>>>>> authenticating
>>>>>> with a special R/O KDC principal. We can also investigate how MS
>>>>> does
>>>>>> internal forwarding and do something similar as I suspect that's
>>>>>> something samba4-RODC will want to implement too, so we could share
>>>>> some
>>>>>> of the development burden there.
>>>>>>
>>>>>> Simo.
>>>>>>
>>>>> I do not think it is a good idea for the remote RO KDC to go back to
>>>>> the main datacenter on every authentication without some sort of
>>>>> caching. This is why I think that some kind of SSSD integration might
>>>>> be due. If RO KDC would just pass the authentication to SSSD in some
>>>>> way and SSSD would do the caching in case the office gets offline. I
>>>>> understand that authhub as is will not work as the client sends time
>>>>> stamp encrypted with password and SSSD needs plain text password as
>>>>> credential. I do not know if there is a way to solve this without
>>>>> actually sending the password in the tunnel. IMO it is more important
>>>>> to make sure that remote office can have uninterrupted operation than
>>>>> to worry about the password being sent inside the encrypted tunnel. It
>>>>> is something that deployment should decide and weight risks against
>>>>> convenience.
>>>> This is why MS does partial replication, ie allows the RODC to have
>>>> data
>>>> about the office users. It's complex and there are many ways to handle
>>>> it. We need to look at various options and see how they would work
>>>> against uses cases we want to support.
>>>> Simo.
>>>>
>>> Then may be Ondrej should start with formulating use cases and
>>> requirements based on this discussion.
>>>
>> I see three possible use cases here, but only two should be considered
>> when speaking about consumer node:
>>
>> 1) The office that should rely on that replica is quite a big one
>> (hundreds of employees) or many different users are authenticating
>> against its replica or there are located admins, who need to do a lot
>> of write-operations. -->  In this case I suppose the best solution is
>> to deploy master replica there.
>>
>>
>> 2) Office that doesn't fulfil the conditions in 1) - not a desperate
>> need for write-operations on ipa-server, but the priority is to allow
>> (some) clients to authenticate and use available services even when
>> the network is down. -->  We need a consumer with credentials caching,
>> authentication requests for non-cached users or write operations must
>> be forwarded to master.
>>
>> 3) Office that doesn't fulfil the conditions in 1), but the priority
>> is security, so that the consumer is not allowed to store or cache any
>> confidential data. -->  We need a consumer, authentications and write
>> operations must be forwarded to master.
>>
>> If we choose the second use case, both the caching and request
>> forwarding must be implemented. I suppose that there shouldn't be big
>> problem to decide during the installation to turn the caching off by
>> some option like '-no-chaching' so that the consumer could be used for
>> the third use case as well.
>>
> Can you please now create a set usage scenarios for the 2) and 3).
> User logs in and he is in cache, he is not in cache, he is redirected
> and data is cached, he failed and account lockout data is updated
> locally or on the other server? Admin tries to perform and IPA command
> or ldapmodify command - what happens?
>
> Can those work flows be spelled out in details for caching and non use
> cases?
>
>

I'll start with usage scenario for 3), it's shorter:
All write operations and authentication requests are forwarded to the master

Operations when connection is OK:
----------------------------------------------
read -- local
write-forwarding to master
authentication-forwarding to master

Operations when connection is BROKEN:
-----------------------------------------------------
read-local (only until ticket expires)
write-not available
authentication-not available


Usage scenario for 2):

USER'S operations when connection is OK:
-------------------------------------------------------
read data -> local
write data -> forwarding to master
authentication:
-credentials cached -- authenticate against credentials in local cache
                         -on failure: log failure locally, update data 
about failures only on lock-down of account
-credentials not cached -- forward request to master, on success cache 
the credentials

USER'S operations when connection is BROKEN:
--------------------------------------------------------------
read data -> local
write data -> not available
authentication:
-credentials cached -- authenticate against credentials in local cache
                             -on failure: log failure locally, on 
lock-down lock account locally and update information to master when the 
connection is back on
-credentials not cached -- deny access -- not possible to authenticate user

ad ADMIN'S -- I suppose that admin's credentials should not be cached -- 
it doesn't make much sense because all the operations, he's permitted to 
do, could be executed on master server only

ADMIN'S operations when connection is OK:
---------------------------------------------------------
read - local
write - forwarding to master
authentication - forwarding to master

ADMIN'S operations when connection is BROKEN:
----------------------------------------------------------------
read-only operations until valid ticket expires
write - not available
authentication - not available

-- 
Regards,

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120312/354bc957/attachment.htm>