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 [[email protected]]
Gesendet: Mittwoch, 25. Januar 2012 08:11
Bis: [email protected]
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 [[email protected]]
Gesendet: Freitag, 20. Januar 2012 19:34
Bis: [email protected]
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.
