summaryrefslogtreecommitdiff
path: root/Architecture_and_Design
diff options
context:
space:
mode:
authorJeroen van Meeuwen (Kolab Systems) <vanmeeuwen@kolabsys.com>2012-02-21 09:58:11 (GMT)
committerJeroen van Meeuwen (Kolab Systems) <vanmeeuwen@kolabsys.com>2012-02-21 09:58:11 (GMT)
commitfd93897ad62d97a776e2792e2f4279f71dfdbb3b (patch)
treeb36682c2caa66746ccad7438815289d9e2ae1eea /Architecture_and_Design
parentc698864452993e4caa6d35ce8a436a55994b168a (diff)
downloadkolab-docs-fd93897ad62d97a776e2792e2f4279f71dfdbb3b.tar.gz
Add a chapter on how we enforce entitlements
Diffstat (limited to 'Architecture_and_Design')
-rw-r--r--Architecture_and_Design/en-US/Enforcing_Entitlements.xml109
1 files changed, 109 insertions, 0 deletions
diff --git a/Architecture_and_Design/en-US/Enforcing_Entitlements.xml b/Architecture_and_Design/en-US/Enforcing_Entitlements.xml
new file mode 100644
index 0000000..8512420
--- /dev/null
+++ b/Architecture_and_Design/en-US/Enforcing_Entitlements.xml
@@ -0,0 +1,109 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Enforcing_Entitlements">
+ <title>Enforcing Entitlements</title>
+ <para>
+ Kolab Groupware is distributed in two different product streams. The community edition is the edition that is supported by the community only, and the enterprise edition, that prior to release has been subject to the necessary Quality Assurance, and is supported by Kolab Systems, for a longer term more appropriate for most businesses, to an extent dependent on the type of Service Level Agreement purchased.
+ </para>
+ <para>
+ Both product streams however are Free Software entirely. The enterprise edition however has restrictions, and is supported only for such and so many users, systems, domains, mailboxes, groups, and other groupware functionality, again depending on the type of Service Level Agreement that has been purchased.
+ </para>
+ <para>
+ This chapter explains how Kolab Systems enforces entitlements using the enterprise version of its software.
+ </para>
+ <para>
+ It is commonly understood that for Free Software to be released in a fashion that allows the enforcing of entitlements, a version must be released that either;
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Itself contains information that allows the program to verify entitlements given a license file. Such program would need to be binary compiled, randomized, and contain a key to unlock the lock on the license file. More importantly, however, the program would need to be proprietary (the <emphasis>Zarafa</emphasis> mechanism).
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Phone home, to verify its current status is within the boundaries configured for it, against a piece of infrastructure controlled by the vendor (the <emphasis>Red Hat Network</emphasis> mechanism).
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ At Kolab Systems, we don't like either of these options. We have come up with a solution that allows the software to remain Free Software, without requiring systems that have Kolab installed to need to phone home.
+ </para>
+ <section id="sect-Architecture_and_Design-Enforcing_Entitlements-Software_Repositories_Behind_Lock_and_Key">
+ <title>Software Repositories Behind Lock and Key</title>
+ <para>
+ First, we create software repositories in a location that requires the consumer to have been issued a key to the lock. We do this through an SSL certificate infrastructure, for which each consumer that we provide access to the repositories is issued with an SSL Client Certificate.
+ </para>
+ <para>
+ This guarantees us anyone with access to the software repositories (for installation, but for updates as well) is a known customer, and has been issued a certificate with an expiry date, that we can revoke.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Enforcing_Entitlements-Entitlements_Files">
+ <title>Entitlements Files</title>
+ <para>
+ Example entitlements could be, the number of users or groups supported within a Kolab Groupware environment. The information for all of a customer's support entitlement purchases is contained within an entitlements file, which can be supplemented with more entitlements files so that the entitlements can be added up and thus easily extended.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Enforcing_Entitlements-Issuing_Entitlement_Files">
+ <title>Issuing Entitlement Files</title>
+ <para>
+ Knowing each of the customer systems contains a Certificate Authority file, and an SSL Client Certificate, as otherwise the system would not have access to the software repositories for important updates, we can use these existing components to sign and encrypt an entitlement file specific to the customer.
+ </para>
+ <procedure>
+ <step>
+ <para>
+ First, we sign the entitlement file using a Certificate Authority certificate, the same one used to issue and sign the SSL Client Certificate.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Second, we encrypt the entitlement file using the SSL Client certificate we have issued to the customer.
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <para>
+ This guarantees that the only those can read the contents of the entitlements file, that have obtained the SSL Client Certificate, for which we can verify the signature on the entitlements file.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Enforcing_Entitlements-Implementing_Enforcement">
+ <title>Implementing Enforcement</title>
+ <para>
+ The entire infrastructure can be replicated, by anyone, if all the information the system would have is a Certificate Authority, an SSL Client Certificate, and a signed and encrypted entitlements file. It may be relatively hard to reverse engineer the exact contents of the entitlements file, and update the binary compiled code to accept a new set of certificates, but it is certainly possible to achieve.
+ </para>
+ <para>
+ Therefor, the components that can enforce the entitlements (for example, the Kolab Daemon) can contain information about the certificates used in the SSL infrastructure. Not to function as a key to a lock, however, but to verify the other information available checks out against what it expects.
+ </para>
+ <para>
+ It is safe for software to contain such information, as it is not leaking any information that is not already known to the outside world. However the trick is to not allow this information to be altered or tampered with. More to the point, the trick is to not allow this information to be altered or tampered with in a way that can not be detected.
+ </para>
+ <para>
+ Our enterprise edition therefor ships a binary compiled version of the software that contains this information, so that checksums can be verified upon every support request, and to make it harder to both alter the codebase as well as maintain a patch-set.
+ </para>
+ <para>
+ Of course, it is relatively easy to write down any checksums for files right after installation, and run one's own version. However, running one's own version is still detectable through backtraces, and stack traces. If these are reproduced using an original version of the code, then the support issue is legitimate even if the day-to-day code running the environment is not the same.
+ </para>
+
+ </section>
+
+
+</chapter>
+