Brian Maso's Tecno-Geek Weblog

Groovy is groovy

Thu, 01 Apr 2004 14:34:29 GMT

JSR 241 -- the "Grrovy" language JSR -- has passed the JCP. I read about it in TheServerSide.com article, pointed out by Scott Hodson in the OCPATTERNS mailing list. I barely know anything about this language, and its already official!

Groovy as an "official" alternate language for the JVM

Tue, 16 Mar 2004 21:24:08 GMT

JSR 241 attempts to officially designate Groovy as an alternative language for the Java VM. The Groovy language is an "agile" language, meaning the language designers attempted to design something a programmer could use to rapidly develop code. Not a bad idea, really, for quick 'n dirty code development. Ruby, Jython and others have been around for a while. Making an official RAD language would stop the balkanization of agile language alternativesfor the JVM. It would also make use of agile languages a realistic alternative for those (great number of) programming houses who are more conservative and like to stick to "official" stuff.

Credential Management

Wed, 08 Oct 2003 21:53:04 GMT

Sharing a few thoughts on security credential management that occurred to me this week...

This issue is credential security: When a credential is presented to a system for authentication, how "assurred" is the system that the credential has not been compromised? That the entity presenting the credential is actually an agent of the identity assocaited with the credential?

To assess "assurrance", you must first consider the type of credential. Token credentials, such as HTTP Session cookies or SAML tokens, are the simplest tyep of credential. The token has been assocaited with an identity known to the system. The simplicity of this credential, however, means that the credential is easy to steal and re-use. Any time the credential is used it can be copied and immediately used by an attacker - use of the credential opens it to compromise relatively easily.

Username/password is really just another version of a token, from the receiving system's point of view. It is a chunk of data that has been associated with a user identity. But use of the username/password immediately opens it up to attack. Anyone who can "see" the username/password pair can immediately use it to make false requests.

The very first time it is used a token credential provides a high degree of assurance. However, each time it is used thereafter its assurrance is "degraded" because of the repeated exposure. Each time it is used it may be copied by an attacker, and so every time after the first there is a cumulative risk that the token has been compromised.

Good management of token-type credentials must therefore include limiting the "lifetime" of the credential. That is, if each time it is used there is some cumulative degredation of "assurance", then assurance approaches 0 as utility approaches infinity. So yhou must limit the uses of the token-type credential to prevent a statistically certain compromise, which would happen eventually.

There are 2 techniques commonly used to limit the utility of a credential:

Lifetime
Max usage count

The "lifetime" technique places a maximum absolute duration on the lifetime of the credential. The credential is considered no longer usable after this lifetime duration has run out. Assuming there are only a finit number of times the credential can be used within a finite time duration, then this technique adequately protects against statisticaly compromise; set the lifetime duration based on the risk each cumulative use adds to compromize, multiplied by the max number of time the credential may be used during its lifetime.

The max usage count technique cuts right to the point: the real crux of the problem is that each time the credential is used, it is potentially compromized. So just limit the total number of times it may be used. This should allow you to manage the risk of compromize.

Another important feature of credential management is revocation. Once a system detects that a credential has been compromised, or is likely to have been compromised, then the system must be able to revoke the credential. Otherwise an attacker may continue to use a compromized credential with impunity, even though the system administrators may even know that the credential has been stolen.

Now note that more complicated credentials, such as hash values built from tokens as well as PK certificates, really have all the same problems are simple tokens. Each exposure means an attacker may copy the credential. Once an attacker has a copy, with correctly applied technique it is only a matter of time before the credential is compromised: hash algorithms can be reversed to obtain the original token; PK private keys can be derived from PK public keys with enough brute-force calculation.

So use of the alternative techniques really only reduce the culumative risk of compromise associated with each exposure of these alternative credentials. The risk is not reduced to zero, but it is reduced exponentially, by potentially thousands of orders of magnitude. However, the need still remains for minimizing utility, and for revocation.

When designing identity credential management, analysis must include what type of credential is being used, with a special eye towards how much risk of compromise is added whenever the credential is used. Lifetime or usage count techniques, as well as a revocation mechanism, must be employed to provide a minimum level of identity assurance to the system.

Distributing a Web Service Sample Implementation

Mon, 15 Sep 2003 23:34:34 GMT

Brian: incomplete. Will hook up links and flesh out a bit soon...

I developed a trick for distributing a test web service implementation. A test implementation would be used by someone else externally to develop a Web Service client. Its an implementation that runs locally on the external developer's machine serving up "dummy" data, but using the correct WSDL and message validity just like a production version of the web service.

Using a test implementation means my company doesn't have to host and maintain a test implementation on public web servers. Its really amazing how resistant IT departments are towards making implementations available externally, and this solution avoid dealing with those people at all.

The idea is that a test implementation of the web service is "pushed" to a client machine through JNLP (Java Web Start). The test implementation is downloaded and runs locally on the client machine when the user clicks particular web page link -- if you are at all familiar with Java Web Start then ou know what I'm talking about. The test implementation is downloaded and run on the client's machine in its own window.

Of course the security implications are pretty drastic -- basically the external developer is downloading and executing an application over the Internet -- recipe for disaster. The solution to this terrible security problem is restricted trust: you must digitally sign the JAR file containing the test implementation of the web service, and the external developer must trust that your implementation will not do anything "bad" while it is running.

I use this trick when I'm developing a web service for consumption by a very few trusted and trusting external organizations. The external developer knows me and I know him, so this type of trusted applicatgion is probably adequate. Of course if you are in a situation when this type of trust would not be appropriate, then of course you wouldn't want to use this trick.

The important pieces of the trick are:

