http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/network_partitioning/network_partitioning_scenarios.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/network_partitioning/network_partitioning_scenarios.html.md.erb b/geode-docs/managing/network_partitioning/network_partitioning_scenarios.html.md.erb deleted file mode 100644 index a90b3f1..0000000 --- a/geode-docs/managing/network_partitioning/network_partitioning_scenarios.html.md.erb +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Network Partitioning Scenarios ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -This topic describes network partitioning scenarios and what happens to the partitioned sides of the distributed system. - -<img src="../../images_svg/network_partition_scenario.svg" id="concept_357ABE91AAA042D2A20328BD01FEB882__image_6ED88C6911EE4C68A19353ABD7B1552A" class="image" /> - -## <a id="concept_357ABE91AAA042D2A20328BD01FEB882__section_DAFBCB8BB421453EB6C5B4A348640762" class="no-quick-link"></a>What the Losing Side Does - -In a network partitioning scenario, the "losing side" constitutes the cluster partition where the membership coordinator has detected that there is an insufficient quorum of members to continue. - -The membership coordinator calculates membership weight change after sending out its view preparation message. If a quorum of members does not remain after the view preparation phase, the coordinator on the "losing side" declares a network partition event and sends a network-partition-detected UDP message to the members. The coordinator then closes its distributed system with a `ForcedDisconnectException`. If a member fails to receive the message before the coordinator closes the connection, it is responsible for detecting the event on its own. - -When the losing side discovers that a network partition event has occurred, all peer members receive a `RegionDestroyedException` with `Operation`: `FORCED_DISCONNECT`. - -If a `CacheListener` is installed, the `afterRegionDestroy` callback is invoked with a `RegionDestroyedEvent`, as shown in this example logged by the losing side's callback. The peer member process IDs are 14291 (lead member) and 14296, and the locator is 14289. - -``` pre -[info 2008/05/01 11:14:51.853 PDT <CloserThread> tid=0x4a] -Invoked splitBrain.SBListener: afterRegionDestroy in client1 whereIWasRegistered: 14291 -event.isReinitializing(): false -event.getDistributedMember(): thor(14291):40440/34132 -event.getCallbackArgument(): null -event.getRegion(): /TestRegion -event.isOriginRemote(): false -Operation: FORCED_DISCONNECT -Operation.isDistributed(): false -Operation.isExpiration(): false -``` - -Peers still actively performing operations on the cache may see `ShutdownException`s or `CacheClosedException`s with `Caused by: ForcedDisconnectException`. - -## <a id="concept_357ABE91AAA042D2A20328BD01FEB882__section_E6E914107FE64C0F9D8F7DA142D00AD7" class="no-quick-link"></a>What Isolated Members Do - -When a member is isolated from all locators, it is unable to receive membership view changes. It can't know if the current coordinator is present or, if it has left, whether there are other members available to take over that role. In this condition, a member will eventually detect the loss of all other members and will use the loss threshold to determine whether it should shut itself down. In the case of a distributed system with 2 locators and 2 cache servers, the loss of communication with the non-lead cache server plus both locators would result in this situation and the remaining cache server would eventually shut itself down.
http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/network_partitioning/preventing_network_partitions.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/network_partitioning/preventing_network_partitions.html.md.erb b/geode-docs/managing/network_partitioning/preventing_network_partitions.html.md.erb deleted file mode 100644 index 6a983f5..0000000 --- a/geode-docs/managing/network_partitioning/preventing_network_partitions.html.md.erb +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Preventing Network Partitions ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -This section provides a short list of things you can do to prevent a network partition from occurring. - -To avoid a network partition: - -- Use NIC teaming for redundant connectivity. See [http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.html#wp696452](http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.html#wp696452) for more information. -- It is best if all servers share a common network switch. Having multiple network switches increases the possibility of a network partition occurring. If multiple switches must be used, redundant routing paths should be available, if possible. The weight of members sharing a switch in a multi-switch configuration will determine which partition survives if there is an inter-switch failure. -- In terms of Geode configuration, consider the weighting of members. For example, you could assign important processes a higher weight. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/region_compression/region_compression.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/region_compression/region_compression.html.md.erb b/geode-docs/managing/region_compression/region_compression.html.md.erb deleted file mode 100644 index c85d1e1..0000000 --- a/geode-docs/managing/region_compression/region_compression.html.md.erb +++ /dev/null @@ -1,226 +0,0 @@ ---- -title: Region Compression ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> -<a id="topic_r43_wgc_gl"></a> - - -This section describes region compression, its benefits and usage. - -One way to reduce memory consumption by Geode is to enable compression in your regions. Geode allows you to compress in-memory region values using pluggable compressors (compression codecs). Geode includes the [Snappy](http://google.github.io/snappy/) compressor as the built-in compression codec; however, you can implement and specify a different compressor for each compressed region. - -## What Gets Compressed - -When you enable compression in a region, all values stored in the region are compressed while in memory. Keys and indexes are not compressed. New values are compressed when put into the in-memory cache and all values are decompressed when being read from the cache. Values are not compressed when persisted to disk. Values are decompressed before being sent over the wire to other peer members or clients. - -When compression is enabled, each value in the region is compressed, and each region entry is compressed as a single unit. It is not possible to compress individual fields of an entry. - -You can have a mix of compressed and non-compressed regions in the same cache. - -- **[Guidelines on Using Compression](#concept_a2c_rhc_gl)** - - This topic describes factors to consider when deciding on whether to use compression. - -- **[How to Enable Compression in a Region](#topic_inm_whc_gl)** - - This topic describes how to enable compression on your region. - -- **[Working with Compressors](#topic_hqf_syj_g4)** - - When using region compression, you can use the default Snappy compressor included with Geode or you can specify your own compressor. - -- **[Comparing Performance of Compressed and Non-Compressed Regions](#topic_omw_j3c_gl)** - - The comparative performance of compressed regions versus non-compressed regions can vary depending on how the region is being used and whether the region is hosted in a memory-bound JVM. - -## <a id="concept_a2c_rhc_gl" class="no-quick-link"></a>Guidelines on Using Compression - -This topic describes factors to consider when deciding on whether to use compression. - -Review the following guidelines when deciding on whether or not to enable compression in your region: - -- **Use compression when JVM memory usage is too high.** Compression allows you to store more region data in-memory and to reduce the number of expensive garbage collection cycles that prevent JVMs from running out of memory when memory usage is high. - - To determine if JVM memory usage is high, examine the the following statistics: - - - vmStats>freeMemory - - vmStats->maxMemory - - ConcurrentMarkSweep->collectionTime - - If the amount of free memory regularly drops below 20% - 25% or the duration of the garbage collection cycles is generally on the high side, then the regions hosted on that JVM are good candidates for having compression enabled. - -- **Consider the types and lengths of the fields in the region's entries.** Since compression is performed on each entry separately (and not on the region as a whole), consider the potential for duplicate data across a single entry. Duplicate bytes are compressed more easily. Also, since region entries are first serialized into a byte area before being compressed, how well the data might compress is determined by the number and length of duplicate bytes across the entire entry and not just a single field. Finally, the larger the entry the more likely compression will achieve good results as the potential for duplicate bytes, and a series of duplicate bytes, increases. -- **Consider the type of data you wish to compress.** The type of data stored has a significant impact on how well the data may compress. String data will generally compress better than numeric data simply because string bytes are far more likely to repeat; however, that may not always be the case. For example, a region entry that holds a couple of short, unique strings may not provide as much memory savings when compressed as another region entry that holds a large number of integer values. In short, when evaluating the potential gains of compressing a region, consider the likelihood of having duplicate bytes, and more importantly the length of a series of duplicate bytes, for a single, serialized region entry. In addition, data that has already been compressed, such as JPEG format files, can actually cause more memory to be used. -- **Compress if you are storing large text values.** Compression is beneficial if you are storing large text values (such as JSON or XML) or blobs in Geode that would benefit from compression. -- **Consider whether fields being queried against are indexed.** You can query against compressed regions; however, if the fields you are querying against have not been indexed, then the fields must be decompressed before they can be used for comparison. In short, you may incur some query performance costs when querying against non-indexed fields. -- **Objects stored in the compression region must be serializable.** Compression only operates on byte arrays, therefore objects being stored in a compressed region must be serializable and deserializable. The objects can either implement the Serializable interface or use one of the other Geode serialization mechanisms (such as PdxSerializable). Implementers should always be aware that when compression is enabled the instance of an object put into a region will not be the same instance when taken out. Therefore, transient attributes will lose their value when the containing object is put into and then taken out of a region. - -- **Compressed regions will enable cloning by default.** Setting a compressor and then disabling cloning results in an exception. The options are incompatible because the process of compressing/serializing and then decompressing/deserializing will result in a different instance of the object being created and that may be interpreted as cloning the object. - -<a id="topic_inm_whc_gl"></a> - -## <a id="topic_inm_whc_gl" class="no-quick-link"></a>How to Enable Compression in a Region - -This topic describes how to enable compression on your region. - -To enable compression on your region, set the following region attribute in your cache.xml: - -``` pre -<?xml version="1.0" encoding= "UTF-8"?> -<cache xmlns="http://geode.incubator.apache.org/schema/cache"; - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; - xsi:schemaLocation="http://geode.incubator.apache.org/schema/cache http://geode.incubator.apache.org/schema/cache/cache-1.0.xsd"; - version="1.0â lock-lease="120" lock-timeout= "60" search-timeout= "300" is-server= "true" copy-on-read= "false" > - <region name="compressedRegion" > - <region-attributes data-policy="replicate" ... /> - <Compressor> - <class-name>org.apache.geode.compression.SnappyCompressor</class-name> - </Compressor> - ... - </region-attributes> - </region> -</cache> -``` - -In the Compressor element, specify the class-name for your compressor implementation. This example specifies the Snappy compressor, which is bundled with Geode . You can also specify a custom compressor. See [Working with Compressors](#topic_hqf_syj_g4) for an example. - -Compression can be enabled during region creation using gfsh or programmatically as well. - -Using gfsh: - -``` pre -gfsh>create-region --name=âCompressedRegionâ --compressor=âorg.apache.geode.compression.SnappyCompressorâ; -``` - -API: - -``` pre -regionFactory.setCompressor(new SnappyCompressor()); -``` - -or - -``` pre -regionFactory.setCompressor(SnappyCompressor.getDefaultInstance()); -``` - -## How to Check Whether Compression is Enabled - -You can also check whether a region has compression enabled by querying which codec is being used. A null codec indicates that no compression is enabled for the region. - -``` pre -Region myRegion = cache.getRegion("myRegion"); -Compressor compressor = myRegion.getAttributes().getCompressor(); -``` - -## <a id="topic_hqf_syj_g4" class="no-quick-link"></a>Working with Compressors - -When using region compression, you can use the default Snappy compressor included with Geode or you can specify your own compressor. - -The compression API consists of a single interface that compression providers must implement. The default compressor (SnappyCompressor) is the single compression implementation that comes bundled with the product. Note that since the Compressor is stateless, there only needs to be a single instance in any JVM; however, multiple instances may be used without issue. The single, default instance of the SnappyCompressor may be retrieved with the `SnappyCompressor.getDefaultInstance()` static method. - -**Note:** -The Snappy codec included with Geode cannot be used with Solaris deployments. Snappy is only supported on Linux, Windows, and OSX deployments of Geode. - -This example provides a custom Compressor implementation: - -``` pre -package com.mybiz.myproduct.compression; - -import org.apache.geode.compression.Compressor; - -public class LZWCompressor implements Compressor { - private final LZWCodec lzwCodec = new LZWCodec(); - - @Override - public byte[] compress(byte[] input) { - return lzwCodec.compress(input); - } - - @Override - public byte[] decompress(byte[] input) { - return lzwCodec.decompress(input); - } -} -``` - -To use the new custom compressor on a region: - -1. Make sure that the new compressor package is available in the classpath of all JVMs that will host the region. -2. Configure the custom compressor for the region using any of the following mechanisms: - - Using gfsh: - - ``` pre - gfsh>create-region --name=âCompressedRegionâ \ - --compressor=âcom.mybiz.myproduct.compression.LZWCompressorâ - ``` - - Using API: - - For example: - - ``` pre - regionFactory.setCompressor(new LZWCompressor()); - ``` - - cache.xml: - - ``` pre - <region-attributes> - <Compressor> - <class-name>com.mybiz.myproduct.compression.LZWCompressor</class-name> - </Compressor> - </region-attributes> - ``` - -## Changing the Compressor for an Already Compressed Region - -You typically enable compression on a region at the time of region creation. You cannot modify the Compressor or disable compression for the region while the region is online. - -However, if you need to change the compressor or disable compression, you can do so by performing the following steps: - -1. Shut down the members hosting the region you wish to modify. -2. Modify the cache.xml file for the member either specifying a new compressor or removing the compressor attribute from the region. -3. Restart the member. - -## <a id="topic_omw_j3c_gl" class="no-quick-link"></a>Comparing Performance of Compressed and Non-Compressed Regions - -The comparative performance of compressed regions versus non-compressed regions can vary depending on how the region is being used and whether the region is hosted in a memory-bound JVM. - -When considering the cost of enabling compression, you should consider the relative cost of reading and writing compressed data as well as the cost of compression as a percentage of the total time spent managing entries in a region. As a general rule, enabling compression on a region will add 30% - 60% more overhead for region create and update operations than for region get operations. Because of this, enabling compression will create more overhead on regions that are write heavy than on regions that are read heavy. - -However, when attempting to evaluate the performance cost of enabling compression you should also consider the cost of compression relative to the overall cost of managing entries in a region. A region may be tuned in such a way that it is highly optimized for read and/or write performance. For example, a replicated region that does not save to disk will have much better read and write performance than a partitioned region that does save to disk. Enabling compression on a region that has been optimized for read and write performance will provide more noticeable results than using compression on regions that have not been optimized this way. More concretely, performance may degrade by several hundred percent on a read/write optimized region whereas it may only degrade by 5 to 10 percent on a non-optimized region. - -A final note on performance relates to the cost when enabling compression on regions in a memory bound JVM. Enabling compression generally assumes that the enclosing JVM is memory bound and therefore spends a lot of time for garbage collection. In that case performance may improve by as much as several hundred percent as the JVM will be running far fewer garbage collection cycles and spending less time when running a cycle. - -## Monitoring Compression Performance - -The following statistics provide monitoring for cache compression: - -- `compressTime` -- `decompressTime` -- `compressions` -- `decompressions` -- `preCompressedBytes` -- `postCompressedBytes` - -See [Cache Performance (CachePerfStats)](../../reference/statistics/statistics_list.html#section_DEF8D3644D3246AB8F06FE09A37DC5C8) for statistic descriptions. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/authentication_examples.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/authentication_examples.html.md.erb b/geode-docs/managing/security/authentication_examples.html.md.erb deleted file mode 100644 index b7634c8..0000000 --- a/geode-docs/managing/security/authentication_examples.html.md.erb +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Authentication Example ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -This example demonstrates the basics of an implementation of the -`SecurityManager.authenticate` method. -The remainder of the example may be found within the Apache Geode -source code within the -`geode-core/src/main/java/org/apache/geode/security/templates` directory. - -Of course, the security implementation of every installation is unique, -so this example cannot be used in a production environment. -Its use of the user name as a returned principal upon successful -authentication is a particularly poor design choice, -as any attacker that discovers the implementation can potentially -spoof the system. - -This example assumes that a set of user name and password pairs -representing users that may be successfully authenticated -has been read into a data structure upon intialization. -Any component that presents the correct password for a user name -successfully authenticates, -and its identity is verified as that user. -Therefore, the implementation of the `authenticate` method -checks that the user name provided within the `credentials` parameter - is in its data structure. -If the user name is present, -then the password provided within the `credentials` parameter -is compared to the data structure's known password for that user name. -Upon a match, the authentication is successful. - -``` pre -public Object authenticate(final Properties credentials) - throws AuthenticationFailedException { - String user = credentials.getProperty(ResourceConstants.USER_NAME); - String password = credentials.getProperty(ResourceConstants.PASSWORD); - - User userObj = this.userNameToUser.get(user); - if (userObj == null) { - throw new AuthenticationFailedException( - "SampleSecurityManager: wrong username/password"); - } - - if (user != null - && !userObj.password.equals(password) - && !"".equals(user)) { - throw new AuthenticationFailedException( - "SampleSecurityManager: wrong username/password"); - } - - return user; -} -``` http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/authentication_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/authentication_overview.html.md.erb b/geode-docs/managing/security/authentication_overview.html.md.erb deleted file mode 100644 index de8088e..0000000 --- a/geode-docs/managing/security/authentication_overview.html.md.erb +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Authentication ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -Authentication verifies the identities of components within the distributed -system such as peers, clients, and those connecting to a JMX manager. - -- **[Implementing Authentication](../../managing/security/implementing_authentication.html)** - - All components of the distributed system authenticate the same way, - through a custom-written method. - -- **[Encrypting Passwords for Use in cache.xml](../../managing/security/encrypting_passwords.html)** - - Apache Geode provides a gfsh utility to generate encrypted passwords. - -- **[Encrypt Credentials with Diffie-Hellman](../../managing/security/encrypting_with_diffie_helman.html)** - - For secure transmission of sensitive information, like passwords, you can encrypt credentials using the Diffie-Hellman key exchange algorithm. - -- **[Authentication Example](../../managing/security/authentication_examples.html)** - - The example demonstrates the basics of an implementation of the -`SecurityManager.authenticate` method. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/authorization_example.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/authorization_example.html.md.erb b/geode-docs/managing/security/authorization_example.html.md.erb deleted file mode 100644 index 2e725a1..0000000 --- a/geode-docs/managing/security/authorization_example.html.md.erb +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Authorization Example ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -This example demonstrates the basics of an implementation of the -`SecurityManager.authorize` method. -The remainder of the example may be found within the Apache Geode -source code within the -`geode-core/src/main/java/org/apache/geode/security/templates` directory. - -Of course, the security implementation of every installation is unique, -so this example cannot be used in a production environment, -as the roles and permissions will not match the needs of any -real distributed system. - -This example assumes that a set of users, a set of roles -that a user might take on within the system, -and a mapping of users to their roles are described -in a JSON format file. -The roles define a set of authorized resource permissions granted -for users in those roles. -Code not shown here parses the file to compose a data structure -with the information on roles and users. -The `authorize` callback denies permission for any operation -that does not have a principal representing the identity of the -operation's requester. -Given the principal, -the method iterates through the data structure searching for the -necessary permissions for the principal. -When the necessary permission is found, -authorization is granted by returning the value `true`. -If the permission is not found in the data structure, -then the method returns `false`, denying authorization of the operation. - -``` pre -public boolean authorize(final Object principal, final ResourcePermission context) { - if (principal == null) return false; - - User user = this.userNameToUser.get(principal.toString()); - if (user == null) return false; // this user is not authorized to do anything - - // check if the user has this permission defined in the context - for (Role role : this.userNameToUser.get(user.name).roles) { - for (Permission permitted : role.permissions) { - if (permitted.implies(context)) { - return true; - } - } - } - - return false; -} -``` http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/authorization_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/authorization_overview.html.md.erb b/geode-docs/managing/security/authorization_overview.html.md.erb deleted file mode 100644 index beca4f2..0000000 --- a/geode-docs/managing/security/authorization_overview.html.md.erb +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Authorization ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -Distributed system and cache operations can be restricted, intercepted and -modifed, or completely blocked based on configured access rights set for -the various distributed system entities. - -- **[Implementing Authorization](../../managing/security/implementing_authorization.html)** - - To use authorization for client/server systems, your client connections must be authenticated by their servers. - -- **[Authorization Example](../../managing/security/authorization_example.html)** - - This topic discusses the authorization example provided in the product under `templates/security` using `XmlAuthorization.java`, `XmlErrorHandler.java`, and `authz6_0.dtd`. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/chapter_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/chapter_overview.html.md.erb b/geode-docs/managing/security/chapter_overview.html.md.erb deleted file mode 100644 index 98990f6..0000000 --- a/geode-docs/managing/security/chapter_overview.html.md.erb +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Security ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -The security framework permits authentication of connecting components and authorization of operations for all communicating components of the distributed system. - -- **[Security Implementation Introduction and Overview](../../managing/security/implementing_security.html)** - - Encryption, SSL secure communication, authentication, and authorization help to secure the distributed system. - -- **[Security Detail Considerations](../../managing/security/security_audit_overview.html)** - - This section gathers discrete details in one convenient location to better help you assess and configure the security of your environment. - -- **[Enable Security with Property Definitions](../../managing/security/enable_security.html)** - -- **[Authentication](../../managing/security/authentication_overview.html)** - - A distributed system using authentication bars malicious peers or clients, and deters inadvertent access to its cache. - -- **[Authorization](../../managing/security/authorization_overview.html)** - - Client operations on a cache server can be restricted or completely blocked based on the roles and permissions assigned to the credentials submitted by the client. - -- **[Post Processing of Region Data](../../managing/security/post_processing.html)** - -- **[SSL](../../managing/security/ssl_overview.html)** - - SSL protects your data in transit between applications. - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/enable_security.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/enable_security.html.md.erb b/geode-docs/managing/security/enable_security.html.md.erb deleted file mode 100644 index 051180c..0000000 --- a/geode-docs/managing/security/enable_security.html.md.erb +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Enable Security with Property Definitions ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - - -## security-manager Property - -The authentication callback and the authorization callback that implement -the `SecurityManager` interface -are specified with the `security-manager` property. -When this property is defined, authentication and authorization are enabled. -The definition of the `security-manager` property is the -fully qualified name of the class that implements the `SecurityManager` interface. -For example: - -``` pre -security-manager = com.example.security.MySecurityManager -``` - -All components of the system invoke the same callbacks. -Here are descriptions of the components and the connections that they -make with the system. - -- A client connects with a server and makes operation requests -of that server. The callbacks invoked are those defined by the -`SecurityManager` interface for that server. -- A server connects with a locator, invoking the `authenticate` callback -defined for that locator. -- Components communicating with a locator's JMX manager connect and make -operation requests of the locator. -The callbacks invoked are those defined by the -`SecurityManager` interface for that locator. -Both `gfsh` and `Pulse` use this form of communication. -- Applications communicating via the REST API make of a server -invoke security callbacks upon connection and operation requests. -- Requests that a gateway sender makes of a locator -invoke security callbacks defined for that locator. - -## security-post-processor Property - -The `PostProcessor` interface allows the definition of a set of callbacks -that are invoked after operations that get data, -but before the data is returned. -This permits the callback to intervene and modify of the data -that is to be returned. -The callbacks do not modify the region data, -only the data to be returned. - -Enable the post processing of data by defining the -`security-post-processor` property -with the path to the definition of the interface. -For example, - -``` pre -security-post-processor = com.example.security.MySecurityPostProcessing -``` http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/encrypting_passwords.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/encrypting_passwords.html.md.erb b/geode-docs/managing/security/encrypting_passwords.html.md.erb deleted file mode 100644 index 975727e..0000000 --- a/geode-docs/managing/security/encrypting_passwords.html.md.erb +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Encrypting Passwords for Use in cache.xml ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> -<a id="topic_730CC61BA84F421494956E2B98BDE2A1"></a> - - -Apache Geode provides a gfsh utility to generate encrypted passwords. - -You may need to specify an encrypted password in `cache.xml` when configuring JNDI connections to external JDBC data sources. See [Configuring Database Connections Using JNDI](../../developing/transactions/configuring_db_connections_using_JNDI.html#topic_A5E3A67C808D48C08E1F0DC167C5C494) for configuration examples. - -The `cache.xml` file accepts passwords in clear text or encrypted text. - -To generate an encrypted password, use the [encrypt password](../../tools_modules/gfsh/command-pages/encrypt.html#concept_2B834B0AC8EE44C6A7F85CC66B1D6E18__section_F3D0959AF6264A3CB1821383B2AE4407) command in `gfsh`. The following example shows a sample command invocation and output (assuming `my_password` is the actual password for the data source). After you [start gfsh](../../tools_modules/gfsh/starting_gfsh.html#concept_DB959734350B488BBFF91A120890FE61), enter the following command: - -``` pre -gfsh>encrypt password --password=my_password -AB80B8E1EE8BB5701D0366E2BA3C3754 -``` - -Copy the output from the `gfsh` command to the `cache.xml` file as the value of the password attribute of the `jndi-binding` tag embedded in `encrypted()`, just like a method parameter. Enter it as encrypted, in this format: - -``` pre -password="encrypted(83f0069202c571faf1ae6c42b4ad46030e4e31c17409e19a)" -``` - -To use a non-encrypted (clear text) password, put the actual password as the value of the password attribute of the `jndi-binding` tag, like this: - -``` pre -password="password" -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/encrypting_with_diffie_helman.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/encrypting_with_diffie_helman.html.md.erb b/geode-docs/managing/security/encrypting_with_diffie_helman.html.md.erb deleted file mode 100644 index 2dd91cb..0000000 --- a/geode-docs/managing/security/encrypting_with_diffie_helman.html.md.erb +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Encrypt Credentials with Diffie-Hellman ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -For secure transmission of sensitive information, like passwords, you can encrypt credentials using the Diffie-Hellman key exchange algorithm. - -This encryption applies only to client/server authentication - not peer-to-peer authentication. - -You need to specify the name of a valid symmetric key cipher supported by the JDK. Valid key names, like DES, DESede, AES, and Blowfish, enable the Diffie-Hellman algorithm with the specified cipher to encrypt the credentials. For valid JDK names, see [http://download.oracle.com/javase/1.5.0/docs/guide/security/CryptoSpec.html#AppA](http://download.oracle.com/javase/1.5.0/docs/guide/security/CryptoSpec.html#AppA). - -Before you begin, you need to understand how to use your security algorithm. - -## <a id="using_diffie_helman__section_45A9502BDF8E42E1970CEFB132F7424D" class="no-quick-link"></a>Enable Server Authentication of Client with Diffie-Hellman - -Set this in property in the clientâs `gemfire.properties` (or `gfsecurity.properties` file if you are creating a special restricted access file for security configuration): - -- `security-client-dhalgo`. Name of a valid symmetric key cipher supported by the JDK, possibly followed by a key size specification. - -This causes the server to authenticate the client using the Diffie-Hellman algorithm. - -## <a id="using_diffie_helman__section_D07F68BE8D3140E99244895F4AF2CC80" class="no-quick-link"></a>Enable Client Authentication of Server - -This requires server authentication of client with Diffie-Hellman to be enabled. To have your client authenticate its servers, in addition to being authenticated: - -1. In server `gemfire.properties` (or `gfsecurity.properties` file if you are creating a special restricted access file for security configuration), set: - 1. `security-server-kspath`. Path of the PKCS\#12 keystore containing the private key for the server - 2. `security-server-ksalias`. Alias name for the private key in the keystore. - 3. `security-server-kspasswd`. Keystore and private key password, which should match. - -2. In client `gemfire.properties` (or `gfsecurity.properties` file if you are creating a special restricted access file for security configuration), set: - 1. `security-client-kspasswd`. Password for the public key file store on the client - 2. `security-client-kspath`. Path to the client public key truststore, the JKS keystore of public keys for all servers the client can use. This keystore should not be password-protected - -## <a id="using_diffie_helman__section_5FB4437072AC4B4E93210BEA60B67A27" class="no-quick-link"></a>Set the Key Size for AES and Blowfish Encryption Keys - -For algorithms like AES, especially if large key sizes are used, you may need Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Sun or equivalent for your JDK. This enables encryption of client credentials in combination with challenge-response from server to client to prevent replay and other types of attacks. It also enables challenge-response from client to server to avoid server-side replay attacks. - -For the AES and Blowfish algorithms, you can specify the key size for the `security-client-dhalgo` property by adding a colon and the size after the algorithm specification, like this: - -``` pre -security-client-dhalgo=AES:192 -``` - -- For AES, valid key size settings are: - - AES:128 - - AES:192 - - AES:256 -- For Blowfish, set the key size between 128 and 448 bits, inclusive. - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/implementing_authentication.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/implementing_authentication.html.md.erb b/geode-docs/managing/security/implementing_authentication.html.md.erb deleted file mode 100644 index 374a95e..0000000 --- a/geode-docs/managing/security/implementing_authentication.html.md.erb +++ /dev/null @@ -1,142 +0,0 @@ ---- -title: Implementing Authentication ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -Authentication lends a measure of security to a distributed system -by verifying the identity of components as they connect to the system. -All components use the same authentication mechanism. - -## How Authentication Works - -When a component initiates a connection to the distributed system, -the `SecurityManager.authenticate` method is invoked. -The component provides its credentials in the form of properties -as a parameter to the `authenticate` method. -The credential is presumed to be the two properties: -`security-username` and `security-password`. -The `authenticate` method is expected to either return an object -representing a principal or throw an `AuthenticationFailedException`. - -A well-designed `authenticate` method will have or will have a way of -obtaining a set of known user and password pairs that can be compared -to the credential presented. - -## How a Server Sets Its Credential - -In order to connect with a locator that does authentication, -a server will need to set its credential, composed of the two properties -`security-username` and `security-password`. -There are two ways of accomplishing this: - -- Set the `security-username` and `security-password` in the server's -`gfsecurity.properties` file that will be read upon server start up, -as in the example - - ``` pre - security-username=admin - security-password=xyz1234 - ``` -The user name and password are stored in the clear, so the -`gfsecurity.properties` file must be protected by restricting access with -file system permissions. - -- Implement the `getCredentials` method of the `AuthInitialize` interface -for the server. -This callback's location is defined in the property `security-peer-auth-init`, -as in the example - - ``` pre - security-peer-auth-init=com.example.security.MyAuthInitialize - ``` -The implementation of `getCredentials` may then acquire values for -the properties `security-username` and `security-password` in whatever way -it wishes. -It might look up values in a database or another external resource. - -Gateway senders and receivers communicate as a component of their -server member. -Therefore, the credential of the server become those of the gateway -sender or receiver. - -## How a Cache Client Sets Its Credential - -In order to connect with a locator or a server that does authentication, -a client will need to set its credential, composed of the two properties -`security-username` and `security-password`. -There are two ways of accomplishing this: - -- Set the `security-username` and `security-password` in the client's -`gfsecurity.properties` file that will be read upon client start up, -as in the example - - ``` pre - security-username=clientapp - security-password=xyz1234 - ``` -The user name and password are stored in the clear, so the -`gfsecurity.properties` file must be protected by restricting access with -file system permissions. - -- Implement the `getCredentials` method of the `AuthInitialize` interface -for the client. -This callback's location is defined in the property `security-client-auth-init`, -as in the example - - ``` pre - security-client-auth-init=com.example.security.ClientAuthInitialize - ``` -The implementation of `getCredentials` may then acquire values for -the properties `security-username` and `security-password` in whatever way -it wishes. -It might look up values in a database or another external resource, -or it might prompt for values. - -## How Other Components Set Their Credentials - -`gfsh` prompts for the user name and password upon invocation of -a`gfsh connect` command. - -Pulse prompts for the user name and password upon start up. - -Due to the stateless nature of the REST API, -a web application or other component that speaks to a server or locator -via the REST API goes through authentication on each request. -The header of the request needs to include attributes that define values for -`security-username` and `security-password`. - -## Implement SecurityManager Interface - -Complete these items to implement authentication done by either a -locator or a server. - -- Decide upon an authentication algorithm. -The [Authentication Example](authentication_examples.html) -stores a set of user name and -password pairs that represent the identities of components -that will connect to the system. -This simplistic algorithm returns the user name as a principal -if the user name and password passed to the `authenticate` method -are a match for one of the stored pairs. -- Define the `security-manager` property. -See [Enable Security with Property Definitions](enable_security.html) -for details about this property. -- Implement the `authenticate` method of the `SecurityManager` interface. -- Define any extra resources that the implemented authentication algorithm -needs in order to make a decision. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/implementing_authorization.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/implementing_authorization.html.md.erb b/geode-docs/managing/security/implementing_authorization.html.md.erb deleted file mode 100644 index ec47133..0000000 --- a/geode-docs/managing/security/implementing_authorization.html.md.erb +++ /dev/null @@ -1,265 +0,0 @@ ---- -title: Implementing Authorization ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -## How Authorization Works - -When a component requests an operation, -the `SecurityManager.authorize` method is invoked. -It is passed the principal of the operation's requester -and a `ResourcePermission`, which describes the operation requested. - -The implementation of the `SecurityManager.authorize` method -makes a decision as to whether or not the principal will be granted permission -to carry out the operation. -It returns a boolean in which a return value of `true` permits -the operation, -and a return value of `false` prevents the operation. - -A well-designed `authorize` method will have or will have a way of obtaining -a mapping of principals to the operations (in the form of resource permissions) -that they are permitted to do. - -## Resource Permissions - -All operations are described by an instance of the `ResourcePermission` class. -A permission contains the `Resource` data member, -which classifies whether the operation as working on - -- cache data; value is `DATA` -- the distributed system; value is `CLUSTER` - -A permission also contains the `Operation` data member, -which classifies whether the operation as - -- reading; value is `READ` -- changing information; value is `WRITE` -- making administrative changes; value is `MANAGE` - -The operations are not hierarchical; -`MANAGE` does not imply `WRITE`, and `WRITE` does not imply `READ`. - -Some operations further specify a region name in the permission. -This permits restricting operations on that region to only those -authorized principals. -And within a region, some operations may specify a key. -This permits restricting operations on that key within that region to -only those authorized principals. - -This table classifies the permissions assigned for operations common to -a Client-Server interaction. - -| Client Operation | Assigned `ResourcePermission` -|------------------------------------|-------------------------------------| -| get function attribute | CLUSTER:READ | -| create region | DATA:MANAGE | -| destroy region | DATA:MANAGE | -| Region.Keyset | DATA:READ:RegionName | -| Region.query | DATA:READ:RegionName | -| Region.getAll | DATA:READ:RegionName | -| Region.getAll with a list of keys | DATA:READ:RegionName:Key | -| Region.getEntry | DATA:READ:RegionName | -| Region.containsKeyOnServer(key) | DATA:READ:RegionName:Key | -| Region.get(key) | DATA:READ:RegionName:Key | -| Region.registerInterest(key) | DATA:READ:RegionName:Key | -| Region.registerInterest(regex) | DATA:READ:RegionName | -| Region.unregisterInterest(key) | DATA:READ:RegionName:Key | -| Region.unregisterInterest(regex) | DATA:READ:RegionName | -| execute function | DATA:WRITE | -| clear region | DATA:WRITE:RegionName | -| Region.putAll | DATA:WRITE:RegionName | -| Region.clear | DATA:WRITE:RegionName | -| Region.removeAll | DATA:WRITE:RegionName | -| Region.destroy(key) | DATA:WRITE:RegionName:Key | -| Region.invalidate(key) | DATA:WRITE:RegionName:Key | -| invalidate key (DIFFERENT?) | DATA:WRITE:RegionName:Key | -| Region.destroy(key) | DATA:WRITE:RegionName:Key | -| destroy key (DIFFERENT?) | DATA:WRITE:RegionName:Key | -| Region.put(key) | DATA:WRITE:RegionName:Key | -| Region.replace | DATA:WRITE:RegionName:Key | - - -This table classifies the permissions assigned for `gfsh` operations. - -| `gfsh` Command | Assigned `ResourcePermission` -|----------------------------------------|----------------------------------| -| alter disk-store | DATA:MANAGE | -| alter region | DATA:MANAGE:RegionName | -| alter runtime | CLUSTER:MANAGE | -| backup disk-store | DATA:READ | -| change loglevel | CLUSTER:WRITE | -| clear defined indexes | DATA:MANAGE | -| close durable-client | DATA:MANAGE | -| close durable-cq | DATA:MANAGE | -| compact disk-store | DATA:MANAGE | -| compact offline-disk-store | DATA:MANAGE | -| configure pdx | DATA:MANAGE | -| create async-event-queue | DATA:MANAGE | -| create defined indexes | DATA:MANAGE | -| create disk-store | DATA:MANAGE | -| create gateway-receiver | DATA:MANAGE | -| create gateway-sender | DATA:MANAGE | -| create index | DATA:MANAGE:RegionName | -| create region | DATA:MANAGE | -| define index | DATA:MANAGE:RegionName | -| deploy | DATA:MANAGE | -| describe client | CLUSTER:READ | -| describe config | CLUSTER:READ | -| describe disk-store | CLUSTER:READ | -| describe member | CLUSTER:READ | -| describe offline-disk-store | CLUSTER:READ | -| describe region | CLUSTER:READ | -| destroy disk-store | DATA:MANAGE | -| destroy function | DATA:MANAGE | -| destroy index | DATA:MANAGE or DATA:MANAGE:RegionName | -| destroy region | DATA:MANAGE | -| disconnect | DATA:MANAGE | -| echo | DATA:MANAGE | -| encrypt password | DATA:MANAGE | -| execute function | DATA:MANAGE | -| export cluster-configuration | CLUSTER:READ | -| export config | CLUSTER:READ | -| export data | CLUSTER:READ | -| export logs | CLUSTER:READ | -| export offline-disk-store | CLUSTER:READ | -| export stack-traces | CLUSTER:READ | -| gc | CLUSTER:MANAGE | -| get --key=key1 --region=region1 | DATA:READ:RegionName:Key | -| import data | DATA:WRITE:RegionName | -| import cluster-configuration | DATA:MANAGE | -| list async-event-queues | CLUSTER:READ | -| list clients | CLUSTER:READ | -| list deployed | CLUSTER:READ | -| list disk-stores | CLUSTER:READ | -| list durable-cqs | CLUSTER:READ | -| list functions | CLUSTER:READ | -| list gateways | CLUSTER:READ | -| list indexes | CLUSTER:READ | -| list members | CLUSTER:READ | -| list regions | DATA:READ | -| load-balance gateway-sender | DATA:MANAGE | -| locate entry | DATA:READ:RegionName:Key | -| netstat | CLUSTER:READ | -| pause gateway-sender | DATA:MANAGE | -| pdx rename | DATA:MANAGE | -| put --key=key1 --region=region1 | DATA:WRITE:RegionName:Key | -| query | DATA:READ:RegionName | -| rebalance | DATA:MANAGE | -| remove | DATA:WRITE:RegionName or DATA:WRITE:RegionName:Key | -| resume gateway-sender | DATA:MANAGE | -| revoke mising-disk-store | DATA:MANAGE | -| show dead-locks | CLUSTER:READ | -| show log | CLUSTER:READ | -| show metrics | CLUSTER:READ | -| show missing-disk-stores | CLUSTER:READ | -| show subscription-queue-size | CLUSTER:READ | -| shutdown | CLUSTER:MANAGE | -| start gateway-receiver | DATA:MANAGE | -| start gateway-sender | DATA:MANAGE | -| start server | CLUSTER:MANAGE | -| status cluster-config-service | CLUSTER:READ | -| status gateway-receiver | CLUSTER:READ | -| status gateway-sender | CLUSTER:READ | -| status locator | CLUSTER:READ | -| status server | CLUSTER:READ | -| stop gateway-receiver | DATA:MANAGE | -| stop gateway-receiver | DATA:MANAGE | -| stop locator | CLUSTER:MANAGE | -| stop server | CLUSTER:MANAGE | -| undeploy | DATA:MANAGE | - -The `gfsh connect` does not have a permission, -as it is the operation that invokes authentication. -These `gfsh` commands do not have permission defined, -as they do not interact with the distributed system. - -- `gfsh describe connection`, which describes the `gfsh` end of the connection -- `gfsh debug`, which toggles the mode within `gfsh` -- `gfsh exit` -- `gfsh help` -- `gfsh hint` -- `gfsh history` -- `gfsh run`, although individual commands within the script -will go through authorization -- `gfsh set variable` -- `gfsh sh` -- `gfsh sleep` -- `validate offline-disk-store` -- `gfsh version` - -This table classifies the permissions assigned for JMX operations. - -| JMX Operation | Assigned `ResourcePermission` -|----------------------------------------------|-----------------------------| -| DistributedSystemMXBean.shutdownAllMembers | CLUSTER:MANAGE | -| ManagerMXBean.start | CLUSTER:MANAGE | -| ManagerMXBean.stop | CLUSTER:MANAGE | -| ManagerMXBean.createManager | CLUSTER:MANAGE | -| ManagerMXBean.shutDownMember | CLUSTER:MANAGE | -| Mbeans get attributes | CLUSTER:READ | -| MemberMXBean.showLog | CLUSTER:READ | -| DistributedSystemMXBean.changerAlertLevel | CLUSTER:WRITE | -| ManagerMXBean.setPulseURL | CLUSTER:WRITE | -| ManagerMXBean.setStatusMessage | CLUSTER:WRITE | -| CacheServerMXBean.closeAllContinuousQuery | DATA:MANAGE | -| CacheServerMXBean.closeContinuousQuery | DATA:MANAGE | -| CacheServerMXBean.executeContinuousQuery | DATA:READ | -| DiskStoreMXBean.flush | DATA:MANAGE | -| DiskStoreMXBean.forceCompaction | DATA:MANAGE | -| DiskStoreMXBean.forceRoll | DATA:MANAGE | -| DiskStoreMXBean.setDiskUsageCriticalPercentage | DATA:MANAGE | -| DiskStoreMXBean.setDiskUsageWarningPercentage | DATA:MANAGE | -| DistributedSystemMXBean.revokeMissingDiskStores| DATA:MANAGE | -| DistributedSystemMXBean.setQueryCollectionsDepth| DATA:MANAGE | -| DistributedSystemMXBean.setQueryResultSetLimit | DATA:MANAGE | -| DistributedSystemMXBean.backupAllMembers | DATA:READ | -| DistributedSystemMXBean.queryData | DATA:READ | -| DistributedSystemMXBean.queryDataForCompressedResult | DATA:READ | -| GatewayReceiverMXBean.pause | DATA:MANAGE | -| GatewayReceiverMXBean.rebalance | DATA:MANAGE | -| GatewayReceiverMXBean.resume | DATA:MANAGE | -| GatewayReceiverMXBean.start | DATA:MANAGE | -| GatewayReceiverMXBean.stop | DATA:MANAGE | -| GatewaySenderMXBean.pause | DATA:MANAGE | -| GatewaySenderMXBean.rebalance | DATA:MANAGE | -| GatewaySenderMXBean.resume | DATA:MANAGE | -| GatewaySenderMXBean.start | DATA:MANAGE | -| GatewaySenderMXBean.stop | DATA:MANAGE | -| LockServiceMXBean.becomeLockGrantor | DATA:MANAGE | -| MemberMXBean.compactAllDiskStores | DATA:MANAGE | - -## Implement Authorization - -Complete these items to implement authorization. - -- Decide upon an authorization algorithm. -The [Authorization Example](authorization_example.html) -stores a mapping of which principals (users) are permitted to do -which operations. -The algorithm bases its decision -on a look up of the permissions granted to the principal attempting -the operation. -- Define the `security-manager` property. -See [Enable Security with Property Definitions](enable_security.html) -for details about this property. -- Implement the `authorize` method of the `SecurityManager` interface. -- Define any extra resources that the implemented authorization algorithm -needs in order to make a decision. - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/implementing_security.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/implementing_security.html.md.erb b/geode-docs/managing/security/implementing_security.html.md.erb deleted file mode 100644 index c0afc5c..0000000 --- a/geode-docs/managing/security/implementing_security.html.md.erb +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Security Implementation Introduction and Overview ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -## Security Features - -Encryption, SSL secure communication, authentication, and authorization -features help to secure the distributed system. - -Security features include: - -- **A single security interface for all components**. The single -authentication and authorization mechanism simplifies the security -implementation. -It views and interacts with all components in a consistent manner. -- **System-wide role-based access control**. -Roles regiment authorized operations requested by the various components. -- **SSL communication**. Allows configuration of connections to be -SSL-based, rather than plain socket connections. -You can enable SSL separately for peer-to-peer, client, JMX, gateway senders and receivers, and HTTP connections. -- **Post processing of region data**. Return values for operations that -return region values may be altered, permitting the filtering of returned data. - -## Overview - -An authentication and authorization mechanism forms the core of -the internal security of the distributed system. -Communications may be further protected by enabling SSL for -data in transit. - -Authentication verifies the identity of communicating components, -leading to control over participation. -The variety of participants include peer members, servers, -clients, originators of JMX operations, Pulse, -gateway senders and receivers representing WAN members of the system, -and commands arriving from `gfsh` on behalf of system users -or administrators. - -Connection requests trigger the invocation of an authentication -callback. -This special-purpose callback is written as part of the application, -and it attempts to authenticate the requester by whatever -algorithm it chooses. -The result is either a returned principal representing the requester's -authenticated identity or an exception indicating that the requester -has not been authenticated. -The principal becomes part of any request for operations, -which go through the authorization process. - - -Given authentication, -isolation and access to cache data and system state can be further -protected by implementing the authorization mechanism, -also implemented as a special-purpose callback as part of the application. -For example, the protection may be to permit only certain system administrators -to start and stop servers. -The authority to do this needs to be limited to specific -verified accounts, preventing those without the authorization. -An implementation of the authorization callback will require -that an authenticate identity accompanies all requests to the system, -and that the system maintains a representation of which identities -are permitted to complete which actions or cache commands. - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/implementing_ssl.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/implementing_ssl.html.md.erb b/geode-docs/managing/security/implementing_ssl.html.md.erb deleted file mode 100644 index c19b6d9..0000000 --- a/geode-docs/managing/security/implementing_ssl.html.md.erb +++ /dev/null @@ -1,226 +0,0 @@ ---- -title: Configuring SSL ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -You can configure SSL for authentication between members and to protect your data during -distribution. You can use SSL alone or in conjunction with the other Geode security options. -Geode SSL connections use the Java Secure Sockets Extension (JSSE) package. - -## <a id="ssl_configurable_components" class="no-quick-link"></a>SSL-Configurable Components - -You can specify that SSL be used system-wide, or you can independently configure SSL for specific -system components. The following list shows the system components that can be separately configured -to communicate using SSL, and the kind of communications to which each component name refers: - -<dt>**cluster**</dt> -<dd>Peer-to-peer communications among members of a distributed system</dd> - -<dt>**gateway**</dt> -<dd>Communication across WAN gateways from one site to another</dd> - -<dt>**web**</dt> -<dd>All web-based services hosted on the configured server, which can include the Developer REST API -service, the Management REST API service (used for remote cluster management) and the Pulse -monitoring tool's web-based user interface.</dd> - -<dt>**jmx**</dt> -<dd>Java management extension communications, including communications with the `gfsh` utility. -The Pulse monitoring tool uses JMX for server-side communication with a locator, but SSL -applies to this connection only if Pulse is located on an app server separate from the -locator. When Pulse and the locator are colocated, JMX communication between the two does not -involve a TCP connection, so SSL does not apply.</dd> - -<dt>**locator**</dt> -<dd>Communication with and between locators</dd> - -<dt>**server**</dt> -<dd>Communication between clients and servers</dd> - -<dt>**all**</dt> -<dd>All of the above (use SSL system-wide)</dd> - -Specifying that a component is enabled for SSL applies to the component's server-socket side and its -client-socket side. For example, if you enable SSL for locators, then any process that communicates -with a locator must also have SSL enabled. - -## <a id="ssl_configuration_properties" class="no-quick-link"></a>SSL Configuration Properties - -You can use Geode configuration properties to enable or disable SSL, to identify SSL ciphers and -protocols, and to provide the location and credentials for key and trust stores. - -<dt>**ssl-enabled-components**</dt> -<dd>list of components for which to enable SSL. "all" or comma-separated list of components</dd> - -<dt>**ssl-require-authentication**</dt> -<dd>Requires two-way authentication, applies to all components except web. boolean - if true (the default), two-way authentication is required.</dd> - -<dt>**ssl-web-require-authentication**</dt> -<dd>Requires two-way authentication for web component. boolean - if true, two-way authentication is required. Default is false (one-way authentication only).</dd> - -<dt>**ssl-default-alias**</dt> -<dd>A server uses one key store to hold its SSL certificates. All components on that server can share a -single certificate, designated by the ssl-default-alias property. If ssl-default-alias -is not specified, the first certificate in the key store acts as the default certificate.</dd> - -<dt>**ssl-_component_-alias=string**</dt> -<dd>You can configure a separate certificate for any component. All certificates reside in the same key -store, but can be designated by separate aliases that incorporate the component name, using this syntax, -where _component_ is the name of a component. When a component-specific alias is specified, it -overrides the ssl-default-alias for the _component_ specified. - -For example, ssl-locator-alias would specify a name for the locator component's certificate in the system key store.</dd> - -<dt>**ssl-ciphers**</dt> -<dd>A comma-separated list of the valid SSL ciphers for SSL-enabled component connections. A setting of 'any' -uses any ciphers that are enabled by default in the configured JSSE provider.</dd> - -<dt>**ssl-protocols**</dt> -<dd>A comma-separated list of the valid SSL-enabled component connections. A setting of 'any' uses -any protocol that is enabled by default in the configured JSSE provider.</dd> - -<dt>**ssl-keystore, ssl-keystore-password**</dt> -<dd>The path to the key store and the key store password, specified as strings</dd> - -<dt>**ssl-truststore, ssl-truststore-password**</dt> -<dd>The path to the trust store and the trust store password, specified as strings</dd> - -### Example: secure communications throughout - -To implement secure SSL communications throughout an entire distributed system, each process should -enable SSL for all components. - -``` pre -ssl-enabled-components=all -ssl-keystore=secure/keystore.dat -ssl-keystore-password=changeit -ssl-truststore=secure/truststore.dat -ssl-truststore-password=changeit -``` - -If the key store has multiple certificates you may want to specify the alias of the one you wish to use for each process. For instance, `ssl-default-alias=Hiroki`. - - -### Example: non-secure cluster communications, secure client/server - -In this example, SSL is used to secure communications between the client and the server: - -**Server properties** - -Cluster SSL is not enabled. - -``` pre -ssl-enabled-components=server,locator -ssl-server-alias=server -ssl-keystore=secure/keystore.dat -ssl-keystore-password=changeit -ssl-truststore=secure/truststore.dat -ssl-truststore-password=changeit -ssl-default-alias=Server-Cert -``` - -**Locator properties** - -Cluster SSL is not enabled. - -``` pre -ssl-enabled-components=locator -ssl-locator-alias=locator -ssl-keystore=secure/keystore.dat -ssl-keystore-password=changeit -ssl-truststore=secure/truststore.dat -ssl-truststore-password=changeit -ssl-default-alias=Locator-Cert -``` - -**Client properties** - -The client's trust store must trust both locator and server certificates. - -Since the client did not specify a certificate alias, SSL will use the default certificate in its key store. - -``` pre -ssl-enabled-components=server,locator -ssl-keystore=secret/keystore.dat -ssl-keystore-password=changeit -ssl-truststore=secret/truststore.dat -ssl-truststore-password=changeit -``` - -## <a id="ssl_property_reference_tables" class="no-quick-link"></a>SSL Property Reference Tables - -The following table lists the components you can configure to use SSL. - -<span class="tablecap">Table 1. SSL-Configurable Components</span> - -| Component | Communication Types | -|-----------|-----------------------------------------------------------------------| -| cluster | Peer-to-peer communications among members of a distributed system | -| gateway | Communication across WAN gateways from one site to another | -| web | Web-based communication, including REST interfaces | -| jmx | Java management extension communications, including gfsh | -| locator | Communication with and between locators | -| server | Communication between clients and servers | -| all | All of the above | - -The following table lists the properties you can use to configure SSL on your Geode system. - -<span class="tablecap">Table 2. SSL Configuration Properties</span> - -| Property | Description | Value | -|------------------------------------|------------------------------------------------------------------------------|-------| -| ssl‑enabled‑components | list of components for which to enable SSL | "all" or comma-separated list of components: cluster, gateway, web, jmx, locator, server | -| ssl-require-authentication | requires two-way authentication, applies to all components except web | boolean - if true (the default), two-way authentication is required | -| ssl‑web‑require‑authentication | requires two-way authentication for web component | boolean - if true, two-way authentication is required. Default is false (one-way authentication only) | -| ssl-default-alias | default certificate name | string - if empty, use first certificate in key store | -| ssl-_component_-alias | component-specific certificate name | string - applies to specified _component_ | -| ssl-ciphers | list of SSL ciphers | comma-separated list (default "any") | -| ssl-protocols | list of SSL protocols | comma-separated list (default "any") | -| ssl-keystore | path to key store | string | -| ssl-keystore-password | key store password | string | -| ssl-truststore | path to trust store | string | -| ssl-truststore-password | trust store password | string | - -## <a id="implementing_ssl__sec_ssl_impl_proc" class="no-quick-link"></a>Procedure - -1. Make sure your Java installation includes the JSSE API and familiarize yourself with its -use. For information, see the [Oracle JSSE website](http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html). - -2. Configure SSL as needed for each connection type: - - 1. Use locators for member discovery within the distributed systems and for client discovery of - servers. See [Configuring Peer-to-Peer Discovery](../../topologies_and_comm/p2p_configuration/setting_up_a_p2p_system.html) and - [Configuring a Client/Server System](../../topologies_and_comm/cs_configuration/setting_up_a_client_server_system.html#setting_up_a_client_server_system). - - 2. Configure SSL properties as necessary for different component types, using the properties - described above. For example, to enable SSL for - communication between clients and servers you would configure properties in the - `gemfire.properties` file similar to: - - ``` pre - ssl-enabled-components=server - ssl-protocols=any - ssl-ciphers=SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA - ssl-keystore=/path/to/trusted.keystore - ssl-keystore-password=password - ssl-truststore=/path/to/trusted.keystore - ssl-truststore-password=password - ``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/84cfbdfc/geode-docs/managing/security/post_processing.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/security/post_processing.html.md.erb b/geode-docs/managing/security/post_processing.html.md.erb deleted file mode 100644 index f0ce32e..0000000 --- a/geode-docs/managing/security/post_processing.html.md.erb +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Post Processing of Region Data ---- - -<!-- -Licensed to the Apache Software Foundation (ASF) under one or more -contributor license agreements. See the NOTICE file distributed with -this work for additional information regarding copyright ownership. -The ASF licenses this file to You under the Apache License, Version 2.0 -(the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. ---> - -The `PostProcessor` interface allows the definition of a callback -that is invoked after any and all client and `gfsh` operations that get data, -but before the data is returned. -It permits the callback to intervene and modify of the data -that is to be returned. -The callbacks do not modify the region data, -only the data to be returned. - -The `processRegionValue` method is given the principal of the -operation requester. -The operation will already have been completed, -implying that the principal will have been authorized to complete -the requested operation. -The post processing can therefore modify the returned data based -on the identity of the requester (principal). - -A use of post processing will be to sanitize or mask out sensitive -region information, -while providing the remainder of a region entry unchanged. -An implementation can alter the entry for some requesters, -but not other requesters. - -The `processRegionValue` method is invoked for these API calls: - -- `Region.get` -- `Region.getAll` -- `Query.execute` -- `CqQuery.execute` -- `CqQuery.executeWithInitialResults` -- `CqListener.onEvent` -- for a relevant region event from `CacheListener.afterUpdate` for which -there is interest registered with `Region.registerInterest` - -Care should be taken when designing a system that implements the -post processing callback. -It incurs the performance penalty of an extra method invocation -on every get operation. - -## Implement Post Processing - -Complete these items to implement post processing. - -- Define the `security-post-processor` property. -See [Enable Security with Property Definitions](enable_security.html) -for details about this property. -- Implement the `processRegionValue` method of the `PostProcessor` interface.
