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/12 16:53:53 UTC
svn commit: r1586859 - in /knox: site/index.html
trunk/src/site/markdown/index.md
Author: lmccay
Date: Sat Apr 12 14:53:52 2014
New Revision: 1586859
URL: http://svn.apache.org/r1586859
Log:
added overview sections to site
Modified:
knox/site/index.html
knox/trunk/src/site/markdown/index.md
Modified: knox/site/index.html
URL: http://svn.apache.org/viewvc/knox/site/index.html?rev=1586859&r1=1586858&r2=1586859&view=diff
==============================================================================
--- knox/site/index.html (original)
+++ knox/site/index.html Sat Apr 12 14:53:52 2014
@@ -189,7 +189,7 @@ limitations under the License. --><div c
<li>Integrates well with enterprise identity management solutions</li>
<li>Protects the details of the Hadoop cluster deployment (hosts and ports are hidden from endusers)</li>
<li>Simplifies the number of services that clients need to interact with</li>
-</ul><p><img src="http://knox.apache.org/images/knox-overview.gif" alt="alt text" /></p></div>
+</ul><p><img src="http://knox.apache.org/images/knox-overview.gif" alt="alt text" /></p></div><div class="section"><h2>Overview<a name="Overview"></a></h2><p>The Knox API Gateway is designed as a reverse proxy with consideration for pluggability in the areas of<br /> policy enforcement, through providers and the backend services for which it proxies requests.</p><p>Policy enforcement ranges from authentication/federation, authorization, audit, dispatch, hostmapping<br /> and content rewrite rules. Policy is enforced through a chain of providers that are defined within the topology<br /> deployment descriptor for each Hadoop cluster gated by Knox. The cluster definition is also defined<br /> within the topology deployment descriptor and provides the Knox Gateway with the layout of the Hadoop<br /> cluster for purposes of routing and translation between user facing URLs and Hadoop cluster internals.</p><p>Each Hadoop cluster that is protected by Knox has its set of REST APIs represent
ed by a single cluster specific<br /> application context path. This allows the Knox Gateway to both protect multiple Hadoop clusters and present<br /> the REST API consumer with a single endpoint for access to all of the Hadoop services required, across the<br /> multiple clusters.</p></div><div class="section"><h2>Authentication<a name="Authentication"></a></h2><p>Providers with the role of authentication are responsible for collecting credentials presented by the API<br /> consumer, validating them and communicating the successful or failed authentication to the client or the<br /> rest of the provider chain.</p><p>Out of the box, the Knox Gateway provides the Shiro authentication provider. This is a provider that leverages<br /> the Apache Shiro project for authenticating BASIC credentials against an LDAP user store. There is support for<br /> OpenLDAP, ApacheDS and Microsoft Active Directory.</p></div><div class="section"><h2>Federation/SSO<a name="FederationSSO"></a></h2><p>Fo
r customers that require credentials to be presented to a limited set of trusted entities within the enterprise,<br /> the Knox Gateway may be configured to federate the authenticated identity from an external authentication event.<br /> This is done through providers with the role of federation. The out of the box federation provider is a simple<br /> mechanism for propagating the identity through HTTP Headers that specify the username and group for the authenticated<br /> user. This has been built with vendor usecases such as SiteMinder and IBM Tivoli Access Manager.</p></div><div class="section"><h2>Service Level Authorization<a name="Service_Level_Authorization"></a></h2><p>The authorization role is used by providers that make access decisions for the requested resources based on the<br /> effective user identity context. This identity context is determined by the authentication provider and the identity<br /> assertion provider mapping rules. Evaluation of the identity contexts
user and group principals against a set of<br /> access policies is done by the authorization provider in order to determine whether access should be granted to<br /> the effective user for the requested resource.</p><p>Out of the box, the Knox Gateway provides an ACL based authorization provider that evaluates rules that comprise<br /> of username, groups and ip addresses.</p></div><div class="section"><h2>Audit<a name="Audit"></a></h2><p>The ability to determine what actions were taken by whom during some period of time is provided by the auditing<br /> capabilities of the Knox Gateway. The facility is built on an extension of the Log4j framework and may be extended<br /> by replacing the out of the box implementation with another.</p></div>
</div>
</div>
<div class="clear">
Modified: knox/trunk/src/site/markdown/index.md
URL: http://svn.apache.org/viewvc/knox/trunk/src/site/markdown/index.md?rev=1586859&r1=1586858&r2=1586859&view=diff
==============================================================================
--- knox/trunk/src/site/markdown/index.md (original)
+++ knox/trunk/src/site/markdown/index.md Sat Apr 12 14:53:52 2014
@@ -44,6 +44,53 @@ provides the enterprise with a solution
+Overview
+------------
+The Knox API Gateway is designed as a reverse proxy with consideration for pluggability in the areas of<br/>
+policy enforcement, through providers and the backend services for which it proxies requests.
+Policy enforcement ranges from authentication/federation, authorization, audit, dispatch, hostmapping<br/>
+and content rewrite rules. Policy is enforced through a chain of providers that are defined within the topology<br/>
+deployment descriptor for each Hadoop cluster gated by Knox. The cluster definition is also defined<br/>
+within the topology deployment descriptor and provides the Knox Gateway with the layout of the Hadoop<br/>
+cluster for purposes of routing and translation between user facing URLs and Hadoop cluster internals.
+Each Hadoop cluster that is protected by Knox has its set of REST APIs represented by a single cluster specific<br/>
+application context path. This allows the Knox Gateway to both protect multiple Hadoop clusters and present<br/>
+the REST API consumer with a single endpoint for access to all of the Hadoop services required, across the<br/>
+multiple clusters.
+Authentication
+------------
+Providers with the role of authentication are responsible for collecting credentials presented by the API<br/>
+consumer, validating them and communicating the successful or failed authentication to the client or the<br/>
+rest of the provider chain.
+
+Out of the box, the Knox Gateway provides the Shiro authentication provider. This is a provider that leverages<br/>
+the Apache Shiro project for authenticating BASIC credentials against an LDAP user store. There is support for<br/>
+OpenLDAP, ApacheDS and Microsoft Active Directory.
+
+Federation/SSO
+------------
+For customers that require credentials to be presented to a limited set of trusted entities within the enterprise,<br/>
+the Knox Gateway may be configured to federate the authenticated identity from an external authentication event.<br/>
+This is done through providers with the role of federation. The out of the box federation provider is a simple<br/>
+mechanism for propagating the identity through HTTP Headers that specify the username and group for the authenticated<br/>
+user. This has been built with vendor usecases such as SiteMinder and IBM Tivoli Access Manager.
+
+Service Level Authorization
+------------
+The authorization role is used by providers that make access decisions for the requested resources based on the<br/>
+effective user identity context. This identity context is determined by the authentication provider and the identity<br/>
+assertion provider mapping rules. Evaluation of the identity context's user and group principals against a set of<br/>
+access policies is done by the authorization provider in order to determine whether access should be granted to<br/>
+the effective user for the requested resource.
+
+Out of the box, the Knox Gateway provides an ACL based authorization provider that evaluates rules that comprise<br/>
+of username, groups and ip addresses.
+
+Audit
+------------
+The ability to determine what actions were taken by whom during some period of time is provided by the auditing<br/>
+capabilities of the Knox Gateway. The facility is built on an extension of the Log4j framework and may be extended<br/>
+by replacing the out of the box implementation with another.
\ No newline at end of file