WashingtonMinutes
From OpenLiberty.org Wiki
Contents |
Attendees:
- Scott Cantor (The Ohio State University / Internet2)
- Conor Cahill (Intel)
- Darryl Champagne (Liberty)
- George Fletcher (AOL)
- Hubert Le Van Gong (Sun)
- Brent Putman (Georgetown University) - Vegetarian
- Chad La Joie (Georgetown University / Internet2)
- Jim Fox (Univ of Washington)
General Info:
Note the new effort begun by Sampo at [zxid.org|http://zxid.org/] (Note: NOT www.zxid.org)
Core Discussion:
- What should the libraries cover?
- WSC Client Library?
Overview of Conor's C++ Library:
- Authn Service, Discovery Service, Liberty Service Class (Instantiates how to send message to the other party).
- SOAP Layer
- XML Wrapper, HTTP Wrapper
- Uses LibXML, libxmlsec, libcurl
- Interaction service not currently included.
General diagram of flows - Browser to IdP, SP, potentially IS. No Photo Taken.
Q: Is signature verification part of the client? A: Yes. May get a response back from the service provider.
None of the security mechanisms explictly say whether the response is signed. In Metadata?
In the SOAP Bindings, can apply to the response as well as the request - could sign the response. Not clear. This is a hole, not well addressed in the specs.
George: AOL may choose to open source some of it's code - in Java.
Conor's Server is primarily Java. Much of it's processing is just done with strings. When going to sign, have to go into a DOM.
George: DS all C code and proprietary.
Discussion regarding generating code using WSF schemas - they break many tools. AXIS 1.3 works with some tweaking. Conor had to made slight changes to the schema to make it work better - basically add a bogus element, minOccurs=0, to generate base class properly.
DOM is supposed to be generic. In Java, DOM is a reasonable interface. Can theoretically substitute alternate implementations, although xerces might be the the only one that actually works well. Not really an option for C++. Xerces, libxml use very different approaches.
AOL Code:
AOL has a Java client side. ASIF - AOL Service Invokation Framework.
- All assertions currently use SAML 1.1
- Plain old Java objects (POJO) are used as much as possible.
- Use IdP to authenticate and validate.
- Currently on WebLogic 8.1, can use 9
- Apache XML Beans for XML processing - Had problems, changed namespace prefixes, thus fail signatures.
- SOAP processing BEA Supplied, HTTP support buried within SOAP stack.
- Handling of all headers done in POJO.
Here is the service type or providerID that I want to invoke, and it goes and discovers, invokes, etc.
Background Discussion:
Conor reviews general WSC, WSP, IdP, Disco concepts.
Key that for each different user, the provider of each service might be different.
License Discussion:
Apache license is better because it covers patents.
Note that general IP is already covered by SAML and Liberty rules.
Apache, an issue for ownership to give it to the foundation later. All copyright holders must agree to turn it over. Apache generally doesn't even like to have any dependencies on anything else.
Environment Discussion:
Perl vs. PHP calling a clean client, or Apache/Tomcat/Weblogic environment?
Axis, tend to write little handlers, different style. Axis has client side stubs.
What are the success criteria? Drop into a router? Add to Apache?
Architecturally, major differences between server, client in LAMP, etc.
Apache? To receive a request? WSC invokes a WSP, that is the WSC side of it.
CGI? Why do an apache module for a profile call? Instead you would have a library that you would offer for cgi apps to bind in. Some body of code to drop in. The code that you add to an SP to allow it to invoke WSPs?
3 Distinct Environments
- Intelligent client - discovers and invokes. Mail reader, browser, could do this.
- Applications hosted on a plain Web server - wanting SSO.
- Web Service Application, application framework is in play, invoked through framework, wants to invoke out.
Java stuff on mobile environment is a different beast. Cannot affort to implement highly specialized code, horsepower/bandwidth constrained.
Focus on Generality. SOAP layer, attachments, etc. A library / Jar file, can invoke it.
Hubert: Sun has WSF 1.0 Library.
Missing, especially for the LAMP community, how to use a Jar file for PHP, etc.
Reason to skip LAMP for now, is difficulty of convincing them to use SOAP. Some discussion of PHP, but some XML Signature support showed up in PHP after the meeting, so much of it now moot.
iClient, mixture of C/Java. App mostly PHP/Perl. Web Services are more Java oreinted. Internet2 is trying to look at web server making web services call, where app is in Java.
Something useful, if there are people who are interested, pieces of functionality in Jar, could drop in. AXIS2, now putting in layers for WS-*, plugins, etc. Also has their own complete object model, Axiom.
Some people are willing to wrap Java and invoke from Perl. Hassle to deal with system specific linking / building, some people won't do it.
Things that we need to do:
- Server side - something to test with. Conor's works for Discovery. George's also works for SOAP.
- Need testing harness.
- Would be happy to include a complete server side library.
- Internet2 willing to host testing sites.
Need an architecture team. Leadership driving how stuff will be done.
Internet2 is not prepared to provide substantial resources at this point. At some future time, if this project succeeds this might be available. Do have XMLToolig code that we're willing to provide (if useful), and has SSO functionality from Shibboleth that would like to be integrated with OpenLiberty. Could provide integration assistance around use of our code. We have general XML wrapping libraries, signature, encryption, metadata, etc.
Possible General Model for a WSC API: Code in SP that would accept a SAML2 assertion, name of a service, body of a message, responds back with body of the response. Does discovery, getting what it needs, invoking, getting response, returning body of response.
Issues: Session - tying a future invokation to a previous one.
Deal with EPRs, also cases where the EPR can change/update. May use this to shortcut assertion with a session ID for future calls.
What pieces are we willing to use, or rule out?
Decide to hold for AOL code? XMLBeans based set of components.
Have to come out of XMLBeans to do xml signature.
Only Open Source XML Sig available is from an Apache project (SUN may have one coming out?)
The Apache library at least, is DOM centric. People trying to do SAX/stacks with it have a hard time.
Large messages will never be supportable with DOM. As in Multi-megabyte. The problem of having to wait until entire message is received before processing. Need DOM for only part of message. Signature processing an issue.
Most of the multi-megabyte is an attachment, so might not be an issue.
Microsoft has a non-DOM way of doing signature. It can be done, but very hard. WS-Sec has requirements to allow serial one-way processing. WSS rule, can't forward reference, to allow for it. Lot's of DOM models available. OpenSAML has it's own Java objects but can always get DOM, to plug into WSS4J (for example).
Axis 2 handlers not DOM, but Axiom. Deciding what to do about the SOAP layer seems to have the most far reaching impact.
WSDL:
How does WSDL fit into this? People think they should be able to take the WSDL for their service, and plug in. George comment: Then we are dead.
More typical, take WSDL, run it through tooling, get proxy object, call.
With Liberty, WSDL doesn't have all the headers, but endpoints are dynamic, so can't have the endpoint WSDL in it. Even from WSC side, need header stuff, extra info, or can't use the service.
Current answer with WSDL, don't use SOAP headers, dump all into Body, then WSDL toolchain works. Not just Liberty that is the issue, WS-security is also the issue.
WSDL2? Horrible mess, but doesn't it have support for headers? No value out of it, list the headers, but so what?
Is it WSDL support that's required, or that here is a set of tools, so you can plug stuff in, and not have to see all the internals?
WSF, an invocation framework, needs to be able to say here is the call, and here is the invocation framework. Nothing like that currently. With WSDL2, able to create bindings to a framework.
Opinions expressed: WSDL2 is going nowhere, SOAP 1.2 is going nowhere. That's the perception, at least.
Think the real requirement is transparency and automation.
Some people feel that the definition of a web service is that there is WSDL. Standard specifications are pushing envelope of tooling. SOAP layer tends to be very customized.
What about running custom tooling? It's a problem, since enabling through application frameworks is valuable.
Security Layer and Implications
JBoss
Codehaus tool, SAX based, no way to get to raw xml?
Apache XML-Sec JAXP 1.3 (OpenSAML requires JAXP 1.3, but being factored out, and could be replaced) DOM 3 (included in JAXP 1.3) What about HTTP? Probably part of SOAP stack.
HTTPUrlConnection in Java (bad).
Have to be able to hook into HTTP layer to be able to do customized SSL handling. Sun's API has problematic SSL hooks, but it can be worked around. For any real deployment, you want dynamic trust anchors and trust decisions. Difficult to do selection of credentials, get certificate chain, dynamically tell if credentials are OK.
From a CGI model, you get a new invocation per message. Need some persistence across CGI invocations. In a web server environment doing Java, not really an issue. People wrapping Java in Perl also have a persistent VM, so again not an issue.
One option, make objects/context serializable. Can't keep an HTTP connection live, because would lose the file descriptors.
WS-Addressing (mostly non-issue, need profile, no processing involved).
WS-Security - only real open source implementation WSS4J, not clearly valuable for this level of work, future - GlassFish emerging from Sun?
What about SAML token profile? (WSS4J does the old one). Creating signatures, verifying signatures, exposing signature semantics. With XMLSig, the hard part is knowing what is signed. SAML had to copy from Liberty a profile for what had to be signed to get around the problem. In WSF, could legally sign via XPath. May also need good access to the message itself to understand what's been signed.
At security layer, build references, nodes, process that, and that is what has been signed. No API layer to expose that functionality. Lower layer may validate signature, but hard to connect with which fields were signed, and were they what was needed.
At application layer, want to be able to get particular data, and be able to tell if that part of the data was signed.
What about requiring that you not sign a subset?
Scott: just use TLS for everything? Signature problematic, that I can only tell not modified since signature generated, not that the original sender sent it to me.
Are these hard problems already solved in anybody's implementation? Probably no.
Locate an alternative, or clean-room something?
Needs to be possible, through the library, to easily create and consume various token techniques, STR transforms, all sorts of different wrappings in accordance with the standards. Some libraries produce stuff that is wrong. We have a correctness requirement.
Encryption part of the picture. Kinds with WSS could be kind of exotic. Liberty doesn't look at encryption of SOAP level stuff much at this point.
Save off and recover later (higher up stack) what was signed at the WSS layer. Plain verifying a signature is easy. Need to relate signature to message content.
Do you have to build it yourself, and what is the layering. Can it be layered cleanly at all? In order to ensure a proper message, you have to be able to poke into both layers.
One way would be to expose both original message, and expose just the signed portion (or only that). Difficult to do with Apache code without hacking. Perhaps either make two passes, or flag everything as to what was signed or not.
Other implementation, JBoss? (based on WSS4J?), GlassFish. Might want to evaluate architecturally.
TLS is what I2's code has generally used. Could still be useful to produce something that does not solve all the security issues. One approach is to use only TLS-based key confirmation as the first phase. If there aren't any implementations available that do it, hard to architect for it.
If doing signatures, would want to do them as part of this project. Relationship of signature to application layer the issue. More of an issue of incoming messages to server, not client. Response headers would be an issue for a WSC library
Interested if anyone has actually implemented signing responses.
Scott's cut-off level, cut at xpath. Jaxon or Xalan added as a dependency. Core xml is one size, adding xpath/xslt is huge.
Conor - cut off sooner, not even deal with signed responses.
In working out interfaces, at granularity of header / body, was it signed? That cuts out strange cases.
SOAP
SOAP (and/or HTTP) is the major piece left. Worst of all worlds is to allow for only one stack.
Conor - do it with our own SOAP implementation, but take the time to make it work with something else.
George: Most of the people dealing with the toolkit wouldn't be dealing with the SOAP layer anyway? Here's a package with JBoss, here is one for Axis, here is one for BEA.
May be true on client side, not necessarily for server side.
If client-side developer cares which stack he's using, he is out of luck anyway, since he really just wants WSDL.
Might be possible to wrap something around WSDL? Spew out a JAR, that does discovery, rather than doing it from WSDL? Read a WSDL and dump the code.
WSDLtoIDWSF Jar. Might have to go there to interest client side.
On server side, the frameworks couple in much more.
Does Axis come with it's own HTTP listener?
Scott predisposed to clean room stuff (on top of Apache XML-Sec, JAXP 1.3, DOM 3).
If you use a SOAP stack off the shelf, can you even get access to the SSL layer?
Is what out there ok, can I improve what is out there, then write my own.
There is a point at which code reuse becomes reuse for the sake of reuse, rather than getting any gain. Spending time adapting, for minor functionality. If it was as trivial to tweak your collection class as it was to implement a good red/black tree....
Guts of SOAP pieces not an issue. Web Services part isn't the critical part. Ability to securely issue a request and get back a response is what matters.
Jim Fox: Signing, just use TLS. Mostly people use Axis. Web services, equally easy in C or Java. Always started with WSDL description, and built from that.Run GSoap. Axis 2 works kind of the same way. Web server is just trusted, identity in the body, web services trust via certificate on TLS.
If using WSDL, does anything other than the schema of the body matter?
Some UML tools generate the types etc. in XSD syntax inline in the WSDL, rather than a separate schema. In WSDL, can specify that these are the faults that can be generated. Makes sense to Java people, because everything is a Java object. Microsoft will import WSDL. Microsoft will do WS-Sec, but not in WSDL. Via Indigo (communication layer). Can give it descriptors, one of which is WS Sec policies.
Tango, beans, wsdl portion. Demos of Netbeans to generate Liberty.
Option: Write our own soap stack, use HTTP from somewhere else. Implement first version.
Conor: Gave up trying to figure out in response handler in Axis, how to get the entire formatted message (didn't get any content in body).
(Discussion of Internet2's XMLTooling code followed.)
Hubert to send out link to their stuff.
Can look at Conor's code for switching between WSF 1 and WSF 2.
General Design Points
George: The way you get the initial SAML assertion is out of scope. Need discovery, might not need initial authentication. Rough layout of how to structure things. What pieces to use, what languages to use, what platform, etc.
The context is a web server-side application.
Deployment expectations?
Scott: Want to avoid dependancies on J2EE. Any SAML SSO should work with it.
In a web server app, have a SAML2 assertion, and want to invoke a profile service and get a name.
Exposing enough discovery service functionality.
Can test against Conor's DS.
Most companies willing to provide test facilities. I2 could host an implementation, that would eventually have SAML 2 SSO.
DS functionality.
Prioritize the SecMech work.
* Bearer over TLS fine for starting point. * Holder of Key via TLS would be next, where signature is coming from client TLS. * Then look at signature issues.
Client TLS security mechanism, have the issue that you must pick the right certificate.
Need Disco, SecMech (bearer or TLS, then holder of key (above) - no work other than establish the right key to lower layer, SOAP stuff, XML Binding stuff.
Message signing? Follow-on - next set of security mechanisms. One school of thought, clients not needing to worry about it.
JDK not really an important issue. Just use the 1.5 JDK.
Name. Liberty Open Source Toolkit (LOST)?
OpenLiberty-ClientLib
Trademark picture?
Sun OpenSSO released under CDDL. Another testbed.
