[OpenSAML] OpenSAML 1 to 2 transition
Alexander Müller
Hi,
quite a few time ago I implemented a SAML 1.1 IdP which was fairly easy - to be honest however with a good share of help from Scott -, generating the artifact with SAMLArtifactType0001 and remembering it along with the data, then receiving the SAML request from the SP, generating the response from the stored data and sending it off.
I am having now a similar project and considered this time Shibboleth, however the authentication is a little bit more complicated this time and so it appears I would need to write a custom extension integrating the authentication into the SAML process flow, which doesnt seem to be the easiest part.
Because of that I am currently considering using again OpenSAML directly. The artifact generation itself still seems rather easy using SAML2ArtifactType0004, however I am running into some understanding problems upon receiving and processing the SAML request from the Service Provider. Basically I am missing the binding classes, I noticed the org.opensaml.*.binding.* packages, but havent found any classes/methods which would allow me to extract the SAML request from the HTTP request respectively to send off the actual SAML response/assertion - as I could with SAMLBindingFactory.getInstance(SAMLBinding.SOAP).
I admit I might be lacking some basic understanding of the changes in OpenSAML 2, or SAML 2 in general, but I am currently truly lost and hope someone could just point me into the right direction, with some pseudo code or general hint, given it hasnt got too complex with OpenSAML 2.
Thanks,
Alexander
Chad La Joie
don't know what other information to give you. If those don't hook in
to whatever framework you're going to use to attempt to write an IdP
then you'll need to write your own binding code.
Is there a reason you think you can't write a login handler for Shib?
The process to do that is far simpler than the process of handling SAML
2 authentication.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Alexander Müller
<chad....@switch.ch> wrote:
> The binding classes are the classes that implement the bindings. I
> don't know what other information to give you. If those don't hook in
> to whatever framework you're going to use to attempt to write an IdP
> then you'll need to write your own binding code.
With OpenSAML 2 I am currently just missing the "obvious" interface between the HTTP layer (like a HttpServletRequest) and the SAML library.
With OpenSAML 1 it was - admittedly after Scott's help :) - pretty straightforward. I simply had to call
SAMLBindingFactory.getInstance(SAMLBinding.SOAP).receive()
to get the SAML request and
SAMLBindingFactory.getInstance(SAMLBinding.SOAP).respond()
to send off the response.
>
> Is there a reason you think you can't write a login handler for Shib?
> The process to do that is far simpler than the process of handling SAML
> 2 authentication.
Well, I have to admit I might have been a bit scared off by the initial
The Shibboleth Identity Provider uses Spring and XML and XML Schema extensively. Before you begin you must have a basic understanding of these technologies.
warning at https://spaces.internet2.edu/display/SHIB2/IdPDevCustomExtension. Primarily because my knowledge of Spring currently tends towards zero.
Hence my assumption is/was that the direct way might be easier at the moment, considering my previous OpenSAML 1 experience. Also the prototype will work on a small scale not requiring all the features Shibboleth comes with.
Thanks once more,
Alexander
Scott Cantor
> Hence my assumption is/was that the direct way might be easier at the
> moment, considering my previous OpenSAML 1 experience. Also the
> prototype will work on a small scale not requiring all the features
> Shibboleth comes with.
Then you might consider one of the smaller/example implementations built on
top of the new library.
FWIW, essentially nothing if your original experience will apply, there's no
similarity at all between the two other than the lack of documentation and
examples.
-- Scott
Jim Fox
>> Is there a reason you think you can't write a login handler for Shib?
>> The process to do that is far simpler than the process of handling SAML
>> 2 authentication.
>
> ... Primarily because my knowledge of Spring currently tends towards zero.
>
So does mine, but I can still write a login handler. Chad tends to overstate
the Spring knowledge requirement.
> Hence my assumption is/was that the direct way might be easier at
> the moment, considering my previous OpenSAML 1 experience. Also the
> prototype will work on a small scale not requiring all the features
> Shibboleth comes with.
There are plenty of examples of various extensions to shib.
They make the writing of one quite easy -- certainly a lot easier
than writing a new Shib.
Jim
Chad La Joie
deal with plain old authentication, forced authentication, passive
authentication, authentication contexts and declarations, and various
other things. Trust me, even if you have to spend the next 6 months
learning Spring and XML you'll still be further ahead writing a Shib plugin.
As Jim said, writing them is not that hard. That warning is there, to
be honest, so that I can tell people who refuse to do even the slightest
bit of work to buzz off.
Alexander Müller wrote:
> Well, I have to admit I might have been a bit scared off by the initial
>
> The Shibboleth Identity Provider uses Spring and XML and XML Schema extensively. Before you begin you must have a basic understanding of these technologies.
>
> warning at https://spaces.internet2.edu/display/SHIB2/IdPDevCustomExtension. Primarily because my knowledge of Spring currently tends towards zero.
>
> Hence my assumption is/was that the direct way might be easier at the moment, considering my previous OpenSAML 1 experience. Also the prototype will work on a small scale not requiring all the features Shibboleth comes with.
>
>
> Thanks once more,
> Alexander
>
--
Scott Cantor
> The problem is that SAML 2 authentication is quite complex. You have to
> deal with plain old authentication, forced authentication, passive
> authentication, authentication contexts and declarations, and various
> other things. Trust me, even if you have to spend the next 6 months
> learning Spring and XML you'll still be further ahead writing a Shib plugin.
Granted, this assumes you need/want SAML 2 support as opposed to just porting to a supported library. So if you don't need the full picture, I would suggest just taking a look at the wrapper/prototype (not sure if that's an accurate description) that Paul Hethmon did, or even consider simpleSAML.php if you're not wedded to Java.
-- Scott
Alexander Müller
"Scott Cantor" <cant...@osu.edu> wrote:
>
> Then you might consider one of the smaller/example implementations built on
> top of the new library.
Would you have a link to them? I tried looking in the OpenSAML and Shibboleth packages but couldnt find any examples - or did you mean the "Projects Using OpenSAML" at https://spaces.internet2.edu/display/OpenSAML/Home?
>
> FWIW, essentially nothing if your original experience will apply, there's no
> similarity at all between the two
Yes, I noticed it is a complete rewrite, but did even the types/possibilites of access change/vanish (like passing a SAML request "easily" from/to a HttpServletRequest)? I would (have) assume(d) they would remain - even if the calls/classes would change.
> other than the lack of documentation and
> examples.
:)
Thanks,
Alexander
Alexander Müller
<alpine.LNX.2.00.0...@x315.cac.washington.edu>, Jim Fox
<f...@washington.edu> wrote:
>
> So does mine, but I can still write a login handler. Chad tends to
> overstate
> the Spring knowledge requirement.
Thank you Jim, then I suppose I shall try ;)
>
> There are plenty of examples of various extensions to shib.
> They make the writing of one quite easy -- certainly a lot easier
> than writing a new Shib.
I consider using OpenSAML directly as the requirements were and are rather limited, so I suppose we would be using just a tenth of what Shibboleth offers and I had a good experience with OpenSAML 1.
Alexander
Alexander Müller
<chad....@switch.ch> wrote:
> The problem is that SAML 2 authentication is quite complex. You have to
> deal with plain old authentication, forced authentication, passive
> authentication, authentication contexts and declarations, and various
> other things. Trust me, even if you have to spend the next 6 months
> learning Spring and XML you'll still be further ahead writing a Shib plugin.
Our requirements are far below from that (the SP wouldnt be involved in the authentication decision) and more similar to SAML 1. What I basically thought was to port the current code (logic) over to SAML 2 with OpenSAML 2.
Approaching it from another perspective, with those requirements (the SP only receiving user credentials from the IdP), which would be still matched by SAML 1, might SAML 1 still be the right choice or would it be nonetheless recommended to go with SAML 2 (newer version, newer specification, .....)?
Thanks again,
Alexander
Alexander Müller
"Scott Cantor" <cant...@osu.edu> wrote:
>
> Granted, this assumes you need/want SAML 2 support as opposed to just
> porting to a supported library.
Right, full SAML 2 support is - at least currently - not required. Basically the functionality of SAML 1 with SAML 2.
> So if you don't need the full picture, I
> would suggest just taking a look at the wrapper/prototype (not sure if that's
> an accurate description) that Paul Hethmon did, or even consider
> simpleSAML.php if you're not wedded to Java.
Unfortunately I AM wedded to Java :), but the mentioned project might be interesting, did you mean the one at http://code.crt.realtors.org/projects/websso?
Alexander
Scott Cantor
> Right, full SAML 2 support is - at least currently - not required.
Basically
> the functionality of SAML 1 with SAML 2.
Answering your other question, yes, you shouldn't be using SAML 1 in any new
projects or deployments. It's an obsoleted standard.
> Unfortunately I AM wedded to Java :), but the mentioned project might
> be interesting, did you mean the one at
> http://code.crt.realtors.org/projects/websso?
Yes, and the Danish implementation is another possibility. Whatever is known
is listed on the wiki.
-- Scott
Paul Hethmon
>> Unfortunately I AM wedded to Java :), but the mentioned project might
>> be interesting, did you mean the one at
>> http://code.crt.realtors.org/projects/websso?
>
> Yes, and the Danish implementation is another possibility. Whatever is known
> is listed on the wiki.
I put together the one on the realtors.org website. I would characterize it
as a toolkit, more than an SP. If you need to do something special with your
application, then it would be a good choice. The Danish is more like
Shibboleth SP, implemented as a filter and meant to sit in front of the web
application.
Both are built on top of OpenSAML and both have liberal licenses for use.
Even if you don't use either, they are good sources of sample code.
Paul
-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----
God does not play dice with the universe; He plays an ineffable game of his
own devising, which might be compared, from the perspective of any of the
other players, to being involved in an obscure and complex version of poker
in a pitch dark room, with blank cards, for infinite stakes, with a dealer
who won't tell you the rules, and who smiles all the time.
-- Terry Pratchett, Good Omens