the pl seam project needs to be updated to use the 2.0.1.final branch given that is the current release.
fixed in trunk...
Thanks, I'm pulling down 2.0.1 and the seam trunk now. I'll let you know how it goes.
On a somewhat related issue - The SEAM project allows for multi-homed applications to be handled properly in the way the SAML Request/Response is built. You can define multiple domains that the SP request can come from and based on the domain of the original request it will use a defined IDP and return the user to the original URL they requested. Is there any plan to support this on the base project?
For example we have a VIP called myserver.mycompany.com which is made up of myserver01.mycompany.com and myserver02.mycompany.com
If in picketlink-idfed.xml I have
And then I point the browser at myserver01.mycompany.com, it will post to the IDP, but then return to the VIP myserver.mycompany.com. Thus when we want to verify something on a particular server it can be problematic. A similar issue will arise when the user is coming from a specific path instead of being returned to that path after loging they would be returned to the root. I believe the SEAM implementation gets around this by storing the original URL in the session and redirecting to that URL after the SAMLResponse is processed.
basically we can now inject configuration providers. I have not documented it perfectly. I envision people pulling configuration from DB or custom classes to replace the default configuration behavior in PL.
Sorry, took me a while to get the time to go back and look through the implementation of this. I'm having trouble locating where the context of the current request (or at minimum the hostname for the request) is passed through to the configuration or the SPType returned to choose the proper idp/sp urls for the current request. In the SEAM implementation they do this in the org.picketlink.identity.seam.federation.configuration.getServiceProvider(String hostname) call but that seems to be done outside the SAMLConfigurationProvider framework. In the BaseFormAuthenticator, which doesn't seem to be overridden in the SPPostFormAuthenticator, the serviceUrl and identityUrl both seem to be single values. Let me know if I'm missing something.