OpenSAML user discussion

["Scott Cantor" <>]

> As far as I know, in current OpenSAML code there's no other way to  
> configure SSL than using the singleton SAMLConfig. This config is  
> read only whithin static part of the SAMLSOAPBinding implementation,  
> so it's global and unique.

This is not the case. 1.1 supports hooks at the HTTP and SOAP layers, and
should enable complex authentication requirements. It is used by Shibboleth
and we do dynamic credential and trust evaluation.

I'm not sure where SAMLConfig fits into this. It doesn't really have
anything SSL related, unless you mean the properties file stuff.

> Maybe I should modify/rewrite SOAPHTTPBindingProvider.java to be  
> dinamically configurable (and to (re)move static part)? In this case  
> what should be the format for the Element passed as an argument to  
> the constructor?

I seriously doubt you could come up with something worse than what
Shibboleth required, and we didn't have to rewrite it. As far as the element
goes, it's whatever you want it to be to configure your plugin instance. It
could just be an Element containing a path to some config file that's not in
XML if that's what you prefer to use.

Note that you don't have to "rewrite" anything either way. Just plug in your
own binding implementation. 1.1 has pluggable bindings now.

> Maybe I'm pushing OpenSAML too far and I should use Axis to handle  
> SOAP-over-HTTPS messaging instead?

That's up to you. It was entirely out of the question in my mind, given the
baggage and work involved, but if somebody wanted to write a binding
implementation that used Axis I would be happy to include it.

I'd be surprised if Axis dealt with HTTPS in a better way than we did. My
experience is people don't understand why static trust lists are so useless
in the real world and libraries tend to reflect that.

OTOH, if I'm wrong, I will evaluate Axis for future inclusion, since it be
less work for me to keep maintaining something.

> Does OpenSAML perform correlation checks between a samlp:request's  
> requestId and the corresponding inResponseTo in the samlp:response?

Yes.

-- Scott