knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lmc...@apache.org
Subject svn commit: r1586859 - in /knox: site/index.html trunk/src/site/markdown/index.md
Date Sat, 12 Apr 2014 14:53:53 GMT
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 
 
 ![alt text](http://knox.apache.org/images/knox-overview.gif "Overview")
 
+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



Mime
View raw message