Thu, Mar 3, 2005
RSA have four patents that seem to overlap with parts of SAML: ”…RSA believed that these four patents could be relevant to practicing certain operational modes of the OASIS Security Assertion Markup Language (“SAML”) specifications…”
for “…certain operational modes…” read Profiles. The main point of the license is if you use SAML to implement the Browser/POST profile.
What’s not clear is if Guanxi is affected in that it uses SAMUEL, SAML UsEd in eLearning, which is an alternative to openSAML, i.e. it’s an open source implementation of the SAML 1.1. core spec. According to RSA, the core spec isn’t affected, it’s just the profiles and in particular, the Browser/POST profile.
The Guanxi implementation of the shibboleth protocol will need a license though, as it uses the Browser/POST profile, which is core to shibboleth. Phase II of Guanxi shouldn’t need a license as we’re going down to the wire and using SOAP. The domain suffix profile is not part of SAML and therefore does not incur an RSA license.
”…in the event that a Licensed Product is a product (such as a toolkit product or operating system service) that is used to develop other products, the license will require the licensee of the RSA Patents to notify users of the Licensed Products that such users must obtain a license directly from RSA…”
We would have needed a license in any case for the Guanxi implementation of the shibboleth protocol, even if we didn’t use SAMUEL, as we need to implement the Browser/POST profile for shibboleth compliance.
So how does this affect shibboleth? As users of the default Internet2 implementation of the shibboleth protocol, we don’t need any licenses as Internet2 have already obtained enough licenses to cover their development work. Remember, it’s only developers that are really affected by this. If you download, install and run a default Internet2 shibboleth implementation, then you’re OK. You’re alright Jack!
If, on the other hand, you’re an open source developer who wants to add SAML functionality to your open source application, then you must obtain an RSA license, if you stray into the RSA affected profiles, such as Browser/POST.
So, our bewildered open source developer gets SAMUEL, gets an RSA license and develops an application for single sign-on (SSO). Everyone who uses that SSO application is fine. No license requirements. He can go make a pot of tea and relax while his users get on with using his application.
A year later, he decides he wants to put a web services interface on the SSO application. Suddenly it’s a toolkit and everyone who develops against his WSDL will require an RSA license. He’ll have to put the WSDL behind a license requirement page.
In summary, I think if you develop an implementation of the SAML core, i.e. SAMUEL, to allow applications to do SAML things, such as compose and interpret SAML messages, then you’re fine. Also, if you use SAMUEL in an application that doesn’t use any of the RSA affected SAML profiles, you’re still ok. The trouble starts when you use profiles such as Browser/POST, then you need a license and if you expose such an application as a toolkit, then developers who use that toolkit will also require a license and you have to tell them they do. You don’t have to ensure they get one though.
So what future for SAML in an open source world?
In the words of Mr Hamilton in the “Waldorf Salad” episode of “Fawlty Towers”:
“What a pile of crap”