Feb 8, 2007
From OpenLiberty.org Wiki
Back to Meeting Minutes←
Present: Chad La Joie - Internet2, Asa Hardcastle - Zenn New Media, Eric Tiffany - Liberty Alliance, Scott Cantor - OSU, Curtis Jones - Verdant Power / Independent Developer
Contents |
Transport
Chad: HTTP URL connection is crap. Doesn't support things like timeout
Asa: it does now
Chad: what JVM?
Asa: 1.5 presumably, particularly since the deployment won't happen for 6 months
Scott: I think everyone people are OK with 1.5
Asa: You can deal with the Socket stuff
Scott: The 1.3 issues included having to cast down to some SSL classes in library
Asa: fixed now probably
Chad: Jakarta common HTTPI client supports more configuration via APIs.
Asa: Do you use Common a lot in OpenSAML
Scott: Starting to phase out dependency on Common*
Asa: used to having lots of dependencies, but also try to simplify to work only with J2EE. Goal is to have as few dependencies.
Scott: the biggest problem is endorsement. If you want to avoid using the Sun parser, you have to endorse Xerces classes over others in order to override.
Curtis: may be fixed in a newer Xerces.
Scott: seen hardcoded problems in other platforms like
Asa: In Webobjects, there are lots of methods to do XML but they don't work well so you have to move them out of the way.
Scott: Not going to expose lower level APIs anyway, so the goal is avoid those problems
Layering
Asa: talking about Layering, what is the OpenSAML organization
Scott: SAML code, WSS code.... Probably better to look at the OpenSAML bindings. Same case with the SOAP stack --- you can configure to accept different security mechs, but at the application level you just have to invoke the right class and go
Scott: OpenSAML is riddled with abstract classes to do keys, credentials in files, so you end up having to write glue code to make it work
Asa: seems there are some pieces that need to be passed from class to class to class. So you get an assertion so you want to store that in a Session. In Scott's case, not really storing in a session
Scott: right
Asa: but you store somewhere and you are tracking your own session state. Keeping each of these separate . So there's these layers
Scott: SOAP client -- the way I've modeled as specific client subclasses that know how to manipulate the transport (including the HTTP layer) there are subclasses that know how to do
Asa: so the SAML is part of the body
Scott: no, it's part of securing the transport. THe construction of WSF is part of the SOAP subclasses
Asa: The way I've been looking at it is embedding SAML in the transport
Scott: that's only one mechanism, but if that's all you neeeded then you wouldn't do it at all and just use TLS
Asa: so the generalization mandates the complexity
Scott: The WSF approach gives you the power to handle various complex models including Kerberos, SAML, other security (inc just TLS). The first step is to use Token based security to do some SAML attribute request. Can do basic att request today with TLS, but need to be able to selectively evaluate credentials at both ends. If you HTTP class doesn't make that easy, then you need to try something else
Asa: TLS at the transport layer, but the credentials are at the SOAP layer
Scott: Most common sec mec is HOK SAML over TLS, so you don't need to support Signing at first
Asa: what would conor say?
Scott: Conor thinks that people will want to sign things vs setting up mutual TLS.
Scott: but the signing makes interop difficult (in practice)
Asa: how do you deal with trust issues?
Scott: you create a Trust Engine and bury it so it's not really
Asa: what are the mechanical steps
Scott: you pass the trust engine certs or credentials - you have to supply the trust policy.
Asa: want to understand that better
Scott: most of it is represented in SAML metadata. you write adapter classes to enable the enforcement of trust policy
Asa: but you have to establish trust via phone call or whatever
Scott: yes, out of band, but that's exogenous
Asa: are you OK having the class layering that you suggested a while back sent to the list as a starting point?
Scott: sure (used to having people disagree).
Scott: choices are 1) Use DOM (in which case your code is not useful), 2
Scott: Try running your code with different
Asa: what does openSAML cover in your stack?
Technology
Asa: in terms of technologies. JDK 1.5, generally agreed.
Scott: If you use Axis, you need to use Axiom
Asa: where did SOAP come from in OpenSAML
Scott: we wrote it. You give up the advanced stuff like SOAP w Attachments, but you need to support the security stuff
Asa: could just stay in strings, too. What are the dependencies that OpenSAML brings to the table?
Chad:
- Bouncy Castle,
- Javalution (collection semantics) -- but may drop because 1.5 works well for collections
- Jodatime (time)
- log4j
- xmlsec 1.4
- Xerces 2.9 Xalan
Chad: we don't directly interact with Xerces but need to endorse it and then interact via JAXP
Scott: in theory you could use Sun, but ther is a transform bug
Chad: so it can't parse xml with schemas
Asa: do you requrie schemas
Scott: used to, but you don't now. Parsing is a separate step. Validation is optional. After you generate the DOM you unmarshal, but you don't need to
Asa: cost of validation
Scott: myth -- validation isn't done because no one has good xml. Signing is much more expensive.
Asa: still need to know more about dependencies. So if we used the tooling how much work to eliminate some dependencies?
Chad: Not too much work to refactor in Eclipse to eliminate external collection classes (javalution). No APIs would change
Eric: what's the reason for using javalution's collections?
Chad: about 10-15% faster than standard JDK 1.4. The other thing is thread-safe looping over changing collections. Prevents you from having to lock the collection.
Curtis: one question on SAOP stack. is that proprietary?
Scott: no, it's a SOAP api designed to support real secmechs, which AXIS doesn't. IT is pretty minimalist, no attachments, etc.
Scott: Has C++ soap client that can plug in, and the thinkin is that it would support the WSF features. Want to pull it out of the SAML code. No Java client yet.
Scott: pluggable transport interface. APIs were geared to even support Async transports, but not tested yet. First step was modeling the object (because there are not too many objs in SOAP).
Chad: possibly porting Scott's SOAP client to java soon, possibly this weekend
Scott: there's nothing in it for Internet2 to use a library that doesn't integrate with this pluggable sechmech, SOAP, etc. tooling.
Curtis: Parallel experience in Telecom world, where people were trying to build the most flexible library. First question is how to get the DOM -- answer is you don't. So that doesn't do any good, so you have to hack to short circuit parsing process.
Asa: The whole point of enveloping is to make interop easier
Curtis: there is just sending raw XML over HTTP
Asa: not much work until after 16th due to other deadline.
Test Harness
Asa: will contact Derrick at Sun about Sun's offered liberty enabled products
