Each IPA user will have the ability to request a cryptographic
certificate. The primary usage for user certificates is for
authentication in cases where Kerberos is not an option: Across
firewalls and cases where cross domain trust has not been established.
There are a range of options for implementing user certificates. The
variables are the number of certificates per user, the work-flow for
approving certificates, and tracking the approval agent for a
certificate signing.
The simplest use case is a user can have only a single certificate, and
it gets approved automatically. This is the way host certificates
currently work. The justification for automated approval is that the
user has already authenticated themselves via Kerberos in order to
request the ticket in the first place.
There is an argument for allow a user to have multiple certificates. The
user might have multiple devices, such as both a laptop and a cellphone,
that should be independently authenticated. Allowing multiple
certificates means that the user is not responsible for transporting
private keys between the two devices, and thus they are less likely to
accidentally expose it. It also means that revoking a certificate for a
lost cell phone will not cut off all remote access for a user.
Some organizations might decide that a certificate needs to require a
higher guarantee of the users identity than just the Kerberos ticket. If
certificate signing is not automated, then IPA is going to need both a
queue to track certificate requests and a mechanism to notify the
approval authority upon request submission. In order for a user to
approve a CSR request, that user would need an appropriate ACI. This
would be managed by IPA Roles. Approval of a certificate should then be
an audited process, which could be done by customizing the User
certificate profile to record the approving user.
Heavy use of user certificates would provide a much larger load on the
OCSP service proxied through the IPA server. This load would need to be
taken into account during deployment planning.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
