« February 01, 2003 | Main | February 04, 2003 »
February 03, 2003
GXA Components: Security Example
This morning I wrote about The GXA security specifications. I took some time this evening to read through the the specification and thought and example might be helpful. This example is quoted from the specification:
(001) <?xml version="1.0" encoding="utf-8"?>
(002) <S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
(003) <S:Header>
(004) <wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext">
(005) <wsse:UsernameToken wsu:Id="MyID">
(006) <wsse:Username>Zoe</wsse:Username>
(007) <wsse:Nonce>FKJh...</wsse:Nonce>
(008) <wsu:Created>2001-10-13T09:00:00Z</wsu:Created>
(009) </wsse:UsernameToken>
(010) <ds:Signature>
(011) <ds:SignedInfo>
(012) <ds:CanonicalizationMethod
Algorithm=
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(013) <ds:SignatureMethod
Algorithm=
"http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(014) <ds:Reference URI="#MsgBody">
(015) <ds:DigestMethod
Algorithm=
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(016) <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
(017) </ds:Reference>
(018) </ds:SignedInfo>
(019) <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
(020) <ds:KeyInfo>
(021) <wsse:SecurityTokenReference>
(022) <wsse:Reference URI="#MyID"/>
(023) </wsse:SecurityTokenReference>
(024) </ds:KeyInfo>
(025) </ds:Signature>
(026) </wsse:Security>
(027) </S:Header>
(028) <S:Body wsu:Id="MsgBody">
(029) <tru:StockSymbol
xmlns:tru="http://fabrikam123.com/payloads">QQQ
</tru:StockSymbol>
(030) </S:Body>
(031) </S:Envelope>
There are a few things to remember as you look at the specification:
- The SOAP envelop has been extended to accomodate the security portions.
- The security standard makes use of XML Signature specification (ds namespace).
- The signature has to reference other elements of the message (e.g. what part the signature applies to) and uses the ID attribute in the wsu namespace to do this.
Deconstructing this example is fairly straightforward. The SOAP envelop header contains a single element: <wsse:Security...> which contains the UsernameToken and the digital signature information. The signature contains information about how the signature was computed, the reference to the message body (to indicate what portion the signature applies to), and the signature itself. Notice that the specification doesn't specify the method, it just allows it to be referenced so that both ends know what to do. If a better algorithm comes along next year, it can be used without any fuss. The final portion is the actual body of the message which, in this case, contains a stock symbol.
There's obviously much more to the spec than this simple example, but if you understand what's going on here, the rest is just options, alternatives, and details. Encrytion would be the similar, except it would reference the XML Excryption specification and some of the details would change. And, of course, the SOAP body would be gobbledygook.
10:30 PM | Recommend This | Print This
A Utah Fund of Funds
House Bill 240, currently being considered by the Utah Legislature would set up a non-profit corporation that is authorized to raise up to $100 million dollars and then disburse that money to existing or new venture capital firms with a Utah presence. Those VCs would be encouraged through various means to invest the money in either Utah firms or firms that create Utah jobs. How do you raise the $100 million in the first place?
With contingent tax credits. The non-profit, called a fund of funds would guarantee its investors a certain rate of return (probably equal to the current money market rate). If the fund did not perform as promised over the life of the fund (usually more than 10 years), the investors could recoup their investment through tax credits. These kinds of bills have proven successful in places like Oklahoma and Arizona in creating new sources of venture money.
Industry statistics from Arizona shows that their economy receives $6.54 revenue return over a five-year period for every $1.00 of venture capital investment. In addition, for every $1 million in venture capital, 27.6 jobs are created in the state. Utah's young companies have seen available venture capital disappear, falling from a high of $330 million invested in Utah firms in the second quarter of 2000, to a low of $4 million in the third quarter of 2002
Its not just the total dollar amount available for investment in a geographic region thats important, its also the number of venture capital firms. Each firm has its own flavor or theme. For example, I've talked to VCs in the last month who say "I won't invest in services." and have lunch the next week with one who says "Services are where its at. That's all I invest in."
If you are involved in high-tech in Utah, would like a high-tech job in Utah, or simply care about it, I urge you to write to your representative and your senator1 and explain to them why Utah needs more investment in high-tech and ask them to support HB240. Make sure you tell them that you are a constituent in their district or that you own a business in their district. That carries a lot of weight. Written or faxed constiuent communication is taken as being much more important than email.
- The Utah Senate doesn't have an interactive map to find your district. You may have to visit your county web site (you can get to it from utah.gov) or call the Senate and ask them (801-538-1035). I could explain to you why the House has a nice map and the Senate doesn't and how they could both have really great ones for free, but I'm trying really hard not to piss anyone off this week.
08:33 PM | Recommend This | Print This
Lucene
Unfortunately, I don't get to program much anymore, but I find that when you're managing a bunch of programmers, its frequently nice to be able to call their bluff. Consequently, I try to read magazines like the Java Developer's Journal to keep up with things and it usually pays off. I find something almost every issue that I'm glad to know about. In the December 2002 issue, for example, I found out about Lucene.
Lucene is an open source, text indexing and search tool written in Java. Its not unusual anymore to want search capabilities in an application and Lucene provides one way to do that. The web site claims that is "high-performance" and offers a a page for users to submit benchmarking results for review. No idea, of course, how these compare to other search products from Verity, for example. If you've used Lucene in a project and would like to comment on either its reliability, ease of use, or performance, please feel free to drop me a note.
05:32 PM | Recommend This | Print This
Flying Without ID
Jeremy Zawodny posts a link about Flying Without ID. Now, I fly without ID all the time...in my plane. Some people are surprised when they learn that you're pretty much free to fly wherever you want whenever you want. The only exception is controlled and restricted airspace, but that's not usually a problem. The link Jeremy posts is about flying without ID on a commercial airline. I think this is interesting, but not really something that gets me all fired up. After all, of all the restrictions that Delta puts on me in order to transport me from point A to point B, showing them my ID is one of the least onerous. I'd rather not have to show them my credit card, for example.
04:54 PM | Recommend This | Print This
GXA Components: Security
I've been writing about the Global XML Web Services Architecture, a set of specifications that sit on top of SOAP and provide interoperability in a number of important areas. This article is a look at WS-Security, the GXZ security specification. These articles and associated resources are being indexed in my featured papers outline.
The OASIS web services security specification creates a set of extensions to SOAP messages that can be used to secure messages and ensure their integrity. Note that this is message-level security, not secured channels (which you could do with SOAP using HTTPS as the transport, for example). Message-level security is important whenever intermediaries are part of a conversation. These extensions are referred to as the "web services security core language" or WSS-Core. The specification was put together by Microsoft, IBM, Verisign, and others.
IBM and Microsoft have released a white paper which describes the specification. The specification extends SOAP so that the following processes can take place (quoting from the MS/IBM white paper):
- A Web service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.). If a message arrives without having the required claims, the service may ignore or reject the message. We refer to the set of required claims and related information as policy.
- A requester can send messages with proof of the required claims by associating security tokens with the messages. Thus, messages both demand a specific action and prove that their sender has the claim to demand the action.
- When a requester does not have the required claims, the requester or someone on its behalf can try to obtain the necessary claims by contacting other Web services. These other Web services, which we refer to as security token services, may in turn require their own set of claims. Security token services broker trust between different trust domains by issuing security tokens.
The paper gives a number of scenarios showing the different ways that the specification can be applied. I think its particularly important that the specification is built to accommodate existing security models rather than foisting another one upon the enterprise. This was the big mistake in 802.11a/b: the security wasn't built on existing, socially proven concepts, but something completely new that, as it turns out, didn't work.
The WS-Security specification is not the end, but the foundation for a number of other security related specifications which will build on the message-level security in the areas of security policy, trust, secure conversations, privacy, authorization, federation, and others. White papers in the areas of trust, policy, and secure conversations were released in December 2002.