-
Notifications
You must be signed in to change notification settings - Fork 396
Add xrealmauthz KDC policy plugin for cross-realm authorization #1431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for submitting this. Before I get into any details, I want to have a conversation to determine whether this functionality has enough general applicability to warrant maintaining it within the upstream krb5 tree. As a general rule the KDC is responsible primarily for authentication, secondarily for authorization, and usually not for access control. There are some exceptions, such as the require_auth string attribute and the restrict_anonymous_to_tgt variable, but for the most part we make application servers bear the burden of access control decisions. @abbra has argued that Windows cross-forest trust is not transitive, while cross-realm relationships in MIT krb5 are. However, MIT krb5 implements transited rules that should generally prohibit access from unknown realms. If there are cross-realm keys A<->B and B<->C but A has never heard of C, principals in C should not be able to authenticate to services in A unless A is configured to believe that B is allowed to transit tickets from C. |
You're welcome, and thank you @greghudson for your consideration. I just pushed a 3 line change for the I understand the architectural concerns about the KDC's role in access control. This is why we implemented this as an optional kdcpolicy plugin rather than modifying core KDC behavior making use of the interface that enables this exact sort of functionality. While krb5's transited rules should prohibit access from unknown realms, they don't provide principal-level granularity within trusted known realms or transited realms. As you noted, krb5 traditionally delegates access control decisions to application servers. To draw an analogy from network security: when protecting thousands of servers, it's common practice to implement firewall rules centrally at the network ingress rather than configuring rules on each individual server. Some organizations prefer defense-in-depth with rules at both layers. This plugin provides krb5 administrators with a similar architectural choice for cross-realm authorization. Sites can now implement principal-level and realm-level access controls centrally at the KDC level, either as their primary control point or as an additional layer complementing application-level controls. This flexibility allows organizations to choose the security architecture that best fits their needs...whether that's centralized control, distributed control, or defense-in-depth with both. |
I think it makes sense to have per-principal (even with a wildcard) access control at the KDC side because it certainly reduces load on the application servers in making the organisation-wide access control decisions. It could be compared with OAuth2-based IdP situations where it is increasingly common. |
@greghudson as per our offline discussion, I think this kind of plugin would be a special case of the following's requirement in the Active Directory's MS-KILE 3.3.5.7 TGS Exchange section:
This is effectively a trigger during TGS-REQ that requires to apply additional external access check before issuing a ticket. E.g. a principal needs to have the allowed to authenticate right on the target principal to get the ticket issued. And this can be used to limit access to krbtgt/TRUSTED@TRUSTING by defining such rules on the TDOs. |
To provide some context for Dax: one of the objections I've seen raised to adding KDC access control facilities is that it could encourage application servers to rely on the KDC instead of doing its own access control, in turn creating an interoperability issue (that some application servers could be deployed securely with one KDC implementation but not another). This objection is less compelling if another of the three most-used KDC implementations has already added a similar access control facility. It looks like there is fairly strong parity between the proposed functionality in this PR and the existing Allowed-to-Authenticate access check in Active Directory. Like the facility in this PR, it appears the Allowed-to-Authenticate check only applies to TGS requests which cross a specifically configured cross-organization trust (those configured with "selective authentication"). So I think that takes care of the general concern. I will review the specifics of the PR and have more feedback soon. |
Starting with a small but important detail: is "Copyright (C) 2017 by Red Hat, Inc." correct for xrealmauthz/main.c? I can see two directions for accepting this contribution:
|
It is correct other than the year. I can update that.
I would advocate for option 1. You are right, the tests are comprehensive and keep it from bitrotting. As an optionally loaded plugin it doesn't impact those who don't need it, and it is currently in use as in at a production site handling 9 million requests a day. The current attribute structure evolved through real-world deployment experience. We encountered and addressed several corner cases in production that shaped the current implementation so its design is battle tested. |
This was the initial idea for this plugin. It had the advantage of optimization, because the server principal entry is passed to the Regarding the direction to take, maybe option 2 is too much of an effort, given the limited audience of this feature, at least for now. Overtime, we could accumulate feedback from our use of this plugin in FreeIPA, and from other users that might be interested in cross-realm access control. Then we could eventually come up with a more final design to be implemented in the core KDC. In this approach, the priority would be to agree on a stable attribute structure, so ideally it would be possible to switch from the plugin to the future core KDC implementation transparently. If we keep the plugin, an immediate improvement that could be made in the core KDC however, would be to add a plugin interface to test access rules before processing the TGS-REQ, contrary to the current |
I don't think that is accurate. The current structure of TGS processing is:
kdcpolicy module checks are done in step 2 (check_tgs_req() -> check_kdcpolicy_tgs()). The KDB is also consulted in step 2 (check_tgs_req() -> check_tgs_policy() -> krb5_db_check_policy_tgs()). |
I've pushed some changes:
Still to address:
This code and its tests could get significantly simpler if we ditched the enforcing flag. But I'm willing to leave it in if it's considered important, under the assumption that this remains a plugin module. |
I'll review the specific changes, but the list looks very reasonable.
Regarding the enforcing flag: I strongly believe it's worth keeping. The first version of the plugin did not have this feature. When we first deployed this plugin in a complex production environment with both krb5 and AD realms, we encountered many unanticipated denials. For example, AD clients with direct trust to a krb5 realm were presenting cross-realm TGTs from other trusted realms instead of using the direct path. I then added the enforcing flag to allow us to run in monitoring mode and analyze logs for a month to identify these misconfigurations and edge cases. This approach mirrors SELinux's enforcing vs permissive modes and other authorization software. Without this capability, we would have had broken production workflows. Based on this experience, I consider the enforcing flag an important feature that significantly reduces deployment risk, especially in complex environments where the plugin is most likely to be deployed. |
0f46b48
to
fbe475b
Compare
@greghudson taking a look at the changes you made and everything looks great to me. One question though, since it requires manual configuration steps to load, why not have it be installed by the build system? End users that rely on their linux distribution krb5 packages will need to build their own or open tickets with their distro to modify their distro's packages to include the module. |
This was previously discussed in the "two directions" comment I made earlier. If we install an artifact from the build system, it is incumbent upon the project to document it and support it, whether it's activated by default or not. If the project is going to do that for this functionality, the shape of the design (almost certainly including the fail-closed behavior and monitoring flag) would likely need to change to better align with MIT krb5's existing policy controls. If the project merely includes the source code in the tree and run its tests to make sure it keeps working in the face of changes elsewhere, that alignment is much less important. It is true that distributions will have to take an active step to facilitate the use of this module. That is intentional, as they will be taking on the burden of documenting and supporting it for their users. |
This module provides fine-grained access control for cross-realm authentications by checking string attributes on the incoming cross-realm TGT entry. It supports realm-based and principal-specific authorization rules. The module is not installed by the build system or loaded by default, and is documented only in the module source code. [ghudson@mit.edu: simplified code and tests; edited commit message]
@greghudson thanks for merging the code into master! When you modify the README my full name is: Dax Kelson Thanks again! |
This PR introduces a new KDC policy plugin (xrealmauthz) that provides fine-grained authorization control for cross-realm authentication in MIT Kerberos. The plugin allows administrators to explicitly authorize which realms and/or principals can obtain cross-realm TGT to access services across realm boundaries, enhancing security in multi-realm Kerberos deployments.
Changes
New plugin: xrealmauthz
Key features:
Testing
Configuration example
Authorization examples
realm based:
principal based:
Compatibility
Security considerations
This plugin addresses the need for explicit authorization in cross-realm scenarios, providing administrators with fine-grained control over which external principals can access their realm's services.