Currently the framework has direct access to a certificate that allows it to perform privileged operations against the CA component. This flies in the faces of the original framework philosophy which advocates for privilege separation and enforcement of ACIs in the backends not the frontend.
Once ticket https://fedorahosted.org/pki/ticket/1359 is implemented we should be able to forward requests to the CA just like we perform operations against the LDAP server by using s4u2proxy and letting the backend apply Access Controls.
When this work is done, we should consider automatically storing user's Kerberos principal in a certificate SAN or at least in Dogtag object for the certificate - so that certificates for a given principal can be easily searched for.
Earlier comments by Martin Kosek and Simo:
Martin Kosek mkosek@redhat.com wrote:
Agent credential is used by FreeIPA web interface, all authorization is then done on python framework level. We can add more agents and then switch the used certificate, but I wonder how to use it in authorization decisions. Apache service will need to to have access to all these agents anyway.
We really need to move to a separate service for agent access, the framework is supposed to not have any more power than the user that connects to it. By giving the framework direct access to credentials we fundamentally change the proposition and erode the security properties of the separation.
We have discussed before a proxy process that pass in commands as they come from the framework but assumes agent identity only after checking how the framework authenticated to it (via GSSAPI).
First we need to think how fine grained authorization we want to do.
We need to associate a user to an agent credential via a group, so that we can assign the rights via roles.
I think we will want to be able to for example say that user Foo can generate certificates in specified subCA. I am not sure it is a good way to go, it would also make such private key distribution on IPA replicas + renewal a challenge.
I do not think we need to start with very fine grained permissions initially.
Right now, we only have "Virtual Operations" concept to authorize different operations with Dogtag CA, but it does not distinguish between different CAs. We could add a new Virtual Operation for every subCA, but it looks clumsy. But the ACI-based mechanism and our permission system would still be the easiest way to go, IMHO, compared to utilizing PKI agents.
We need to have a different agent certificate per role, and then in the proxy process associate the right agent certificate based on what the framework asks and internal checking that the user is indeed allowed to do so.
The framework will select the 'role' to use based on the operation to be performed.
Simo.
the dogtag prerequisite 1359 was postponed, therefore postponing as well.
master:
Metadata Update from @simo: - Issue assigned to ftweedal - Issue set to the milestone: FreeIPA 4.5
Metadata Update from @tkrizek: - Custom field affects_doc reset - Custom field tester adjusted to wanted - Issue close_status updated to: None
Metadata Update from @tkrizek: - Custom field affects_doc reset
Metadata Update from @mbasti: - Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)
Ground work was prepared in 4.5, but it was not finished. Moving to 4.7 - next major, to be finished there.
Metadata Update from @pvoborni: - Issue set to the milestone: FreeIPA 4.7 (was: FreeIPA 4.5.1)
Metadata Update from @rcritten: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1527185 (was: todo)
Issue linked to Bugzilla: Bug 1527185
Metadata Update from @rcritten: - Issue set to the milestone: FreeIPA 4.7.1 (was: FreeIPA 4.7)
FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone
Metadata Update from @ftweedal: - Assignee reset
ipa-4-8:
Metadata Update from @rcritten: - Issue set to the milestone: None (was: FreeIPA 4.7.1)
Login to comment on this ticket.