Shibboleth is part of SAMLv2. If you are talking about the Shibboleth implementation from Internet2, then we do not immediately have any plans of integrating it.
That was the implementation that I was referring to yes.
Do you have a need for shibboleth? Are you in the educational domain?
I am just curious.
Yes we are - we write MIS software for schools and are in the process of migrating all our production systems from WebSphere to JBoss4.
Longer term requirements are for Shibboleth integration to enable SSO across multiple applications and this project seemed the ideal starting point and if it had covered Shibboleth would have been a real bonus and enabled some quick wins.
I have not had the time to play with Shibb implementation yet. Someday, if I am able to deploy a working shib on JBossAS, then I can blog or write more on it.
I too have plans to use Shibboleth as my IdP. I am not an educational user, I work at a government laboratory. We plan to use Shibboleth as the global IdP for all our internal servers and for access to external partner sites (some of which may be educational establishments)
My initial experiments with SAML2 technology indicates that:
- PicketLink works fine - if you use the PicketLink IdP
- WebLogic's SAML2 works fine - if you use the WebLogic IdP
- Shibboleth's SP works fine - if you use the Shibboleth IdP
- OIOSAML works fine - if you use Shibboleth as the IdP (hey, that's two hits for Shibboleth!)
And the problem is that several of those "if's" are actually "but only if's" (I haven't tested every combination!)
I do not understand why this should be so. Perhaps I am being a little naive here, but isn't SAML2 an interoperability standard? In the ideal world shouldn't I be able to use *any* SAML2 SP with *any* SAML2 IdP? It would be absurd if I had to use different IdP's for different types of SP's around the lab.
In fact, from that point of view I would semi-seriously suggest that you would do better to stop working on the PicketLink IdP since there are others (like Shibboleth) that are free, open source, flexible, reliable, widely used, and try very hard to adhere to the SAML2 protocol standard. (In fact one of the authors of the SAML2 standard works on Shibboleth at Internet2.)
What I would *really* love is for PicketLink to be a way to make JBossAS into a SAML2 compliant SP in such a way that it is transparent to the applications inside it (assuming that they are written to J2EE standard and use the container for authentication and authorization). I think that you are already a long way towards that goal, but I think that the SAML2 compliance is currently lacking. (I know, it all takes time!)
For the short term, as I have said above, I would dearly love to use PicketLink to act as the SP interface for our JBoss application servers, but my initial attempt resulted in an error message from Shibboleth saying that "No providerId parameter given in Shibboleth SSO authentication request". Have I missed defining the identifying URI for the SP somewhere? Looking around I can't see where it could be specified.
If I seem a bit critical, I apologize. I think I'm just a bit frustrated at all these compatibility problems! I think that PicketLink shows a great deal of promise.
I agree with you that PicketLink should be more focussed on integrating with other IDP's and SP's.
But it's not that we didn't pay attention to interoperability at all. I did lots of integration testing between the PicketLink Seam module (SP) and Sun's OpenSSO IDP. After fixing a lot of interoperability problems, I got it working:
In fact, I used OpenSSO more than the PicketLink IDP, when testing the Seam module. Unfortunately, that doesn't help you if your applications are not Seam applications, and if your IDP is not OpenSSO. I didn't realize that Shibboleth is an open source product that I can just download and play around with. I hope to find time to do that in the near future.
No, of course I'm not suggesting that you (nor the rest of the team) have ignored interoperability. If it looked that way then again I apologize for my crankiness born of frustration. I really do think that using PicketLink at the Valve level in JBoss would be an ideal solution for many people (including me).
But for the short term, since you have had experience with other IdP's, perhaps you could help me with my immediate PicketLink/Shibboleth difficulty.
It seems that Shibboleth is complaining that the authentication request does not contain the SP's identifier. It is my understanding that all SAML2 SP's and IdP's are required to have such an identifier (an arbitrary URI) but I have not seen it in PicketLink. Is there a place where I can specify this identifier? And if I do will it then be sent to the IdP?
Sorry, I can't help you with the valve-level PicketLink service providers. I didn't use them for a long time. I'm sure there will be other guys at this forum that know how to use them.
Nick, I support your frustration.
My vision is highlighted in : https://community.jboss.org/wiki/PicketLinkArchitectures
I work with the Shibboleth people on the Oasis SAML Technical Committee and I sometime answer questions on the opensaml user mailing list. They are absolutely wonderful people and shibboleth is great adoption wise and history.
We are slowly inching toward making JBAS SAML aware. I mean we have lots of pieces currently to make that happen. As you know, we do have the JBAS bindings for PL.
We have not really done explicit interoperability tests with shibboleth IDP. This is where community members (such as Marcel and you) come to this open source project's rescue.
The number of context switches my team and I do on a daily basis will only prolong this interoperability exercize. In an ideal world, we would be doing this interoperability exercise often but we are far from that.
I strongly suggest checking out the PL source code, fire up your IDE of your choice and see what is the real problem and feed us bugs/requests etc. If you are interested in taking charge, your commit rights will not be too far. Marcel tresspassed on our forums and we punished him with commit rights and he has provided great features to our project.
This is a community project. An open source project, just like shibboleth is. You are free to bring over the source code of both projects and debug and see where the issues are.
I like the look of that vision.
I have checked out the source code, as you suggested. I'll take a look, but I'm not sure that I deserve to be punished as thoroughly as Marcel ;-)
As you suggested I downloaded the source code of PicketLink. By adjusting the settings of Shibboleth and by editing the code of PicketLink I am close to getting the SPFilter implementation of PicketLink to work with Shibboleth for SSO. (It's not my ideal solution, but I thought it might be the simplest place to start).
I am more than happy to contribute my code back to the community when I think it might be useful, but I confess that I am not sure quite how to do so. I haven't worked with an open-source project like this before. Should I perhaps send you a patch for each well-defined item along with a description of its intent?
good news. IYou made some fixes to the SPFilter such that it works with Shib IDP. Is that what you meant? If so, are you able to describe here what the fixes were and issues were?
We have no qualms in giving you commit rights, if you are in the right direction.
Yes, that's what I meant.
Here's a list of things I found and modified to the extent necessary to get my proof-of-concept to work, in no particular order...
I also noticed a couple of other things that are "bigger" and that I have not tried to address.
- In AssertionUtil the code applies a strict check to the time bounds in the "Condition" statement. This can (and did) cause failure because of clock skew, and some allowance for that should be made. (I checked with Scott Cantor that it is the SP, not the IdP, that should allow for clock skew).
- In SPFilter (and other places?) the "trace" variable that guards TRACE level debugging remains false, even when TRACE level debugging is active. (I didn't investigate too hard. May be related to the timing of the static logger initialization vs the reading of the log4j initialization file vs the non-static trace variable???)
- In SAML2AuthenticationHandler just after "Let us get the roles" the code assumes that the first statement is an AttributeStatement, but it need not be so. The statements should be searched to find the AttributeStatement.
- In the same part of the code, each attribute has its first element taken to be a role. It would seem more natural to look for a specific attribute (named "roles"?) and use all the values of that single attribute as the roles.
- In SPFilter, the ServletRequest object that is passed on to the application should be wrapped to override the isUserInRole(String) and other methods that may be used by the application. (The roles and other user information should probably be stored in the session).
- In SAML2AuthenticationHandler (around line 400) the code checks that the user has one of the configured roles. This is presumably a replacement for the "declarative security" that can not be used in the web.xml with filter-based security. (That is why I really want the Tomcat Valve-based version to work!) At some point it might be worth making the access URL-based, just like in the web.xml.
- I think that the code combines the concept of the "service URL" (the URL at which the application can be reached) with the "identification URI" (the unique URI identifier, not necessarily a URL, that all SAML2 IdP's and SP's must have). I am concerned that this might lead to confusion or awkwardness later, and would prefer that these concepts be kept quite distinct.
- Perhaps related to the previous point, I think that after the SAML-SSO negotiation the browser always ends up at the "service URL". It would be better if the user could go directly to any URL within the application.
- It would certainly be nice if PicketLink could read standard metadata from the IdP and supply its own metadata for the IdP. (I think Marcel has made a good start on this for the SEAM integration).
As I say, I am very willing to send patches for these items once I have them cleaned up.
If you want me to go and dive in to the repository directly then I hope you will be understanding and forgiving if I inadvertently break things!
Nick, thanks for the detailed post. Reading your post, I can concur that we need to beef up PL at points you have highlighted. Typically when we implement code, we try to take the "best approach at this current time" approach and usually leave enhancements to post-feedback phase. This may include assumptions that we make.
By the way,one of my objectives behind PL is to keep it as simple as possible and not make it a configuration maze. Toward this, our documentation may not be up to date with all the latest-and-greatest possible with picketlink.
If you send me a private message with your jboss.org username, I will grant you commit access. Once you have cleaned up your code, we can discuss ways by which you can commit the code.
Welcome to PicketLink as a committer.
By the way, Scott Cantor is a virtual god of SAML2.