cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r821227 - in /websites/production/cxf/content: cache/main.pageCache fediz-architecture.html fediz.html
Date Mon, 11 Jun 2012 07:48:53 GMT
Author: buildbot
Date: Mon Jun 11 07:48:52 2012
New Revision: 821227

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/main.pageCache
    websites/production/cxf/content/fediz-architecture.html
    websites/production/cxf/content/fediz.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 Jun 11 07:48:52 2012
@@ -142,7 +142,7 @@ The scope of Fediz is illustrated in the
 
 <h3><a shape="rect" name="FedizArchitecture-WSFederationDesign"></a>WS-Federation
Design</h3>
 
-<p>The following picture illustrates the main components of a Web Single Sign On (SSO)
solution based on WS-Federation (Passive Requestor Profile). 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">
+<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>
 
@@ -172,11 +172,11 @@ Fediz ships examples to illustrate how t
 <p><span class="image-wrap" style="display: block; text-align: center"><img
src="fediz-architecture.data/Fediz_Detailed.png" style="border: 0px solid black"></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&#8217;t mandate SAML). 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>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&#8217;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 WS-Federation Metadata
document.</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><a shape="rect" name="FedizArchitecture-Components"></a>Components</h3>
@@ -189,14 +189,15 @@ One service provider could require a SAM
 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><a shape="rect" name="FedizArchitecture-Identityprovider%28IDP%29"></a>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.</p>
+<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><a shape="rect" name="FedizArchitecture-ClaimsbasedAccessControl"></a>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><a shape="rect" name="FedizArchitecture-ResourceandRequestorIDP"></a>Resource
and Requestor IDP</h3>
-</div>
+<p>tbd</p></div>
            </div>
            <!-- Content -->
          </td>

Modified: websites/production/cxf/content/fediz.html
==============================================================================
--- websites/production/cxf/content/fediz.html (original)
+++ websites/production/cxf/content/fediz.html Mon Jun 11 07:48:52 2012
@@ -145,7 +145,6 @@ Apache CXF -- Fediz
 
 <h2><a shape="rect" name="Fediz-News"></a>News</h2>
 
-
 <h2><a shape="rect" name="Fediz-Features"></a>Features</h2>
 
 <p>The following features are supported by the Fediz plugin 1.0</p>
@@ -158,6 +157,11 @@ Apache CXF -- Fediz
 
 <p>You can get the current status of the enhancements <a shape="rect" class="external-link"
href="https://issues.apache.org/jira/browse/FEDIZ">here </a>.</p>
 
+<h2><a shape="rect" name="Fediz-Architecture"></a>Architecture</h2>
+
+<p>The Fediz architecture is described in more detail <a shape="rect" href="fediz-architecture.html"
title="Fediz Architecture">here</a>.</p>
+
+
 <h2><a shape="rect" name="Fediz-Gettingstarted"></a>Getting started</h2>
 
 <p>The WS-Federation specification defines the following parties involved during a
web login:</p>



Mime
View raw message