cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: FEDIZ container agnostic configuration
Date Thu, 22 Mar 2012 13:41:20 GMT
+1 - sounds good. Oli, how about we try to come up with a roadmap for
Fediz and discuss how to get it out of the sandbox, and where it
should go?

Colm.

On Thu, Mar 22, 2012 at 12:03 PM, Oliver Wulff <owulff@talend.com> wrote:
> Hi Juerg
>
> I'd like to make a proposal for the configuration to be able to support newer versions
of ws-federation or support other protocols like SAML-P or OAuth.
>
> Some parts are generic like trusted certificates, clock sqew, etc. I introduced the element
"protocol" which is an abstract type where we have right now only one sub type "FederationProtocol".
This is the extension point to support other protocols.
> I'd like to note also that some federation parameters might be known at deployment time
some others might be evaluated at request time. I've already used the Java callbackhandler
mechanism to evaluate the value at request time.
>
> <fediz>
>    <context name=String>
>        <audienceUris> ... </audienceUris>
>        <certificateValidation mode="PeerTrust|ChainTrust"> ... </certificateValidation>
>        <trustedIssuers> ... </trustedIssuers>   <!-- IDP/IP certs
-->
>        <maximumClockSkew> ... </maximumClockSkew>
>        <serviceCertificate> ... </serviceCertificate>    <!-- if
token is encrypted -->
>        <protocol xsi:type="FederationProtocol>
>            <version/>
>            <authenticationType type="string|Class"/>     <!-- maps to
wauth -->
>            <freshness/>   <!-- maps to wfresh -->
>            <homeRealm type="string|Class"/>   <!-- maps to whr -->
>            <realm/>  <!-- maps to wtrealm -->
>            <reply/>  <!-- maps to wreply -->
>            <request/>  <!-- maps to wreq -->
>            <claimTypeRequested>
>                <claimType type="" optional="true|false" />
>            </claimTypeRequested>
>            <securityTokenValidators> ... </securityTokenValidators>
>        </protocol>
>    </context>
> </fediz>
>
>
> What do you think?
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> Von: Oliver Wulff [owulff@talend.com]
> Gesendet: Mittwoch, 21. März 2012 13:02
> Bis: users@cxf.apache.org
> Betreff: AW: FEDIZ container agnostic configuration
>
> Hi Juerg
>
> That's a good improvement as it reduces the amount of container specific code. This would
also allow to move the creation of the redirect URL to the FederationProcessorImpl.
>
> I do have on my todo list to support publishing the WS-Federation Metadata document.
This could be moved to fediz-core too as it is mainly based on the configuration file.
>
> You can raise a JIRA for the "services" component of CXF (https://issues.apache.org/jira/browse/CXF)
and attach the patch there (svn diff) or attach the patch in this mail thread.
>
> Thanks a lot.
>
> Oli
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> Von: Juerg Portmann [juerg.portmann@gmail.com]
> Gesendet: Mittwoch, 21. März 2012 11:05
> Bis: users@cxf.apache.org
> Betreff: FEDIZ container agnostic configuration
>
> Hi all
>
> At the moment all configuration is within the fediz-tomcat module ant thus
> has to be implemented for each container separately.
> I would propose to extract the common configuration part into an xml based
> configuration bean and move this to the fediz-core module.
> As addition, the configuration should be able to provide values for
> different target url's to add the possibility to support different scopes
> (container level, servlet context)
>
> I would like to contribute this functionality, what is the best approach to
> do so ?
>
> - Juerg



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message