Very nice Oli, thank you very much for the time espent. We'll try to integrate the new feature and give you a feedback ASAP.
Kind regards and have a nice weekend. Fran. El 03/02/2012, a las 13:27, Oliver Wulff escribió: > Hi Fran > > I've added this functionality here: > http://svn.apache.org/viewvc?view=revision&revision=1240127 > > Here is a sample callback handler: > > public class DummyIDPCallbackHandler implements CallbackHandler { > > public void handle(Callback[] callbacks) throws IOException, > UnsupportedCallbackException { > > for (int i = 0; i < callbacks.length; i++) { > if (callbacks[i] instanceof IDPCallback) { > IDPCallback pc = (IDPCallback) callbacks[i]; > pc.setIssuerUrl(new URL("https://localhost:9443/fedizidp/";)); > pc.setTrustedIssuer(".*CN=www.sts.com.*"); > break; > } > } > } > } > > You can configure the callback handler like this: > <Valve className="org.apache.cxf.fediz.tomcat.FederationAuthenticator" > issuerCallbackHandler="org.apache.cxf.fediz.tomcat.DummyIDPCallbackHandler" > truststoreFile="conf/stsstore.jks" truststorePassword="stsspass" /> > > > HTH > > Oli > > ------ > > Oliver Wulff > > http://owulff.blogspot.com > Solution Architect > Talend Application Integration Division http://www.talend.com > > ________________________________________ > Von: Francisco Serrano [francisco.serr...@mimacom.com] > Gesendet: Dienstag, 31. Januar 2012 15:58 > Bis: users@cxf.apache.org > Betreff: Re: IDP resolver feature > > Hi Oliver, great thanks, > > From my understanding this would let us to use it even before the IDP > resolution mechanism so we could gain even more control, right? > > I think this would be a good extension point as with the request we get with > the callback we could manage to do the redirect to the corresponding IDP > depending on the request URL. > > Is this correct? > > Thanks again Oliver. > > Fran. > > El 27/01/2012, a las 10:44, Oliver Wulff escribió: > >> Hi Fran >> >> What do you think about the following proposal? >> >> I'd like to use the callback api's provided by Java to add this extension >> point which means that you have to implement a CallbackHandler >> implementation. In the handle method you get a specific Callback object like >> this one: >> >>>>> >> import javax.security.auth.callback.Callback; >> import javax.servlet.http.HttpServletRequest; >> >> >> public class IDPCallback implements Callback { >> >> private HttpServletRequest request = null; >> private URL issuerUrl = null; >> private String trustedIssuer = null; >> >> public IDPCallback(HttpServletRequest request) { >> super(); >> this.request = request; >> } >> >> public IDPCallback(HttpServletRequest request, URL issuerUrl, >> String trustedIssuer) { >> super(); >> this.request = request; >> this.issuerUrl = issuerUrl; >> this.trustedIssuer = trustedIssuer; >> } >> >> public HttpServletRequest getRequest() { >> return request; >> } >> public void setRequest(HttpServletRequest request) { >> this.request = request; >> } >> public URL getIssuerUrl() { >> return issuerUrl; >> } >> public void setIssuerUrl(URL issuerUrl) { >> this.issuerUrl = issuerUrl; >> } >> public String getTrustedIssuer() { >> return trustedIssuer; >> } >> public void setTrustedIssuer(String trustedIssuer) { >> this.trustedIssuer = trustedIssuer; >> } >> >> } >>>>> >> >> Your custom callback handler could be implemented like this: >> >>>>> >> import java.io.IOException; >> >> import javax.security.auth.callback.Callback; >> import javax.security.auth.callback.CallbackHandler; >> import javax.security.auth.callback.UnsupportedCallbackException; >> >> >> public class DummyCallbackHandler implements CallbackHandler { >> >> public void handle(Callback[] callbacks) throws IOException, >> UnsupportedCallbackException { >> >> for (int i = 0; i < callbacks.length; i++) { >> if (callbacks[i] instanceof IDPCallback) { >> IDPCallback pc = (IDPCallback) callbacks[i]; >> >> //todo >> } >> } >> } >> } >>>>> >> >> The callback handler will be configured in the valve. >> >> What do you think? >> >> >> ------ >> >> Oliver Wulff >> >> http://owulff.blogspot.com >> Solution Architect >> Talend Application Integration Division http://www.talend.com >> >> ________________________________________ >> Von: Oliver Wulff [owu...@talend.com] >> Gesendet: Mittwoch, 25. Januar 2012 08:11 >> Bis: users@cxf.apache.org >> Betreff: AW: IDP resolver feature >> >> Hi Fran >> >> This is the so called "home realm discovery" mechanism which is usually >> deployed in the resource idp. I get back to you asap. This plugin mechanism >> can then be configured either in the relying party or within the resource >> idp. >> >> Thanks >> Oli >> >> >> ------ >> >> Oliver Wulff >> >> http://owulff.blogspot.com >> Solution Architect >> Talend Application Integration Division http://www.talend.com >> >> ________________________________________ >> Von: Francisco Serrano [francisco.serr...@mimacom.com] >> Gesendet: Freitag, 20. Januar 2012 19:34 >> Bis: users@cxf.apache.org >> Betreff: IDP resolver feature >> >> Hi List! >> >> Regarding the last post I wrote in this mailing list (two approaches for the >> IDP resolution depending on which application is asking for the token), I >> think it would be a great and "reusable" idea that the Tomcat plugin for the >> token processing and IDP redirection was able to be configured in a >> separated file, where you could write which IDP would be the correct to >> challenge the user depending on, for example, the pattern of the request URL. >> For example, if an application tries to access a secured resource like >> "http://www.mydomain.com/internal";, as "internal" is a substring of the >> requested URL, it would be resolved to IDP1, while for a request like >> "http://www.otherdomain.com/external"; would resolve against a second IDP. >> >> As a proposal, the valve could be configured referring an IDP resolver bean >> with all the mappings needed for the resolution. Given the default >> configuration in the valve: >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> <Context> <Valve >> className="org.apache.cxf.fediz.tomcat.FederationAuthenticator" >> issuerURL="https://localhost:9443/fedizidp/"; >> truststoreFile="conf/stsstore.jks" truststorePassword="thepass" trustedIssu >> er=".*CN=www.mydomain.com.*" /> </Context> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> An approach could be to have an extension point like being able to specify >> the "idpResolverConfig" instead of the issuerURL, and this idpResolverConfig >> would keep the information needed to to the appropiate redirect in another >> spring configuration xml file (for example): >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> <Context> <Valve >> className="org.apache.cxf.fediz.tomcat.FederationAuthenticator" >> idpResolverConfig ="conf/idpResolverMapping.xml" >> truststoreFile="conf/stsstore.jks" truststorePassword="thepass" trustedIssu >> er=".*CN=www.mydomain.com.*" /> </Context> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> Then, this idpResolverMapping.xml could look like this: >> >> <?xml version="1.0" encoding="UTF-8"?> >> <beans xmlns="http://www.springframework.org/schema/beans"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xmlns:util="http://www.springframework.org/schema/util"; >> xsi:schemaLocation=" >> http://www.springframework.org/schema/beans >> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd >> http://www.springframework.org/schema/util >> http://www.springframework.org/schema/util/spring-util-2.0.xsd";> >> >> <util:map id="idpMappings"> >> <entry key="/internal/*" >> value="http://idp1.mydomain.com"; /> >> <entry key="/external/*" >> value="http://idp2.mydomain.com"; /> >> </util:map> >> >> </beans> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> What do you think? >> >> Thanks in advance for any feedback on this subject. >> >> Kind regards, >> >> Fran. >> >> > > >
