You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Francisco Serrano <fr...@mimacom.com> on 2012/01/20 19:34:33 UTC
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.
Re: IDP resolver feature
Posted by Francisco Serrano <fr...@mimacom.com>.
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.serrano@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 [owulff@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.serrano@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.
>>
>>
>
>
>
AW: IDP resolver feature
Posted by Oliver Wulff <ow...@talend.com>.
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.serrano@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 [owulff@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.serrano@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.
>
>
Re: IDP resolver feature
Posted by Francisco Serrano <fr...@mimacom.com>.
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 [owulff@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.serrano@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.
>
>
AW: IDP resolver feature
Posted by Oliver Wulff <ow...@talend.com>.
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 [owulff@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.serrano@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.
AW: IDP resolver feature
Posted by Oliver Wulff <ow...@talend.com>.
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.serrano@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.