Packing up a test web service implementation as a web application -- a J2EE WAR file.
Packing up the WAR file with a small J2EE Servlet container, such as Jetty.
Building a JNLP main application that starts the small web server and makes it host the web service web-app.

Here is an example. Click on it and it will download an application that will host a "Hello, World!"-type web service locally. I have digitally signed the application JAR file, which means when you click on the link above you'll be asked whether or not you trust me to run an application "without restrictions" on your local machine. If you click "yes" then the application will run on your local machine, all with just a couple clicks of the mouse.

To be honest, I'm not sure you would want to click "yes" if you don't know me and trust me already. That's just asking for trouble, right? I could be a very clever hacker trying to take over your system through this blog entry. Instead you can download all my original source and an ANT build script, recompile and try running the application yourself (requires JDK 1.4+ and ANT installed). This gives you he chance to peruse the source code to make sure the test implementation won't try to do aything malicious to your system or your local network.

Java.net Community Page

Mon, 15 Sep 2003 18:00:48 GMT

Somewhat based on the SourceForge model, Sun is hosting projects through www.dev.java.net.

"X": A Language Based on the XML Infoset

Wed, 27 Aug 2003 19:29:26 GMT

I've been on a very long hiatus from blogging. In fact I'd be surprised if anyone is even paying attention to this any more. I have a germ of an idea that I'm starting to believe is not half-bad, and I have to memorialize it somewhere. So even if I'm addressing a darkened, empty room, I have to at least voice this...

I've been doing a bit of web services in Java lately, and I've come to these conclusions:

Object-to-XML (O/X) conversation layers stink. Only a subset of all complex and simple XML Schema node types can be accurately, unambiguously translated to object types in any popular OO language (C#, Java, C++, whatever). I'm not talking about parsing serialized XML to a DOM representation. I'm talking about generating an OOL type from a Schema type. For example, a Java class from an XML Schema complexType declaration.
O/X conversion generates data-only classes. Classes generated from XML Schema have no specific behavior additions other than data accessors and validation. (Huh?) What I mean is that the generation of an OO class from the xsi:anyComplexType definition can do anything and everything an OO class generated from someURI:myComplexClass can do. There's no behavior in the specialized class. Why use an OO class at all? Just use DOM (or an equivalent) and save yourself a lot of unnecssary class generation.

Proposal

What about an OO language that uses the XML data model as the data model? It's crazy enough: it would actually work!

What I mean is, instead of generating a class that kind of approximates an XML complexType, you have a language in which someURI:myComplexType is a first class object type. To get an idea, check out this type which describe a person entity in the HR domain:

//
// someURI:Person complexType definition
//
namespace "someURI" as "ns";
import schema "http://www.w3.org/..." as "xsi";
public complexType Person
{
  //...field attributes capture aspects not associated with behavior. Fields are either
  //   elements or attributes. The first element's type is xsi:string. There are
  //   three element fields and one attribute field in this ns:Person type. The
  //   first two elements have type xsi:string. The attribute has type ns:employeeID,
  //   a simple type ostensibly defined within the same namespace. The final
  //   element field has value type xsi:integer...
  @public-read, @private-modify, @not-nill
    element(xsi:string) first-name;
  @public-read, @private-modify, @not-nill
    element(xsi:string) last-name;
  @public-read, @private-modify, @not-nill
    attribute(ns:employeeID) id;
  @public-read, @private-modify, @not-nill
    element(xsi:decimal) salary;

  // Programmatic contructor, takes 4 arguments.
  @public
  Person(xsi:string a-first-name, xsi:string a-last-name, ns:employeeID a-id, xsi:decimal a-salary)
  {
    this/first-name = new element(xsi:string) {""};
    this/first-name/value::. = a-first-name/value::.;

    this/last-name = new element(xsi:string) {""};
    this/last-name/value::. = a-last-name/value::.;

    this/id = new attibute(ns:employeeID) {new ns:employeeID(0)};
    this/id/value::. = a-id/value::.;

    this/salary = new element(xsi:decimal) {0.0};
    this/salary/value::. = a-salary/value::.;
  }

  // Example method in this class.
  @public
  void give-raise(xsi:decimal percent)
  {
    //..."-:" below is an XPath shorthand for "value::."...
    salary/value = salary/-: * (1.0 + percent);
  }
}

Some features of this proposed language to point out:

An complex type may have one or more fields. Each field is an element or an attribute. The value type of the field is also declared.
XPath is used to traverse the object graph. For example, "this/first-name" is an XPath expression that resolves to the single "first-name" child element field of the node references by "this".
The type-specific content of attributes and elements can be accessed using the synthetic XPath axis "value::", which only allows a single suffix character ".". That is, the type-specific value of a node is accessed using the XPath expression "theNodeRef/value::.". A shorthand version "-:" could be invented, which means "theNodeRef/value::. == theNodeRef/-:" is true.
Code attributes are used to further shade the declaration of fields, classes, and methods. In the sample code above, each field has the code attributes "@public:read, @private:modify, @not-nill", which we assume a compiler and a runtime interpreter could understand.

A Moment of Silence, Please

Wed, 23 Apr 2003 19:26:33 GMT

Codd's work in practical computer science is an undenyable foundational pillar of the whole industry. Compared to people like him, even the cleverest developers must feel their efforts miniscule, their significance fleeting.

In the final accounting of my contributions to the world, may the logarithm of the magnitude of my impact compared to his be at least -4.

SF Now Supports RSS Feeds

Wed, 19 Mar 2003 19:03:57 GMT

Very cool. Now get project updates through your feed reader. Per-project and site-wide feeds available.