You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@knox.apache.org by lm...@apache.org on 2014/04/19 20:29:28 UTC
svn commit: r1588691 [2/2] - in /knox: site/books/knox-0-4-0/
trunk/books/0.4.0/
Modified: knox/trunk/books/0.4.0/book_limitations.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.4.0/book_limitations.md?rev=1588691&r1=1588690&r2=1588691&view=diff
==============================================================================
--- knox/trunk/books/0.4.0/book_limitations.md (original)
+++ knox/trunk/books/0.4.0/book_limitations.md Sat Apr 19 18:29:28 2014
@@ -28,15 +28,14 @@ There is an undocumented configuration s
In the future this will be made more easily configuration and at that time it will be documented.
-### LDAP Groups Acquisition ###
+### LDAP Groups Acquisition from AD ###
-The LDAP authenticator currently does not "out of the box" support the acquisition of group information.
-This can be addressed by implementing a custom Shiro Realm extension.
+The LDAP authenticator currently does not "out of the box" support the acquisition of group information from Microsoft Active Directory.
Building this into the default implementation is on the roadmap.
### Group Membership Propagation ###
-Groups that are acquired via Identity Assertion Group Principal Mapping are not propigated to the Hadoop services.
+Groups that are acquired via Shiro Group Lookup and/or Identity Assertion Group Principal Mapping are not propagated to the Hadoop services.
Therefore groups used for Service Level Authorization policy may not match those acquired within the cluster via GroupMappingServiceProvider plugins.
Modified: knox/trunk/books/0.4.0/config.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.4.0/config.md?rev=1588691&r1=1588690&r2=1588691&view=diff
==============================================================================
--- knox/trunk/books/0.4.0/config.md (original)
+++ knox/trunk/books/0.4.0/config.md Sat Apr 19 18:29:28 2014
@@ -114,9 +114,9 @@ topology/service/url
#### Hostmap Provider ####
-The purpose of the Hostmap provider is to handle situations where host are know by one name within the cluster and another name externally.
-This frequently occurs when virtual machines are used and in particular using cloud hosting services.
-Currently the Hostmap provider is configured as part of the topology file.
+The purpose of the Hostmap provider is to handle situations where host are known by one name within the cluster and another name externally.
+This frequently occurs when virtual machines are used and in particular when using cloud hosting services.
+Currently, the Hostmap provider is configured as part of the topology file.
The basic structure is shown below.
<topology>
@@ -176,7 +176,7 @@ The Hostmap configuration required to al
##### Hostmap Provider Example - Sandbox #####
-Hortonwork's Sandbox 2.x poses a different challenge for host name mapping.
+The Hortonworks Sandbox 2.x poses a different challenge for host name mapping.
This version of the Sandbox uses port mapping to make the Sandbox VM appear as though it is accessible via localhost.
However the Sandbox VM is internally configured to consider sandbox.hortonworks.com as the host name.
So from the perspective of a client accessing Sandbox the external host name is localhost.
@@ -264,21 +264,21 @@ The following is a description of how th
Upon start of the gateway server we:
-1. Look for an identity store at `conf/security/keystores/gateway.jks`.
+1. Look for an identity store at `data/security/keystores/gateway.jks`.
The identity store contains the certificate and private key used to represent the identity of the server for SSL connections and signature creation.
* If there is no identity store we create one and generate a self-signed certificate for use in standalone/demo mode.
The certificate is stored with an alias of gateway-identity.
- * If there is an identity store found than we ensure that it can be loaded using the provided master secret and that there is an alias with called gateway-identity.
-2. Look for a credential store at `conf/security/keystores/__gateway-credentials.jceks`.
+ * If there is an identity store found than we ensure that it can be loaded using the provided master secret and that there is an alias called gateway-identity.
+2. Look for a credential store at `data/security/keystores/__gateway-credentials.jceks`.
This credential store is used to store secrets/passwords that are used by the gateway.
- For instance, this is where the pass-phrase for accessing the gateway-identity certificate is kept.
- * If there is no credential store found then we create one and populate it with a generated pass-phrase for the alias `gateway-identity-passphrase`.
+ For instance, this is where the passphrase for accessing the gateway-identity certificate is kept.
+ * If there is no credential store found then we create one and populate it with a generated passphrase for the alias `gateway-identity-passphrase`.
This is coordinated with the population of the self-signed cert into the identity-store.
* If a credential store is found then we ensure that it can be loaded using the provided master secret and that the expected aliases have been populated with secrets.
Upon deployment of a Hadoop cluster topology within the gateway we:
-1. Look for a credential store for the topology. For instance, we have a sample topology that gets deployed out of the box. We look for `conf/security/keystores/sandbox-credentials.jceks`. This topology specific credential store is used for storing secrets/passwords that are used for encrypting sensitive data with topology specific keys.
+1. Look for a credential store for the topology. For instance, we have a sample topology that gets deployed out of the box. We look for `data/security/keystores/sandbox-credentials.jceks`. This topology specific credential store is used for storing secrets/passwords that are used for encrypting sensitive data with topology specific keys.
* If no credential store is found for the topology being deployed then one is created for it.
Population of the aliases is delegated to the configured providers within the system that will require the use of a secret for a particular task.
They may programmatic set the value of the secret or choose to have the value for the specified alias generated through the AliasService.
@@ -296,7 +296,6 @@ See the Knox CLI section for description
In order to provide your own certificate for use by the gateway, you will need to either import an existing key pair into a Java keystore or generate a self-signed cert using the Java keytool.
##### Importing a key pair into a Java keystore #####
-# ----NEEDS TESTING
One way to accomplish this is to start with a PKCS12 store for your key pair and then convert it to a Java keystore or JKS.
openssl pkcs12 -export -in cert.pem -inkey key.pem > server.p12
@@ -311,11 +310,9 @@ While using this approach a couple of im
1. the alias MUST be "gateway-identity"
2. the name of the expected identity keystore for the gateway MUST be gateway.jks
-3. the passwords for the keystore and the imported key MUST both be the master secret for the gateway install
+3. the passwords for the keystore and the imported key may both be set to the master secret for the gateway install
-NOTE: The password for the keystore as well as that of the imported key must be the master secret for the gateway instance.
-
-# ----END NEEDS TESTING
+NOTE: The password for the keystore as well as that of the imported key may be the master secret for the gateway instance or you may set the gateway-identity-passphrase alias using the Knox CLI to the actual key passphrase. See the Knox CLI section for details.
##### Generating a self-signed cert for use in testing or development environments #####
@@ -326,21 +323,21 @@ Keytool will prompt you for a number of
*NOTE:* When it prompts you for your First and Last name be sure to type in the hostname of the machine that your gateway instance will be running on. This is used by clients during hostname verification to ensure that the presented certificate matches the hostname that was used in the URL for the connection - so they need to match.
-*NOTE:* When it prompts for the key password just press enter to ensure that it is the same as the keystore password. Which as was described earlier must match the master secret for the gateway instance.
+*NOTE:* When it prompts for the key password just press enter to ensure that it is the same as the keystore password. Which as was described earlier must match the master secret for the gateway instance. Alternatively, you can set it to another passphrase - take note of it and set the gateway-identity-passphrase alias to that passphrase using the Knox CLI.
See the Knox CLI section for descriptions of the command line utilties related to the management of the keystores.
##### Credential Store #####
-Whenever you provide your own keystore with either a self-signed cert or a real certificate signed by a trusted authority, you will need to create an empty credential store. This is necessary for the current release in order for the system to utilize the same password for the keystore and the key.
+Whenever you provide your own keystore with either a self-signed cert or an issued certificate signed by a trusted authority, you will need to set an alias for the gateway-identity-passphrase or create an empty credential store. This is necessary for the current release in order for the system to determine the correct password for the keystore and the key.
The credential stores in Knox use the JCEKS keystore type as it allows for the storage of general secrets in addition to certificates.
-Keytool may be used to create credential stores but the Knox CLI section details how to create aliases. These aliases are managed within credential stores which are created by the CLI as appropriate.
+Keytool may be used to create credential stores but the Knox CLI section details how to create aliases. These aliases are managed within credential stores which are created by the CLI as needed. The simplest approach is to create the gateway-identity-passpharse alias with the Knox CLI. This will create the credential store if it doesn't already exist and add the key passphrase.
See the Knox CLI section for descriptions of the command line utilties related to the management of the credential stores.
##### Provisioning of Keystores #####
-Once you have created these keystores you must move them into place for the gateway to discover them and use them to represent its identity for SSL connections. This is done by copying the keystores to the `{GATEWAY_HOME}/conf/security/keystores` directory for your gateway install.
+Once you have created these keystores you must move them into place for the gateway to discover them and use them to represent its identity for SSL connections. This is done by copying the keystores to the `{GATEWAY_HOME}/data/security/keystores` directory for your gateway install.
#### Summary of Secrets to be Managed ####
Modified: knox/trunk/books/0.4.0/config_preauth_sso_provider.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.4.0/config_preauth_sso_provider.md?rev=1588691&r1=1588690&r2=1588691&view=diff
==============================================================================
--- knox/trunk/books/0.4.0/config_preauth_sso_provider.md (original)
+++ knox/trunk/books/0.4.0/config_preauth_sso_provider.md Sat Apr 19 18:29:28 2014
@@ -25,6 +25,8 @@ Knox Gateway needs a pluggable mechanism
#### Configuration ####
##### Overview #####
+This provider was designed for use with identity solutions such as those provided by CA's SiteMinder and IBM's Tivoli Access Manager. While direct testing with these products has not been done, there has been extensive unit and functional testing that ensure that it should work with such providers.
+
The HeaderPreAuth provider is configured within the topology file and has a minimal configuration that assumes SM_USER for CA SiteMinder. The following example is the bare minimum configuration for SiteMinder (with no IP address validation).
<provider>