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:

• caca181d3b73c045abd72e464a195c6b61c251c7 private_ccache: yield ccache name

master:

• f51869bf5214e2d2322f85bf72b7ae86b6893974 replica install: relax domain level check for promotion

master:

• 2066a80be21258d9311ae374fe124d9ac3b79acd Remove redundant principal_type argument
• 11c9df25774fbc8ed24b30f75c205d12ca3c5b90 Extract method to map principal to princpal type

master:

• 3ba0375c831eca673c2df146b565a32dbc03fdb3 rabase.get_certificate: make serial number arg mandatory

Ground work was prepared in 4.5, but it was not finished. Moving to 4.7 - next major, to be finished there.

Issue linked to Bugzilla: Bug 1527185

FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone

master:

• c7766ebb940cca040d08a1dd58b92f6546ca3e9b (HEAD) Define errors_by_code in ipalib.errors

ipa-4-8:

• 7bfe6b261fa03ecc05d9f75ef24175f588d45e16 (HEAD) Define errors_by_code in ipalib.errors

master:

• 0c0061babdd9a6584ea30742648a200d6aa4d3ba extract virtual operation access check subroutine

master:

• d7f3a0b2d31fe3a02a19286d590cf1a343458fd8 ra.get_certificate: use REST API

master:

• 5ab24ddf8a74c4c59c5c28bc79da150633530363 ca-del: require CA to already be disabled
• 6da63e3be44033d7d623a574787937ab4ec9ed0a ca plugin: improve doc
• 6a0901f6fdf744023dc90ec5141aa9ebe4d806fd tests: fix cleanup for CATracker

Should this be closed?

I found this link mentioned as a precondition on the page https://www.freeipa.org/page/V4/Sub-CAs#implementation