| --- |
| layout: post |
| status: PUBLISHED |
| published: true |
| title: Securing Apache Geode With Your Corporate LDAP |
| id: 79dbaddf-99f8-4389-bd3b-2e19424a2122 |
| date: '2015-07-29 18:10:27 -0400' |
| categories: geode |
| tags: |
| - ldap |
| - security |
| - apache |
| - geode |
| permalink: geode/entry/securing_apache_geode_with_your |
| --- |
| <p class="c4"><span class="c2">This is a guest blog post written by Apache Geode contributor Guillermo Tantachuco</span></p> |
| <p class="c4"><span class="c2">To protect your data and to mitigate threats such as spoofing, information disclosure, replay attacks and elevation of privileges, </span><span class="c7"><a class="c0" href="http://geode.incubator.apache.org">Apache Geode (incubating)</a></span><span class="c2"> provides </span><span class="c7"><a class="c0" href="http://geode-docs.cfapps.io/docs/managing/security/chapter_overview.html">mature security features</a></span><span class="c2"> such as authentication, authorization and SSL communication that have consistently addressed customer’s security requirements for over a decade</span><span class="c16">. </span><span class="c2">Apache Geode provides a flexible security framework and lets you integrate it with your organization’s preferred authentication method. In this article, we are going to discuss system-level authentication with LDAP and a sample authorization method. For system-level security, you need a service account, which is an account that belongs to your application instead of to an individual end-user. This is similar to how most applications currently connect to a relational database. </span></p> |
| <p class="c4"><span class="c2">Apache Geode provides two (2) types of </span><span class="c6">authentication</span><span class="c2">: </span></p> |
| <ul class="c1 lst-kix_list_1-0 start"> |
| <li class="c10 c9"><span class="c2 c8">Cache server authentication</span><span class="c2"> allows a new member to join a cluster. The membership coordinator is responsible for authenticating credentials of the new member. Geode assumes that the coordinator is authenticated and subsequent members authenticate against the coordinator. When using locators, the coordinator is the first locator to join the cluster. When using multicast, the coordinator is the first server to join the cluster</span></li> |
| <li class="c9 c10"><span class="c2 c8">Client authentication</span><span class="c2"> enables client apps to provide service account credentials to a server during connection initialization and for each operation request so that servers never process the same request twice</span></li> |
| </ul> |
| <p class="c4"><span class="c2">To protect the membership coordinator, it is important to point out that you should always run the Geode cluster in a secure environment.</span></p> |
| <p class="c4"><span class="c2">To prevent replay attacks, the server generates a random unique identifier and returns it to the client to use in its next operation request (get, put, destroy, among others). Then the server verifies the client’s unique identifier, processes the client request, and responds with a new randomly generated unique identifier, for the client to include in its next request. Please see Apache Geode online documentation for </span><span class="c7"><a class="c0" href="http://geode-docs.cfapps.io/docs/managing/security/authentication_overview.html">more details about authentication</a></span></p> |
| <p class="c4"><span class="c2">The </span><span class="c6">authorization</span><span class="c2"> of operations performed by a client application on a cluster can be restricted or completely blocked according to your configurations and programmatic authorization callback. There are two (2) types of authorization callbacks:</span></p> |
| <ul class="c1 lst-kix_list_4-0 start"> |
| <li class="c10 c9"><span class="c2 c8">Pre-operation</span><span class="c2">: you can program the authorization callback to do something before the operation is executed</span></li> |
| <li class="c10 c9"><span class="c2 c8">Post-operation</span><span class="c2">: All client operations that return a result (like get and query) and all notifications can also be authorized where the callback can peek and even modify the result before it is sent out to the client</span></li> |
| </ul> |
| <p class="c4"><span class="c2">What about audit trails? Any authorization implementation can also create an audit trail given that the following information is available to you: authorized user, code of the operation performed, region name, remote client and operation data (e.g: data for PUT and PUTALL commands). All that information can be stored wherever you decide including but not limited to: database table, log file and Apache Geode region. Please see Apache Geode online documentation for </span><span class="c7"><a class="c0" href="http://geode-docs.cfapps.io/docs/managing/security/authorization_overview.html">more details about authorization</a></span></p> |
| <h2 class="c11"><span>Sample security scenario</span></h2> |
| <p class="c4 c18"><span class="c2">The best way to illustrate authentication and authorization is with an example. In this example, we use a local LDAP server. The picture below shows two (2) sample applications that provide bank account access to employees and customers, respectively. The LDAP service account used by the </span><span class="c3">employee application</span><span class="c2"> can read and update multiple bank accounts (Put, PutAll, Get and Query). The LDAP Service account used by the </span><span class="c3">customer-facing application</span><span class="c2"> can only read and update information of a single bank account (Put and Get)</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/a66df5a0-4c57-48ad-a24c-a9303364ee2f?t" alt="image001.png"></img></p> |
| <p class="c4"><span class="c2">In our example, the cluster hosts two (2) regions: The </span><span class="c3">Account</span><span class="c6"> </span><span class="c2">region is a partitioned region that stores bank account information such as account ID, account number, account type, balance and credit line. The </span><span class="c3">PermissionPerRole</span><span class="c2"> region is a replicated region that stores the roles of each LDAP user for a given Apache Geode region</span></p> |
| <h2 class="c11"><span>Running the sample code</span></h2> |
| <p class="c4"><span class="c16">You can find the</span><span class="c7"><a class="c0" href="https://github.com/Pivotal-Open-Source-Hub/geode-security-samples"> source code of the sample security scenario on this Github repository</a></span><span class="c16"> . The </span><span class="c7"><a class="c0" href="https://github.com/Pivotal-Open-Source-Hub/geode-security-samples/blob/master/README.md">README.MD file</a></span><span class="c16"> contains detailed instructions to build and execute our sample client application with a local Apache Geode cluster and a local LDAP server. </span><span class="c2">Once you have the environment configured, you can execute the sample client application, change to the ‘sample-client-security’ folder and execute this command: </span><span class="c2 c8">java -jar target/sample-client-security-0.1.0.jar</span></p> |
| <p class="c4"><span class="c2">To run the test scenarios using the Customer application’s service account, enter 1. To use the Employee application’s service account, enter 2. This screenshot shows the menu that the sample client application displays.</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/6cf97aa2-20c1-42ad-8656-81e2c9043341" alt="image003.png" width="700" height="300"></img></p> |
| <p class="c4"><span class="c2">When we use the Customer application’s service account to execute a PUT on the Account region, the “server1/server1.log” file of the cluster contains the following ALLOWED log messages:</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/8e4da62d-afb6-49cc-9496-249a8f10ac6b" alt="image005.png" width="700" height="150"></img></p> |
| <p class="c4"><span class="c2">However, when we use the Customer application’s service account to execute a PUT-ALL on the Account region, the “server1/server1.log” file correctly indicates that said service account could not perform the aforementioned operation by displaying a DENIED log message:</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/ad7cc4ff-f9f4-4cf0-b0f1-a21a61fb6d58" alt="image007.png" width="700" height="300"></img></p> |
| <h2 class="c11"><span class="c2">Now let’s walk through our sample authentication and authorization implementations.</span></h2> |
| <h2 class="c11"><span>Implementing Authentication for Apache Geode servers</span></h2> |
| <p class="c4"><span class="c2">Apache Geode has two (2) authentication interfaces that you need to implement: </span><span class="c3">AuthInitialize</span><span class="c2"> and </span><span class="c3">Authenticator </span><span class="c2">which are located in the </span><span class="c2 c8">com.gemstone.gemfire.security</span><span class="c2"> package. Our sample implementations of AuthInitialize and Authenticator are called </span><span class="c3">UserPasswordAuthInit</span><span class="c2"> and </span><span class="c3">LdapUserAuthenticator</span><span class="c2">, respectively. Both classes are part of the </span><span class="c2 c8">org.mycompany.security.samples</span><span class="c2"> package.</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/04404444-ba8d-41fe-bbee-0c0d68214e72" alt="image009.png"></img></p> |
| <p class="c4"><span class="c2">Locators and servers use our sample </span><span class="c2 c8">gemfire-server.properties</span><span class="c2"> file to store any security-related properties. Here is an excerpt of our sample properties file, feel free to change any LDAP-related settings to run this example in your environment:</span></p> |
| <ul class="c1 lst-kix_list_2-0 start"> |
| <li class="c10 c9"><span class="c6">security-ldap-url=</span><span class="c2">ldap://localhost:10389/</span></li> |
| <li class="c10 c9"><span class="c6">security-ldap-basedn=</span><span class="c2">o=sevenSeas</span></li> |
| <li class="c10 c9"><span class="c6">security-ldap-filter=</span><span class="c2">(&(objectClass=inetOrgPerson)(uid={0}))</span></li> |
| <li class="c10 c9"><span class="c6">security-username=</span><span class="c2">geode-system</span></li> |
| <li class="c10 c9"><span class="c6">security-password=</span><span class="c2">pass</span></li> |
| </ul> |
| <p class="c12"><span class="c2">These properties represent the URL of your LDAP server; the search base is the location in the LDAP directory tree from which any LDAP user search begins; the search filter defines LDAP user search criteria. Last but not least, both username and password to be used to join the cluster.</span></p> |
| <p class="c4"><span class="c2">The properties file also specifies the fully qualified names of our sample implementations.</span></p> |
| <ul class="c1 lst-kix_list_3-0 start"> |
| <li class="c10 c9"><span class="c6">security-peer-auth-init</span><span class="c2">=org.mycompany.security.samples.UserPasswordAuthInit.create</span></li> |
| <li class="c10 c9"><span class="c6">security-peer-authenticator</span><span class="c2">=org.mycompany.security.samples.LdapUserAuthenticator.create</span></li> |
| </ul> |
| <p class="c4"><span class="c2">The </span><span class="c2 c8">security-peer-auth-init</span><span class="c2"> property should be set to the name of a zero-argument static method that returns an AuthInitialize object on the members while the </span><span class="c2 c8">security-peer-authenticator</span><span class="c2"> property should be set to the name of a zero-argument static method that returns an Authenticator object on the members and locators. You can find the source code of </span><span class="c7"><a class="c0" href="https://github.com/Pivotal-Open-Source-Hub/geode-security-samples/blob/master/sample-data-grid-security/src/main/java/org/mycompany/security/samples/UserPasswordAuthInit.java">UserPasswordAuthInit</a></span><span class="c2"> and </span><span class="c7"><a class="c0" href="https://github.com/Pivotal-Open-Source-Hub/geode-security-samples/blob/master/sample-data-grid-security/src/main/java/org/mycompany/security/samples/LdapUserAuthenticator.java">LdapUserAuthenticator</a></span><span class="c2"> implementation classes on Github.</span></p> |
| <h2 class="c11"><span>Implementing Authentication for Apache Geode clients</span></h2> |
| <p class="c4"><span class="c2">To enable client authentication, we need to configure both cluster members and the client application.</span></p> |
| <p class="c4"><span class="c3">Cluster configuration</span><span class="c2">: To configure the cluster, we need to add this entry to our properties file:</span></p> |
| <ul class="c1 lst-kix_list_5-0 start"> |
| <li class="c10 c18 c9"><span class="c6">security-client-authenticator</span><span class="c2">=org.mycompany.security.samples.LdapUserAuthenticator.create</span></li> |
| </ul> |
| <p class="c4 c13"><span class="c2">The </span><span class="c2 c8">security-client-authenticator</span><span class="c2"> property should be set to the name of a zero-argument static method that returns an Authenticator object on all the servers.</span></p> |
| <p class="c4"><span class="c3">Client application configuration</span><span class="c2">: the settings required for the client application are described below.</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/96e9e3c3-a6b5-49af-ab68-b10598662a48" alt="image011.png" width="700" height="300"></img></p> |
| <p class="c4 c13"><span class="c2">The </span><span class="c2 c8">security-client-auth-init</span><span class="c2"> property should be set to the name of a zero-argument static method that returns an AuthInitialize object on all the clients. We also set both username and password to be used by client applications to authenticate with the cluster.</span></p> |
| <p class="c4"><span class="c2">It is important to note that, in our example, we are using the same </span><span class="c7"><a class="c0" href="https://github.com/Pivotal-Open-Source-Hub/geode-security-samples/blob/master/sample-data-grid-security/src/main/java/org/mycompany/security/samples/UserPasswordAuthInit.java">UserPasswordAuthInit</a></span><span class="c2"> class to obtain service accounts of client applications and servers.</span></p> |
| <h2 class="c11"><span>Implementing Authorization</span></h2> |
| <p class="c4"><span class="c2">There is an authorization interface that you need to implement: </span><span class="c3">AccessControl</span><span class="c2">, which is part of the </span><span class="c2 c8">com.gemstone.gemfire.security</span><span class="c2"> package. Our sample implementation of AccessControl is called </span><span class="c3">PrePostAuthorization </span><span class="c2">as described in below diagram. This class is part of the </span><span class="c2 c8">org.mycompany.security.samples</span><span class="c2"> package.</span></p> |
| <p><img src="https://blogs.apache.org/geode/mediaresource/715307e5-8ca6-4403-9634-b02447e2c1a2" alt="image013.png"></img></p> |
| <p class="c12"><span class="c2">To enable cluster authorization, we need to add these two (2) entries to our cluster’s properties file:</span></p> |
| <ul class="c1 lst-kix_list_5-0"> |
| <li class="c10 c9"><span class="c6">security-client-accessor</span><span class="c2">=org.mycompany.security.samples.PrePostAuthorization.create</span></li> |
| <li class="c10 c9"><span class="c6">security-client-accessor-pp</span><span class="c2">=org.mycompany.security.samples.PrePostAuthorization.create</span></li> |
| </ul> |
| <p class="c4 c13"><span class="c2">For pre-operation calls, set </span><span class="c2 c8">security-client-accessor</span><span class="c2"> to the fully qualified name of the static method you programmed to return an instance of the class. For post-operation calls, set </span><span class="c2 c8">security-client-accessor-pp</span><span class="c2"> to the fully qualified name of the static method you programmed to return an instance of the class. You can find the source code of the </span><span class="c7"><a class="c0" href="https://github.com/Pivotal-Open-Source-Hub/geode-security-samples/blob/master/sample-data-grid-security/src/main/java/org/mycompany/security/samples/PrePostAuthorization.java">PrePostAuthorization class</a></span><span class="c2"> on Github.</span></p> |
| <h2 class="c11"><a name="h.30j0zll"></a><span>Summary</span></h2> |
| <p class="c4"><span class="c2">Now you know the mechanisms to enable system-level authentication and authorization of a Apache Geode cluster. It is important to point out that Apache Geode is very flexible and allows you to configure system users and their corresponding roles and permissions based on your security policy and technology. We find that most enterprise customers typically have a common infrastructure such as single sign-on or centralized authentication systems they need to integrate with. You can join Apache Geode project right now and start reaping the benefits of using a powerful distributed in-memory database that provides applications ultra-low latency access to terabytes of operational data at a massive scale, in a secure manner.</span></p> |
| <p></body></html></p> |
