You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Juerg Portmann <ju...@gmail.com> on 2012/03/21 11:05:12 UTC
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
Re: FEDIZ container agnostic configuration
Posted by Colm O hEigeartaigh <co...@apache.org>.
+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 <ow...@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
Re: FEDIZ container agnostic configuration
Posted by Juerg Portmann <ju...@gmail.com>.
Hi Oliver
Thanks a lot for your input. I will adapt my code based on this. Allow me
to suggest that we use the scope of element <fediz> to supply default
values for the <context> children.
What do you think ?
- Juerg
2012/3/22 Oliver Wulff <ow...@talend.com>
> 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
>
Re: AW: FEDIZ container agnostic configuration
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Oli,
On 22/03/12 12:03, Oliver Wulff 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?
Having protocol-specific configurations does look like a good idea.
As far as OAuth is concerned, I think even Fediz-WSFed or
Fediz-SAML-P/Redirect will work great with the OAuth runtime. Even though
OAuth has the redirection flows (ex, authorization code or implicit
flows in OAuth 2.0), those flows are to do with obtaining an authorized
grant from the end user. However, during those flows the end user does
need to authenticate both with the 3rd party client server (as in
authorization code flow) and with the resource server when redirected to
it by the client web app.
So Fediz SSO will work great in such cases, specifically when SSO is
required for improving the end user's experience. I wonder if I should
try the OAuth 2.0 demo with Fediz sooner rather than later...
OpenId, OpendId-Connect are other technologies often quoted alongside
OAuth (2.0). I'll have to look into them after 2.6.0 and see if it makes
sense to get Fediz 'involved'...
Thanks, Sergey
>
> ------
>
> 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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
AW: FEDIZ container agnostic configuration
Posted by Oliver Wulff <ow...@talend.com>.
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
AW: FEDIZ container agnostic configuration
Posted by Oliver Wulff <ow...@talend.com>.
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