cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache CXF > Fediz Architecture
Date Fri, 08 Jun 2012 22:23:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/15/_/styles/combined.css?spaceKey=CXF&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/CXF/Fediz+Architecture">Fediz
Architecture</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~owulff@apache.org">Oliver
Wulff</a>
    </h4>
        <br/>
                         <h4>Changes (1)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >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&#39;t mandate the usage of SAML token to carry this information. <br>Role
based Access Control (RBAC) is a subet of Claims based Access Control. The roles of a user/subject
is just a claim statement. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">
<br>h3. Resource and Requestor IDP <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="FedizArchitecture-FedizArchitecture"></a>Fediz Architecture</h1>
<p>This page describes the security architecture for WS-Federation and the message flow
between the components in detail.<br/>
The scope of Fediz is illustrated in the next section.</p>

<h3><a 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/>
The IDP component leverages the STS capabilities to issue all sorts of security tokens.<br/>
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="image-wrap" style="display: block; text-align: center"><img
src="/confluence/download/attachments/27849062/Fediz_Highlevel.png?version=1&amp;modificationDate=1339193808000"
style="border: 0px solid black" /></span></p>


<p>Fediz provides the following components to implement Web SSO based on WS-Federation
(red background):</p>
<ul>
	<li><b>Federation Plugin for RP</b><br/>
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><b>IDP / STS</b><br/>
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><b>Examples</b><br/>
Fediz ships examples to illustrate how to protect a web application.</li>
</ul>



<h3><a name="FedizArchitecture-WSFederationMessageflow"></a>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="image-wrap" style="display: block; text-align: center"><img
src="/confluence/download/attachments/27849062/Fediz_Detailed.png?version=1&amp;modificationDate=1339193808000"
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’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>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>


<h3><a name="FedizArchitecture-Components"></a>Components</h3>

<h5><a name="FedizArchitecture-WSTrustSecurityTokenService%28STS%29"></a>WS-Trust
Security Token Service (STS)</h5>
<p>The <a href="http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html"
class="external-link" 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/>
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/>
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 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>

<h3><a 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/>
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 name="FedizArchitecture-ResourceandRequestorIDP"></a>Resource and
Requestor IDP</h3>

    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/CXF/Fediz+Architecture">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=27849062&revisedVersion=2&originalVersion=1">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/CXF/Fediz+Architecture?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message