[Freeipa-devel] Stageuser API

[Alexander Bokovoy]

On ti, 17 tammi 2017, Christian Heimes wrote:
>On 2017-01-17 12:56, David Kupka wrote:
>> Hi Christian,
>> uniqueness of uid is not checked in staging area on purpose, it may be
>> changed multiple times before the stageuser is transformed into user
>> (activated). The uid uniqueness is then checked during activation.
>>
>> Third party application that use FreeIPA's LDAP should:
>> 1) search for users (and usercertificate attribute) only in
>> cn=users,cn=accounts
>> 2) respect the value of nsAccountLock that is set to true for all staged
>> users.
>>
>> But it would be nice to have this scenario (stageuser.uid == user.uid)
>> implemented as a part of [1].
>
>Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd
>party application *always* use the FreeIPA API or LDAP to validate a
>user cert? Some applications may just validate the certificate and
>OCSP/CRL for client cert authentication with e.g. mod_ssl.
>
>Consider this scenario:
>
>1) IT issues a smart card for a staging user. The smart card contains a
>valid private/public key pair for FreeIPA.
>2) HR sends the smart card to a new hire.
>3) HR creates a standard user with same login as staging user
>4) New hire uses the smart card to log into a system that only verifies
>validity of cert (signature, dates, OCSP status) and uses subject to
>identify user.
The certificate validity for a future users should have
validity.notBefore property set.  A login before that time should not be
possible with systems like (4) describes.

>Even if we 'fix' the issue with non-unique UIDs in staging, it stays
>dangerous to hand a valid certificate to a not-yet-valid user. At least
>we should try to reduce risks with a couple of measures:
>
>* Add a "valid from" field to stage users and set the cert's valid from
>date accordingly. That renders the public key useless until the
>estimated first day on the job.
According to RFC 3280, validity is the mandatory part of the x.509
certificate. Granted, certmonger does not allow you to set
validity.notBefore to some externally defined value, but this is
something we could implement. You can already achieve that with your own
certificate signing request. And it this case we deal with externally
provided user certificates, so we could have no ability to influence
what happens at all.

>* Lock the smart card with a PIN and don't release the PIN until the
>user has been moved from staging area to user area. This arrangement
>makes the smart card inaccessible. We could use the KRA to store the PIN.
This is just a process, not a technical solution. Someone needs to
communicate PIN separate to the smartcard to a new hire anyway.


-- 
/ Alexander Bokovoy