b5b9efeb57
A "cookie" is used with certmonger to track the state of a request across multiple requests to a CA (in ca-cookie). This is used with the certmonger POLL operation to submit a request to the CA for the status of a certificate request. This, along with the profile, are passed to the certmonger CA helper scripts via environment variables when a request is made. It is cleared from the certmonger request once the certificate is issued. This CA helper can do a number of things: - SUBMIT new certicate requests (including the CA) - POLL for status of an existing certificate request - For non renewal masters, POLL to see if an updated cert is in LDAP A POLL operation requires a cookie so that the state about the request can be passed to the CA. For the case of retrieving an updated cert from LDAP there is no state to maintain. It just checks LDAP and returns either a cert or WAIT_WITH_DELAY if one is not yet available. There are two kinds of cookies in operation here: 1. The CERTMONGER_CA_COOKIE environment variable passed via certmonger to this helper which is a JSON object. 2. The cookie value within the JSON object which contains the URL to be passed to dogtag. For the purposes of clarity "cookie" here is the value within the JSON. The CERTMONGER_CA_COOKIE is deconstructed and reconstructed as the request is processed, doing double duty. It initially comes in as a JSON dict object with two keys: profile and cookie. In call_handler the CERTMONGER_CA_COOKIE is decomposed into a python object and the profile compared to the requested profile (and request rejected if they don't match) and the cookie key overrides the CERTMONGER_CA_COOKIE environment variable. This is then reversed at the end of the request when it again becomes a JSON object containing the profile and cookie. This script was previously enforcing that a cookie be available on all POLL requests, whether it is actually required or not. This patch relaxes that requirement. The first request of a non-renewal master for an updated certicate from LDAP is a SUBMIT operation. This is significant because it doesn't require a cookie: there is no state on a new request. If there is no updated cert in LDAP then the tracking request goes into the CA_WORKING state and certmonger will wait 8 hours (as returned by this script) and try again. Subsequent requests are done using POLL. This required a cookie so all such requests would fail with the ca-error Invalid cookie: u'' as it was empty (because there is no state). There is no need to fail early on a missing cookie. Enforcement will be done later if needed (and it isn't always needed). So if CERTMONGER_CA_COOKIE is an empty string then generate a new CERTMONGER_CA_COOKIE containing the requested profile and an empty cookie. It still will fail if certmonger doesn't set a cookie at all. An example of a cookie when retrieving a new RA Agent certificate is: {"profile": "caServerCert", "cookie": "state=retrieve&requestId=20"} This will result in this request to the CA: [09/Jan/2020:14:29:54 -0500] "GET /ca/ee/ca/displayCertFromRequest?requestId=20&importCert=true&xml=true HTTP/1.1" 200 9857 For a renewal, the reconstructed cookie will consist of: {"profile": "caServerCert", "cookie": ""} https://pagure.io/freeipa/issue/8164 Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com> |
||
---|---|---|
.copr | ||
asn1 | ||
client | ||
contrib | ||
daemons | ||
doc | ||
init | ||
install | ||
ipaclient | ||
ipalib | ||
ipaplatform | ||
ipapython | ||
ipaserver | ||
ipatests | ||
po | ||
pypi | ||
util | ||
.freeipa-pr-ci.yaml | ||
.git-commit-template | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.tox-install.sh | ||
.wheelconstraints.in | ||
ACI.txt | ||
API.txt | ||
autogen.sh | ||
BUILD.txt | ||
CODE_OF_CONDUCT.md | ||
configure.ac | ||
Contributors.txt | ||
COPYING | ||
COPYING.openssl | ||
freeipa.doap.rdf | ||
freeipa.spec.in | ||
ipa.in | ||
ipasetup.py.in | ||
make-doc | ||
make-test | ||
makeaci.in | ||
makeapi.in | ||
Makefile.am | ||
Makefile.python.am | ||
Makefile.pythonscripts.am | ||
makerpms.sh | ||
pylint_plugins.py | ||
pylintrc | ||
README.md | ||
server.m4 | ||
tox.ini | ||
VERSION.m4 | ||
zanata.xml |
FreeIPA Server
FreeIPA allows Linux administrators to centrally manage identity, authentication and access control aspects of Linux and UNIX systems by providing simple to install and use command line and web based management tools.
FreeIPA is built on top of well known Open Source components and standard protocols with a very strong focus on ease of management and automation of installation and configuration tasks.
FreeIPA can seamlessly integrate into an Active Directory environment via cross-realm Kerberos trust or user synchronization.
Benefits
FreeIPA:
- Allows all your users to access all the machines with the same credentials and security settings
- Allows users to access personal files transparently from any machine in an authenticated and secure way
- Uses an advanced grouping mechanism to restrict network access to services and files only to specific users
- Allows central management of security mechanisms like passwords, SSH Public Keys, SUDO rules, Keytabs, Access Control Rules
- Enables delegation of selected administrative tasks to other power users
- Integrates into Active Directory environments
Components
The FreeIPA project provides unified installation and management tools for the following components:
- LDAP Server - based on the 389 project
- KDC - based on MIT Kerberos implementation
- PKI based on Dogtag project
- Samba libraries for Active Directory integration
- DNS Server based on BIND and the Bind-DynDB-LDAP plugin
Project Website
Releases, announcements and other information can be found on the IPA server project page at http://www.freeipa.org/ .
Documentation
The most up-to-date documentation can be found at http://freeipa.org/page/Documentation .
Quick Start
To get started quickly, start here: http://www.freeipa.org/page/Quick_Start_Guide
For developers
- Building FreeIPA from source
- http://www.freeipa.org/page/Build
- See the BUILD.txt file in the source root directory
Licensing
Please see the file called COPYING.
Contacts
- If you want to be informed about new code releases, bug fixes, security fixes, general news and information about the IPA server subscribe to the freeipa-announce mailing list at https://www.redhat.com/mailman/listinfo/freeipa-interest/ .
- If you have a bug report please submit it at: https://pagure.io/freeipa/issues
- If you want to participate in actively developing IPA please subscribe to the freeipa-devel mailing list at https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/ or join us in IRC at irc://irc.freenode.net/freeipa