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 <[email protected]> > 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 [[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 >
