Shibboleth Developers

[Scott Cantor <>]

> (1)  When SAML 2.0 changes everything again, I think we won't 
> be in a position to break things, but will have to offer a 
> non-disruptive transition path.

Agreed. I consider our 1.0 release a pretty firm commitment as well, which is 
why I'm not looking forward to trying to slipstream a
SAML 1.1 change in later. In fact, I doubt we would, which raises some 
concerns if one tries to bridge our use of SAML to something
like WS-Sec, which needs the signing fixes in 1.1.

> still change").  From what I've seen the plans are mostly 
> about adding Liberty-style metadata and some new scenarios, 
> eg credential collector, ie additions rather than changes.  
> So it seems like relatively smooth transition should be 
> possible, though of course one never knows till we get there. 

Well, the namespace is probably going to change, making it necessary to do 
some redesign on OpenSAML, which was written by somebody
with a distinct lack of XML experience at the time.

Also, I was being a bit flip in reference to a comment Phill H-B made (after 
not really being around for weeks) that SAML "clearly
would change radically because of all the things that needed to be done to 
make it fit the WS-* world", which was not a comment I
took great comfort in.

>  But at least at this point we could be encouraging about 
> this, no?  There are certainly folks out there saying "why 
> SAML?", and version incompatibilities give them ammunition ...

Agreed, which is why I prefer to focus on the state of the 0.8 code in a 
sense, rather than SAML 1.1.

> (2)  Can you explain the nature of the target side 
> insecurities?  All releases have some security assumptions 
> and caveats, obviously we can't fix everything.  But you're 
> talking something fundamental, so I'd like to understand it 
> better and how the 1.1 changes will fix it.

It's largely orthogonal to SAML 1.1. The actual signature verification in 0.8 
is reasonably sound, for just the POST profile
(whereas signing assertions is effectively not supported). But there is only 
a hand-wavy path check on the signing cert, and no
comparison of the cert's contents to the name of the issuing HS, so there's a 
gaping hole in the trust model. This wasn't a bug or a
mistake, it's just that as I moved from the Java SHIRE to C, I had so much 
trouble just getting the verify step to work that I never
had time to plug back in the X.509 code.

Whereas with the new Apache library, I got the code plugged in to reproduce 
the 0.8 functionality + a few extras in a few days, and
have plenty of time to finally write the OpenSSL code (I even bought the 
O'Reilly book).

I can leave the signatures as is, and just stay with SAML 1.0 for Shibboleth, 
but move OpenSAML to 1.1 for all the other people
playing with it so they can sign assertions properly and do all the SOAP 
stuff. Whether I can somehow do both in one code base is
what I'm not sure of.

But I am sure that staying with 0.8 is a bad idea for targets, and so if one 
posits that origins will want the 1.0 AA functionality
(I would even if I was using LDAP), interop doesn't seem that crucial to me 
except for demos. Particularly since Ebsco is going to
be getting fresh code, not 0.8.

> (3)  How does this affect schedule?  I guess you're saying 
> that providing SAML 1.0+1.1 compatibility is the hardest, 
> hence would cause most delay. And the SAML 1.0 that's in 0.8, 
> and in the absence of making the 1.1 changes would remain 
> more or less the same in 1.0, has security holes?

0.8 has holes, but not any caused by the signature limitations in SAML 1.0. 
The code just isn't very sound inside the SAML library
whereas the 1.1 stuff would be, and I wouldn't have to keep figuring out why 
things are breaking.

I don't think any options affect schedule greatly except for trying to 
support 1.1 and 1.0 in the same code base. I think supporting
both on a per-site basis is impossible in the short run (we'd need target 
site metadata to do that), but I think I may be able to
build in a sort of backward-mode for the origin and target to basically 
choose between 1.1 and 1.0. But the only real use for that
is to interop with our 0.8.

> So the 
> quickest path to market, while not opening ourselves up to 
> massive abuse on bugtraq, is to make the 1.1 improvements, 
> and break 0.8 compat?

It's the fastest way to just do it and be sure it's all working as intended, 
without my wasting cycles on it. Either way I have to
write the OpenSSL code to do the same kind of things, it's just that I'll be 
multi-tasking with these other changes if I try and
straddle both sides of the SAML fence.

In a related vein, I really would like to support signing of attribute 
assertions, and we can't do that at this point.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--