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 [[email protected]]
Gesendet: Mittwoch, 21. März 2012 13:02
Bis: [email protected]
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 [[email protected]]
Gesendet: Mittwoch, 21. März 2012 11:05
Bis: [email protected]
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
