Author: buildbot
Date: Mon Jul 6 16:47:26 2015
New Revision: 957242
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/main.pageCache
websites/production/cxf/content/fediz-architecture.html
Modified: websites/production/cxf/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/fediz-architecture.html
==============================================================================
--- websites/production/cxf/content/fediz-architecture.html (original)
+++ websites/production/cxf/content/fediz-architecture.html Mon Jul 6 16:47:26
2015
@@ -99,68 +99,7 @@ Apache CXF -- Fediz Architecture
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="FedizArchitecture-FedizArchitecture">Fediz
Architecture</h1>
-<p>This page describes the security architecture for WS-Federation and the
message flow between the components in detail.<br clear="none">
-The scope of Fediz is illustrated in the next section.</p>
-
-<h3 id="FedizArchitecture-WS-FederationDesign">WS-Federation Design</h3>
-
-<p>The following picture illustrates the main components of a Web Single Sign
On (SSO) solution based on <a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html";
rel="nofollow">WS-Federation</a> (<a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002";
rel="nofollow">Passive Requestor Profile</a>). The Web Application is part of
the Relying Party (RP) side whereas the Identity Provider (IDP/STS) is the
central security server that is responsible to authenticate clients and issue
security tokens based on the requirements by the RP.<br clear="none">
-The IDP component leverages the STS capabilities to issue all sorts of
security tokens.<br clear="none">
-An browser first access the Web Application (RP) which redirects the browser
to the IDP as the requestor is not authenticated. The IDP authenticates the
user and requests a security token based on the requirements by the RP. The
security token is "redirected" to the RP which validates the token and creates
a session in the RP.</p>
-
-
-<p><span class="confluence-embedded-file-wrapper image-center-wrapper"><img
class="confluence-embedded-image image-center"
src="fediz-architecture.data/Fediz_Highlevel.png"></span></p>
-
-
-<p>Fediz provides the following components to implement Web SSO based on
WS-Federation (red background):</p>
-<ul><li><strong>Federation Plugin for RP</strong><br clear="none">
-The plugin consists of two Fediz libraries. The core processing logic is
within a container independent library. In addition, a library is provided for
each container to adapt the core library to the container specific security
API.</li></ul>
-
-
-<ul><li><strong>IDP / STS</strong><br clear="none">
-The IDP / STS leverages the Apache CXF STS. Fediz ships a fully configured IDP
where users/claims are managed in files. The IDP can be configured to integrate
an LDAP directory.</li></ul>
-
-
-<ul><li><strong>Examples</strong><br clear="none">
-Fediz ships examples to illustrate how to protect a web application.</li></ul>
-
-
-
-<h3 id="FedizArchitecture-WS-FederationMessageflow">WS-Federation Message
flow</h3>
-
-<p>This section describes and illustrates the message flow between the browser
and the application and IDP in more detail.</p>
-
-
-<p><span class="confluence-embedded-file-wrapper image-center-wrapper"><img
class="confluence-embedded-image image-center"
src="fediz-architecture.data/Fediz_Detailed.png"></span></p>
-
-
-<p>The browser accesses the web application (1). It is then redirected to
IDP/STS if no token or cookie is supplied in the request (2). This redirection
process may require prompting the user (3) to authenticate himself (4). The
IDP/STS issues a signed SAML 2.0 security token (WS-Federation doesn’t
mandate <a shape="rect" class="external-link"
href="http://saml.xml.org/saml-specifications"; rel="nofollow">SAML</a>). The
IDP "redirects" (5/6) the user to the application server including the SAML
token. The application server verifies the signature of the SAML token. There
is a trust relationship between the application server and the IDP/STS which
doesn't require network connectivity between the application server and the
IDP/STS (Cloud!). After successful validation, a session is created and the
corresponding cookie is set on the browser (7). Finally, the request is
dispatched to the application.</p>
-
-<p>As an extension to the description above, step 2 might contain specific
claims requested by the application such as role, username, full name, email
address, sales organization, etc. which are gathered by the STS.</p>
-
-<p>Requirements of the Web Application are described in the <a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223174943";
rel="nofollow">WS-Federation Metadata</a> document.</p>
-
-
-<h3 id="FedizArchitecture-Components">Components</h3>
-
-<h5 id="FedizArchitecture-WS-TrustSecurityTokenService(STS)">WS-Trust Security
Token Service (STS)</h5>
-<p>The <a shape="rect" class="external-link"
href="http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html";
rel="nofollow">WS-Trust OASIS standard</a> specifies a runtime component
called Security Token Service. A service consumer requests a security token
from the STS which is sent to the service provider. Either the service provider
can validate the security token on its own or sends a request to the STS for
validation. This pattern is based on an indirect trust relationship between the
service provider and the STS instead of a direct trust between the service
provider and service consumer. As long as the service consumer is in the
possession of a security token issued by a trusted STS, the service provider
accepts this security token.</p>
-
-<p>A key benefit of the STS is the reduced complexity for applications. A web
service consumer doesn't have to know how to create the various types of
security tokens its service providers require. Instead, it sends a request to
the STS containing the requirements of the client and the service provider and
attaches the returned security token to the outgoing SOAP message to the
service provider.<br clear="none">
-One service provider could require a SAML 1.1 token, another SAML 2.0 token
and another custom binary security token. The service consumer doesn't have to
understand SAML 1.1, SAML 2.0 or the custom binary security token. All he has
to do is grab the returned token from the STS and attach it to the message.
Thus, you can reduce the complexity in your application and move it to a
centralized component.<br clear="none">
-A web service consumer requests tokens from an STS if the service provider
defines an IssuedToken assertion in its security policy. This policy can
contain some additional information like the address of the STS, token type,
claims, etc.</p>
-
-<h5 id="FedizArchitecture-Identityprovider(IDP)">Identity provider (IDP)</h5>
-<p>The security model of the STS builds on the foundation established by
WS-Security and WS-Trust. The primary issue for Web browsers is that there is
no easy way to directly send web service (SOAP) requests. Consequently, the
processing must be performed within the confines of the base HTTP 1.1
functionality (GET, POST, redirects, and cookies) and conform as closely as
possible to the WS-Trust protocols for token acquisition.<br clear="none">
-The IDP is in charge of transforming the SignIn request of the browser to a
SOAP request for the STS and the response of the STS to the SignInResponse for
the browser. Further the browser user must authenticate himself with the IDP.
At the time of initial authentication an artifact/cookie may be created for the
browser so that every request for a resource doesn't require user
interaction.</p>
-
-<h3 id="FedizArchitecture-ClaimsbasedAccessControl">Claims based Access
Control</h3>
-<p>A claim is a statement made about a client. The concept of claim is
described in the WS-Trust specification. Claims information of an authenticated
subject can ba carried in a Attribute Statement of a SAML token even WS-Trust
doesn't mandate the usage of SAML token to carry this information.<br
clear="none">
-Role based Access Control (RBAC) is a subet of Claims based Access Control.
The roles of a user/subject is just a claim statement.</p>
-
-<h3 id="FedizArchitecture-ResourceandRequestorIDP">Resource and Requestor
IDP</h3>
-<p>tbd</p></div>
+<div id="ConfluenceContent"><h1 id="FedizArchitecture-FedizArchitecture">Fediz
Architecture</h1><p>This page describes the security architecture for
WS-Federation and the message flow between the components in detail.<br
clear="none"> The scope of Fediz is illustrated in the next section.</p><h3
id="FedizArchitecture-WS-FederationDesign">WS-Federation Design</h3><p>The
following picture illustrates the main components of a Web Single Sign On (SSO)
solution based on <a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html";
rel="nofollow">WS-Federation</a> (<a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002";
rel="nofollow">Passive Requestor Profile</a>). The Web Application is part of
the Relying Party (RP) side whereas the Identity Provider (IDP/STS) is the
central security server that is responsible to authenticate clients an
d issue security tokens based on the requirements by the RP.<br clear="none">
The IDP component leverages the STS capabilities to issue all sorts of security
tokens.<br clear="none"> An browser first access the Web Application (RP) which
redirects the browser to the IDP as the requestor is not authenticated. The IDP
authenticates the user and requests a security token based on the requirements
by the RP. The security token is "redirected" to the RP which validates the
token and creates a session in the RP.</p><p><span
class="confluence-embedded-file-wrapper image-center-wrapper"><img
class="confluence-embedded-image image-center"
src="fediz-architecture.data/Fediz_Highlevel.png"></span></p><p>Fediz provides
the following components to implement Web SSO based on WS-Federation (red
background):</p><ul><li><strong>Federation Plugin for RP</strong><br
clear="none"> The plugin consists of two Fediz libraries. The core processing
logic is within a container independent library. In additio
n, a library is provided for each container to adapt the core library to the
container specific security API.</li></ul><ul><li><strong>IDP / STS</strong><br
clear="none"> The IDP / STS leverages the Apache CXF STS. Fediz ships a fully
configured STS where users/claims are managed in files. The STS can be
configured to integrate an LDAP
directory.</li></ul><ul><li><strong>Examples</strong><br clear="none"> Fediz
ships examples to illustrate how to protect a web application.</li></ul><h3
id="FedizArchitecture-WS-FederationMessageflow">WS-Federation Message
flow</h3><p>This section describes and illustrates the message flow between the
browser and the application and IDP in more detail.</p><p><span
class="confluence-embedded-file-wrapper image-center-wrapper"><img
class="confluence-embedded-image image-center"
src="fediz-architecture.data/Fediz_Detailed.png"></span></p><p>The browser
accesses the web application (1). It is then redirected to IDP/STS if no token
or cookie is supplied in
the request (2). This redirection process may require prompting the user (3)
to authenticate himself (4). The IDP/STS issues a signed SAML 2.0 security
token (WS-Federation doesn’t mandate <a shape="rect"
class="external-link" href="http://saml.xml.org/saml-specifications";
rel="nofollow">SAML</a>). The IDP "redirects" (5/6) the user to the application
server including the SAML token. The application server verifies the signature
of the SAML token. There is a trust relationship between the application server
and the IDP/STS which doesn't require network connectivity between the
application server and the IDP/STS (Cloud!). After successful validation, a
session is created and the corresponding cookie is set on the browser (7).
Finally, the request is dispatched to the application.</p><p>As an extension to
the description above, step 2 might contain specific claims requested by the
application such as role, username, full name, email address, sales
organization, etc. which are g
athered by the STS.</p><p>Requirements of the Web Application are described in
the <a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223174943";
rel="nofollow">WS-Federation Metadata</a> document.</p><h3
id="FedizArchitecture-Components">Components</h3><h5
id="FedizArchitecture-WS-TrustSecurityTokenService(STS)">WS-Trust Security
Token Service (STS)</h5><p>The <a shape="rect" class="external-link"
href="http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html";
rel="nofollow">WS-Trust OASIS standard</a> specifies a runtime component
called Security Token Service. A service consumer requests a security token
from the STS which is sent to the service provider. Either the service provider
can validate the security token on its own or sends a request to the STS for
validation. This pattern is based on an indirect trust relationship between the
service provider and the STS instead of a direc
t trust between the service provider and service consumer. As long as the
service consumer is in the possession of a security token issued by a trusted
STS, the service provider accepts this security token.</p><p>A key benefit of
the STS is the reduced complexity for applications. A web service consumer
doesn't have to know how to create the various types of security tokens its
service providers require. Instead, it sends a request to the STS containing
the requirements of the client and the service provider and attaches the
returned security token to the outgoing SOAP message to the service
provider.<br clear="none"> One service provider could require a SAML 1.1 token,
another SAML 2.0 token and another custom binary security token. The service
consumer doesn't have to understand SAML 1.1, SAML 2.0 or the custom binary
security token. All he has to do is grab the returned token from the STS and
attach it to the message. Thus, you can reduce the complexity in your
application and mo
ve it to a centralized component.<br clear="none"> A web service consumer
requests tokens from an STS if the service provider defines an IssuedToken
assertion in its security policy. This policy can contain some additional
information like the address of the STS, token type, claims, etc.</p><h5
id="FedizArchitecture-Identityprovider(IDP)">Identity provider (IDP)</h5><p>The
security model of the STS builds on the foundation established by WS-Security
and WS-Trust. The primary issue for Web browsers is that there is no easy way
to directly send web service (SOAP) requests. Consequently, the processing must
be performed within the confines of the base HTTP 1.1 functionality (GET, POST,
redirects, and cookies) and conform as closely as possible to the WS-Trust
protocols for token acquisition.<br clear="none"> The IDP is in charge of
transforming the SignIn request of the browser to a SOAP request for the STS
and the response of the STS to the SignInResponse for the browser. Further the
browser user must authenticate himself with the IDP. At the time of initial
authentication an artifact/cookie may be created for the browser so that every
request for a resource doesn't require user interaction.</p><h3
id="FedizArchitecture-ClaimsbasedAccessControl">Claims based Access
Control</h3><p>A claim is a statement made about a client. The concept of claim
is described in the WS-Trust specification. Claims information of an
authenticated subject can ba carried in a Attribute Statement of a SAML token
even WS-Trust doesn't mandate the usage of SAML token to carry this
information.<br clear="none"> Role based Access Control (RBAC) is a subet of
Claims based Access Control. The roles of a user/subject is just a claim
statement.</p><h3 id="FedizArchitecture-ResourceandRequestorIDP">Resource and
Requestor IDP</h3><p>tbd</p></div>
</div>
<!-- Content -->
</td>
