| <!DOCTYPE html> |
| <html lang="en"><head> |
| <meta charset="utf-8"> |
| <meta http-equiv="X-UA-Compatible" content="IE=edge"> |
| <meta name="viewport" content="width=device-width, initial-scale=1"><!-- Begin Jekyll SEO tag v2.8.0 --> |
| <title>Securing Apache Geode With Your Corporate LDAP | Blogs Archive</title> |
| <meta name="generator" content="Jekyll v3.9.3" /> |
| <meta property="og:title" content="Securing Apache Geode With Your Corporate LDAP" /> |
| <meta property="og:locale" content="en_US" /> |
| <meta name="description" content="This is a guest blog post written by Apache Geode contributor Guillermo Tantachuco To protect your data and to mitigate threats such as spoofing, information disclosure, replay attacks and elevation of privileges, Apache Geode (incubating) provides mature security features such as authentication, authorization and SSL communication that have consistently addressed customer’s security requirements for over a decade. 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. Apache Geode provides two (2) types of authentication: Cache server authentication 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 Client authentication 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 To protect the membership coordinator, it is important to point out that you should always run the Geode cluster in a secure environment. 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 more details about authentication The authorization 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: Pre-operation: you can program the authorization callback to do something before the operation is executed Post-operation: 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 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 more details about authorization Sample security scenario 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 employee application can read and update multiple bank accounts (Put, PutAll, Get and Query). The LDAP Service account used by the customer-facing application can only read and update information of a single bank account (Put and Get) </img> In our example, the cluster hosts two (2) regions: The Account region is a partitioned region that stores bank account information such as account ID, account number, account type, balance and credit line. The PermissionPerRole region is a replicated region that stores the roles of each LDAP user for a given Apache Geode region Running the sample code You can find the source code of the sample security scenario on this Github repository . The README.MD file contains detailed instructions to build and execute our sample client application with a local Apache Geode cluster and a local LDAP server. Once you have the environment configured, you can execute the sample client application, change to the ‘sample-client-security’ folder and execute this command: java -jar target/sample-client-security-0.1.0.jar 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. </img> 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: </img> 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: </img> Now let’s walk through our sample authentication and authorization implementations. Implementing Authentication for Apache Geode servers Apache Geode has two (2) authentication interfaces that you need to implement: AuthInitialize and Authenticator which are located in the com.gemstone.gemfire.security package. Our sample implementations of AuthInitialize and Authenticator are called UserPasswordAuthInit and LdapUserAuthenticator, respectively. Both classes are part of the org.mycompany.security.samples package. </img> Locators and servers use our sample gemfire-server.properties 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: security-ldap-url=ldap://localhost:10389/ security-ldap-basedn=o=sevenSeas security-ldap-filter=(&(objectClass=inetOrgPerson)(uid={0})) security-username=geode-system security-password=pass 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. The properties file also specifies the fully qualified names of our sample implementations. security-peer-auth-init=org.mycompany.security.samples.UserPasswordAuthInit.create security-peer-authenticator=org.mycompany.security.samples.LdapUserAuthenticator.create The security-peer-auth-init property should be set to the name of a zero-argument static method that returns an AuthInitialize object on the members while the security-peer-authenticator 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 UserPasswordAuthInit and LdapUserAuthenticator implementation classes on Github. Implementing Authentication for Apache Geode clients To enable client authentication, we need to configure both cluster members and the client application. Cluster configuration: To configure the cluster, we need to add this entry to our properties file: security-client-authenticator=org.mycompany.security.samples.LdapUserAuthenticator.create The security-client-authenticator property should be set to the name of a zero-argument static method that returns an Authenticator object on all the servers. Client application configuration: the settings required for the client application are described below. </img> The security-client-auth-init 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. It is important to note that, in our example, we are using the same UserPasswordAuthInit class to obtain service accounts of client applications and servers. Implementing Authorization There is an authorization interface that you need to implement: AccessControl, which is part of the com.gemstone.gemfire.security package. Our sample implementation of AccessControl is called PrePostAuthorization as described in below diagram. This class is part of the org.mycompany.security.samples package. </img> To enable cluster authorization, we need to add these two (2) entries to our cluster’s properties file: security-client-accessor=org.mycompany.security.samples.PrePostAuthorization.create security-client-accessor-pp=org.mycompany.security.samples.PrePostAuthorization.create For pre-operation calls, set security-client-accessor to the fully qualified name of the static method you programmed to return an instance of the class. For post-operation calls, set security-client-accessor-pp 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 PrePostAuthorization class on Github. Summary 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. </body></html>" /> |
| <meta property="og:description" content="This is a guest blog post written by Apache Geode contributor Guillermo Tantachuco To protect your data and to mitigate threats such as spoofing, information disclosure, replay attacks and elevation of privileges, Apache Geode (incubating) provides mature security features such as authentication, authorization and SSL communication that have consistently addressed customer’s security requirements for over a decade. 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. Apache Geode provides two (2) types of authentication: Cache server authentication 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 Client authentication 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 To protect the membership coordinator, it is important to point out that you should always run the Geode cluster in a secure environment. 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 more details about authentication The authorization 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: Pre-operation: you can program the authorization callback to do something before the operation is executed Post-operation: 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 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 more details about authorization Sample security scenario 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 employee application can read and update multiple bank accounts (Put, PutAll, Get and Query). The LDAP Service account used by the customer-facing application can only read and update information of a single bank account (Put and Get) </img> In our example, the cluster hosts two (2) regions: The Account region is a partitioned region that stores bank account information such as account ID, account number, account type, balance and credit line. The PermissionPerRole region is a replicated region that stores the roles of each LDAP user for a given Apache Geode region Running the sample code You can find the source code of the sample security scenario on this Github repository . The README.MD file contains detailed instructions to build and execute our sample client application with a local Apache Geode cluster and a local LDAP server. Once you have the environment configured, you can execute the sample client application, change to the ‘sample-client-security’ folder and execute this command: java -jar target/sample-client-security-0.1.0.jar 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. </img> 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: </img> 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: </img> Now let’s walk through our sample authentication and authorization implementations. Implementing Authentication for Apache Geode servers Apache Geode has two (2) authentication interfaces that you need to implement: AuthInitialize and Authenticator which are located in the com.gemstone.gemfire.security package. Our sample implementations of AuthInitialize and Authenticator are called UserPasswordAuthInit and LdapUserAuthenticator, respectively. Both classes are part of the org.mycompany.security.samples package. </img> Locators and servers use our sample gemfire-server.properties 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: security-ldap-url=ldap://localhost:10389/ security-ldap-basedn=o=sevenSeas security-ldap-filter=(&(objectClass=inetOrgPerson)(uid={0})) security-username=geode-system security-password=pass 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. The properties file also specifies the fully qualified names of our sample implementations. security-peer-auth-init=org.mycompany.security.samples.UserPasswordAuthInit.create security-peer-authenticator=org.mycompany.security.samples.LdapUserAuthenticator.create The security-peer-auth-init property should be set to the name of a zero-argument static method that returns an AuthInitialize object on the members while the security-peer-authenticator 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 UserPasswordAuthInit and LdapUserAuthenticator implementation classes on Github. Implementing Authentication for Apache Geode clients To enable client authentication, we need to configure both cluster members and the client application. Cluster configuration: To configure the cluster, we need to add this entry to our properties file: security-client-authenticator=org.mycompany.security.samples.LdapUserAuthenticator.create The security-client-authenticator property should be set to the name of a zero-argument static method that returns an Authenticator object on all the servers. Client application configuration: the settings required for the client application are described below. </img> The security-client-auth-init 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. It is important to note that, in our example, we are using the same UserPasswordAuthInit class to obtain service accounts of client applications and servers. Implementing Authorization There is an authorization interface that you need to implement: AccessControl, which is part of the com.gemstone.gemfire.security package. Our sample implementation of AccessControl is called PrePostAuthorization as described in below diagram. This class is part of the org.mycompany.security.samples package. </img> To enable cluster authorization, we need to add these two (2) entries to our cluster’s properties file: security-client-accessor=org.mycompany.security.samples.PrePostAuthorization.create security-client-accessor-pp=org.mycompany.security.samples.PrePostAuthorization.create For pre-operation calls, set security-client-accessor to the fully qualified name of the static method you programmed to return an instance of the class. For post-operation calls, set security-client-accessor-pp 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 PrePostAuthorization class on Github. Summary 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. </body></html>" /> |
| <link rel="canonical" href="http://localhost:4000/geode/entry/securing_apache_geode_with_your" /> |
| <meta property="og:url" content="http://localhost:4000/geode/entry/securing_apache_geode_with_your" /> |
| <meta property="og:site_name" content="Blogs Archive" /> |
| <meta property="og:type" content="article" /> |
| <meta property="article:published_time" content="2015-07-29T18:10:27-04:00" /> |
| <meta name="twitter:card" content="summary" /> |
| <meta property="twitter:title" content="Securing Apache Geode With Your Corporate LDAP" /> |
| <script type="application/ld+json"> |
| {"@context":"https://schema.org","@type":"BlogPosting","dateModified":"2015-07-29T18:10:27-04:00","datePublished":"2015-07-29T18:10:27-04:00","description":"This is a guest blog post written by Apache Geode contributor Guillermo Tantachuco To protect your data and to mitigate threats such as spoofing, information disclosure, replay attacks and elevation of privileges, Apache Geode (incubating) provides mature security features such as authentication, authorization and SSL communication that have consistently addressed customer’s security requirements for over a decade. 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. Apache Geode provides two (2) types of authentication: Cache server authentication 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 Client authentication 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 To protect the membership coordinator, it is important to point out that you should always run the Geode cluster in a secure environment. 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 more details about authentication The authorization 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: Pre-operation: you can program the authorization callback to do something before the operation is executed Post-operation: 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 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 more details about authorization Sample security scenario 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 employee application can read and update multiple bank accounts (Put, PutAll, Get and Query). The LDAP Service account used by the customer-facing application can only read and update information of a single bank account (Put and Get) </img> In our example, the cluster hosts two (2) regions: The Account region is a partitioned region that stores bank account information such as account ID, account number, account type, balance and credit line. The PermissionPerRole region is a replicated region that stores the roles of each LDAP user for a given Apache Geode region Running the sample code You can find the source code of the sample security scenario on this Github repository . The README.MD file contains detailed instructions to build and execute our sample client application with a local Apache Geode cluster and a local LDAP server. Once you have the environment configured, you can execute the sample client application, change to the ‘sample-client-security’ folder and execute this command: java -jar target/sample-client-security-0.1.0.jar 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. </img> 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: </img> 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: </img> Now let’s walk through our sample authentication and authorization implementations. Implementing Authentication for Apache Geode servers Apache Geode has two (2) authentication interfaces that you need to implement: AuthInitialize and Authenticator which are located in the com.gemstone.gemfire.security package. Our sample implementations of AuthInitialize and Authenticator are called UserPasswordAuthInit and LdapUserAuthenticator, respectively. Both classes are part of the org.mycompany.security.samples package. </img> Locators and servers use our sample gemfire-server.properties 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: security-ldap-url=ldap://localhost:10389/ security-ldap-basedn=o=sevenSeas security-ldap-filter=(&(objectClass=inetOrgPerson)(uid={0})) security-username=geode-system security-password=pass 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. The properties file also specifies the fully qualified names of our sample implementations. security-peer-auth-init=org.mycompany.security.samples.UserPasswordAuthInit.create security-peer-authenticator=org.mycompany.security.samples.LdapUserAuthenticator.create The security-peer-auth-init property should be set to the name of a zero-argument static method that returns an AuthInitialize object on the members while the security-peer-authenticator 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 UserPasswordAuthInit and LdapUserAuthenticator implementation classes on Github. Implementing Authentication for Apache Geode clients To enable client authentication, we need to configure both cluster members and the client application. Cluster configuration: To configure the cluster, we need to add this entry to our properties file: security-client-authenticator=org.mycompany.security.samples.LdapUserAuthenticator.create The security-client-authenticator property should be set to the name of a zero-argument static method that returns an Authenticator object on all the servers. Client application configuration: the settings required for the client application are described below. </img> The security-client-auth-init 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. It is important to note that, in our example, we are using the same UserPasswordAuthInit class to obtain service accounts of client applications and servers. Implementing Authorization There is an authorization interface that you need to implement: AccessControl, which is part of the com.gemstone.gemfire.security package. Our sample implementation of AccessControl is called PrePostAuthorization as described in below diagram. This class is part of the org.mycompany.security.samples package. </img> To enable cluster authorization, we need to add these two (2) entries to our cluster’s properties file: security-client-accessor=org.mycompany.security.samples.PrePostAuthorization.create security-client-accessor-pp=org.mycompany.security.samples.PrePostAuthorization.create For pre-operation calls, set security-client-accessor to the fully qualified name of the static method you programmed to return an instance of the class. For post-operation calls, set security-client-accessor-pp 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 PrePostAuthorization class on Github. Summary 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. </body></html>","headline":"Securing Apache Geode With Your Corporate LDAP","mainEntityOfPage":{"@type":"WebPage","@id":"http://localhost:4000/geode/entry/securing_apache_geode_with_your"},"url":"http://localhost:4000/geode/entry/securing_apache_geode_with_your"}</script> |
| <!-- End Jekyll SEO tag --> |
| <link rel="stylesheet" href="/assets/main.css"><link type="application/atom+xml" rel="alternate" href="http://localhost:4000/feed.xml" title="Blogs Archive" /></head> |
| <body><header class="site-header" role="banner"> |
| |
| <div class="wrapper"><a class="site-title" rel="author" href="/">Blogs Archive</a><nav class="site-nav"> |
| <input type="checkbox" id="nav-trigger" class="nav-trigger" /> |
| <label for="nav-trigger"> |
| <span class="menu-icon"> |
| <svg viewBox="0 0 18 15" width="18px" height="15px"> |
| <path d="M18,1.484c0,0.82-0.665,1.484-1.484,1.484H1.484C0.665,2.969,0,2.304,0,1.484l0,0C0,0.665,0.665,0,1.484,0 h15.032C17.335,0,18,0.665,18,1.484L18,1.484z M18,7.516C18,8.335,17.335,9,16.516,9H1.484C0.665,9,0,8.335,0,7.516l0,0 c0-0.82,0.665-1.484,1.484-1.484h15.032C17.335,6.031,18,6.696,18,7.516L18,7.516z M18,13.516C18,14.335,17.335,15,16.516,15H1.484 C0.665,15,0,14.335,0,13.516l0,0c0-0.82,0.665-1.483,1.484-1.483h15.032C17.335,12.031,18,12.695,18,13.516L18,13.516z"/> |
| </svg> |
| </span> |
| </label> |
| |
| <div class="trigger"><a class="page-link" href="/about/">About</a></div> |
| </nav></div> |
| </header> |
| <main class="page-content" aria-label="Content"> |
| <div class="wrapper"> |
| <article class="post h-entry" itemscope itemtype="http://schema.org/BlogPosting"> |
| |
| <header class="post-header"> |
| <h1 class="post-title p-name" itemprop="name headline">Securing Apache Geode With Your Corporate LDAP</h1> |
| <p class="post-meta"> |
| <time class="dt-published" datetime="2015-07-29T18:10:27-04:00" itemprop="datePublished">Jul 29, 2015 |
| </time>• <span itemprop="author" itemscope itemtype="http://schema.org/Person"><span class="p-author h-card" itemprop="name">{"display_name"=>"Gregory Chase ", "login"=>"gregchase", "email"=>"gregchase@apache.org"}</span></span></p> |
| </header> |
| |
| <div class="post-content e-content" itemprop="articleBody"> |
| <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> |
| |
| </div><a class="u-url" href="/geode/entry/securing_apache_geode_with_your" hidden></a> |
| </article> |
| |
| </div> |
| </main><footer class="site-footer h-card"> |
| <data class="u-url" href="/"></data> |
| |
| <div class="wrapper"> |
| |
| <h2 class="footer-heading">Blogs Archive</h2> |
| |
| <div class="footer-col-wrapper"> |
| <div class="footer-col footer-col-1"> |
| <ul class="contact-list"> |
| <li class="p-name">Blogs Archive</li><li><a class="u-email" href="mailto:issues@infra.apache.org">issues@infra.apache.org</a></li></ul> |
| </div> |
| |
| <div class="footer-col footer-col-2"><ul class="social-media-list"><li><a href="https://github.com/jekyll"><svg class="svg-icon"><use xlink:href="/assets/minima-social-icons.svg#github"></use></svg> <span class="username">jekyll</span></a></li><li><a href="https://www.twitter.com/jekyllrb"><svg class="svg-icon"><use xlink:href="/assets/minima-social-icons.svg#twitter"></use></svg> <span class="username">jekyllrb</span></a></li></ul> |
| </div> |
| |
| <div class="footer-col footer-col-3"> |
| <p>This is an archive of the Roller blogs that were previously hosted on blogs.apache.org</p> |
| </div> |
| </div> |
| |
| </div> |
| |
| </footer> |
| </body> |
| |
| </html> |
