These are essential ingredients for an enterprise approach to web service solutions. Usefully, [...]]]> In project Metro – a java/glassfish web services stack – we have the Web Services Interoperability Technologies (WSIT) project. It caters for a number of novel, often security related, web service specifications, like  WS-Trust, WS-SecureConversation, WS-SecurityPolicy, WS-ReliableMessaging, WS-AtomicTransactions/Coordination, WS-MetadataExchange and SOAP over TCP.

These are essential ingredients for an enterprise approach to web service solutions. Usefully, the WSIT team has provided a longish list with explanations on the different security mechanism options you might employ with WSIT. This is an educational list w.r.t. what one’s security options in general are for secure messaging. So, let’s have a brief summary;

1. “Username Authentication with Symmetric Keys”: Client logs in with username, password. Client generates secret key with servers certificate and shares this with server.
2. “Mutual Certificates Security”: As with option 1, but this time bidirectionally. The server needs to know the client’s public certificate to provide a server generated key. Provides additional confidence in the client I guess.
3. “Transport Security”: Simply using certificates over SSL. Provides transport layer security such that application layer negotiation – ploicy, tokens, usernames as well as business content – can be done in privacy.
4. “Message Authentication over SSL”: Option 3 in addition to that the same certificates are used to send an authentication token with the message. I’m a bit unclear on what advantages this provides? It is also a bit unclear to me whether this, as is with SAML, one may use a separate identity provider for the generation of the authentication token.
5. “SAML Authorization over SSL”: Client requests a service. The service issues an authentication request back to the client. The client asks a SAML identity provider for an authentication token. The client forwards the token and requests the service again. Note that you don’t need to use a separate token service; the client may form the SAML assertion itself.
6. “Endorsing certificate”: A third party is used to countersign the message. The client asks a third party to countersign the message and the server verifies.
7. “SAML Sender Vouches with certificates”: A variant of the normal SAML, but where there is an intermediary acting on behalf of the end-user. The underlying problem here is to make sure that the SAML assertion corresponds to the SOAP request, i.e. that the request actually originates from the subject of the SAML assertion (Thanks to Glen Mazza for putting this in simple terms). In this case, an intermediary takes care of signing and packaging the SAML assertion and the SOAP request on behalf of a client. The client has typically been authenticated with the intermediary using some other means.
8. “SAML Holder-of-Key (HOK)”: In difference to option 7, here the client itself signs the SAML assertion and SOAP request package, making it possible to verify that the request originates from the subject of the SAML assertion.
9. “Secure Token Service (STS) issued token”: The client asks an STS identity provider for an authentication token. The client forwards the token and requests the service.

It seems a bit confusing to mix message level security (ws-security) and transport level security in the same list of mechanisms. I reason one might have message level security with or without transport level security. And vice versa. Generally it  seems that you have

• basic authentication,
• certificates/pki
• a third party serving as an identity provider (Brokered Authentication) and an
• endorsing mechanism.

In addition you may have transport layer security.

Another issue regards the difference between SAML and STS. My understanding is that the SAML protocol specifies

“Our study shows that the 114 reported drone strikes in northwest Pakistan, including 18 in 2010, from 2004 to the present have killed approximately between 834 and 1,216 individuals, of whom around 549 to 849 were described as militants in reliable press accounts, about 2/3 of total on average. Thus, the true civilian fatality [...]]]> Boingboing writes:

“Our study shows that the 114 reported drone strikes in northwest Pakistan, including 18 in 2010, from 2004 to the present have killed approximately between 834 and 1,216 individuals, of whom around 549 to 849 were described as militants in reliable press accounts, about 2/3 of total on average. Thus, the true civilian fatality rate since 2004 according to our analysis is approximately 32%.”.

They themselves quote http://counterterrorism.newamerica.net/drones.

It’s clearly hard to separate facts from fiction here. But 1/3 civilian casualty rate, if roughly right, is hard to justify I’d say.

I scratch my head, and find that

“These errors are related to SOAP 1.1 or 1.2 versions: SOAP 1.1 uses text/xml SOAP 1.2 uses application/soap+xml”

thanks to Adrian.

gets me nowhere however, as wget stops pretty fast and leaves a file that states

I can do ‘-e robots=off’ mixed with some stuff from  Voelkers excellent wget examples:

Additionally, I added to the invocation of mule a -debug flag, e.g. in the hello example;

2. Let’s look at the hello example; The config.xml file consists of a set of definitional items, e.g.

and then continues [...]]]> 1. You may attach a debugger by editing the wrapper.conf file;

wrapper.java.additional.3=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

Additionally, I added to the invocation of mule a -debug flag, e.g. in the hello example;

 exec "$MULE_BASE/bin/mule" -debug -config hello-http-config.xml

2. Let’s look at the hello example; The config.xml file consists of a set of definitional items, e.g.

 <custom-transformer name="StringToNameString"/>

and then continues with a model which consists of a set of services;

<model name="helloSample">

 <service name="GreeterUMO">

 </service>

 <service name="ChitChatUMO">

 </service>

 <service name="UserErrorHandler">

 </service>

 <service name="SystemErrorHandler">

 </service>

 </model>

Each service seems to feature an <inbound>, a <component> and an <outbound> section;

 <inbound>

 <inbound-endpoint address="http://localhost:8888" transformer-refs="HttpRequestToNameString" synchronous="true">

 </inbound-endpoint>

 <inbound-endpoint address="servlet://name" transformer-refs="HttpRequestToNameString" synchronous="true">

 </inbound-endpoint>

 <inbound-endpoint address="servlet://rest" transformer-refs="HttpRequestToParameter StringToNameString" responseTransformer-refs="PlainTextResponseTransformer" synchronous="true"/>

 <vm:inbound-endpoint path="greeter" transformer-refs="StringToNameString" synchronous="true"/>

 </inbound>

 <component/>

 <outbound>

 <filtering-router>

 <vm:outbound-endpoint path="chitchatter" synchronous="true"/>

 <payload-type-filter expectedType="org.mule.example.hello.NameString"/>

 </filtering-router>

 <filtering-router>

 <vm:outbound-endpoint path="userErrorHandler" synchronous="true"/>

 <payload-type-filter expectedType="java.lang.Exception"/>

 </filtering-router>

 </outbound>

 <!-- Route unexpected errors to separate error handler -->

 <default-service-exception-strategy>

 <vm:outbound-endpoint path="systemErrorHandler"/>

 </default-service-exception-strategy>

You may, it seems define multiple inbound-endpoints. It seems there is a vm:inbound-endpoint for every service and which precedes the component part.

2.1. outbound and inbound endpoints seem to match on path, e.g.

 <vm:outbound-endpoint path="chitchatter" synchronous="true"/>

matches

<vm:inbound-endpoint path="chitchatter" ../>

2.2. Which method on components are called? Seems there is a fair amount of reflection going on. With the

 <service name="ChitChatUMO">

 <inbound>

 <vm:inbound-endpoint path="chitchatter" transformer-refs="NameStringToChatString" responseTransformer-refs="ChatStringToString" synchronous="true"/>

 </inbound>

 <component/>

 </service>

mule will pick a unique public method from ChitChatter that doesn’t match

“ignoredMethods=[getClass, clone, equals, hashCode, getInvocationHandler, get*, wait, is*, notify, toString, notifyAll]”

If there are more than one match, you add a method parameter, url style;

 <vm:inbound-endpoint path="chitchatter?method=chat1"../>

2.3. How does Mule know which types to use when calling and filtering?

a. In <inbound-endpoint address=”http://localhost:8888″ transformer-refs=”HttpRequestToNameString” synchronous=”true”>

HttpRequestToNameString is an AbstractTranformer and returns a NameString.

b. Greeter.greet(NameString) receives this data.

c. In the filtering-router, the router selects according to type; <payload-type-filter expectedType=”org.mule.example.hello.NameString”/>

d. in  <vm:inbound-endpoint path=”chitchatter” transformer-refs=”NameStringToChatString” responseTransformer-refs=”ChatStringToString” synchronous=”true”/> the component class is called after the transformer NameStringToChatString is called. Input is then ok.

Anyway, one cannot help but think of how software engineering was before agile came along, when one works with this framework. A majority of [...]]]> I’m TOGAF certifying myself. Going through an 800 page book. Authorless by the way. A set of contributors are listed, but there are no editors and authors per se. That’s quite unusual.

Anyway, one cannot help but think of how software engineering was before agile came along, when one works with this framework. A majority of the methodological steps are about defining things (architectures and all that follows). As opposed to implementing and realizing. And the number of documents and textual deliverables is staggering. It seems so cumbersome and bureaucratic. It reminds me of the definitions, plans and specifications that were prescribed by pre-agile software development methods.

Now, the proponents of TOGAF will surely put forward that the framework must be tailored to the needs and constraints of the business and case at hand. And that one may, given the right circumstance, skip and trim to make the process lighter. Hmm.

That echoes arguments we heard from pre-agile s/w development method proponents when agile came with it’s fairly revolutionary approach as well.  And then there were the chorus from pre-agile s/w development method proponents saying that the agile way would go off the rails and it would be chaos without clear definitions and full specifications before the actual development could start.

I realize that enterprise architectural work is quite different from software development. And it might be that in fact you need to be as stringent and document centric as TOGAF prescribes.

But still..

Let’s say you have war A that renders some pages. Let’s say you’re writing another war (B)  and you suddenly want to reuse some ot the content from A. Let’s say you want to inherit, but also [...]]]> Hm.. what are my options when you want to reuse some visual content rendered by some other runtime component?

Let’s say you have war A that renders some pages. Let’s say you’re writing another war (B)  and you suddenly want to reuse some ot the content from A. Let’s say you want to inherit, but also tweak. Parameterize I guess. I could..

• do: jstl <c:import url=”<absolute or relative url>”/>in a jsp page. This includes rendered content however, so you don’t get to influence the content before rendering.

• do: response.sendRedirect(<absolute or relative url); on the server side. Ditto disadvantage as above.
• make a jsp taglib. I principle I guess you may put anything in the start and end tag methods, but in practice it is at best an unelegant method for reusing visual content with some size and layout
• use maven2’s war plugin’s overlay functionality. This works, but is somewhat crude, and requires good control over naming and directories.
• make a (jsf 2.0+) facelet taglib. No disadvantages, but a huge added bonus that you may include all kinds of fancy layout and composition as you would normally do with facelets. And paramterization works just fine.

So this last option is the only good option in my opinion. Let’s have a look;

Component A

In web.xml you define the taglib;

<context-param>
 <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
 <param-value>
 /META-INF/mfoTags.taglib.xml
 </param-value>
 </context-param>

In META-INF (nowhere else, or the inter-module/war dependency will not work) you define mfoTags.taglib.xml (and it needs to have both taglib and xml as postfixes) :

<?xml version="1.0" encoding="UTF-8"?>
 <facelet-taglib>
 <namespace>http://yarc.name/mfoFaceletTags</namespace>
 <tag>
 <tag-name>siteNav</tag-name>
 <source>../WEB-INF/tags/siteNav.xhtml</source>
 </tag>
 </facelet-taglib>

..and you need (at least) an empty faces-config.xml:

<?xml version="1.0"?>
<!DOCTYPE faces-config PUBLIC
 "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
 "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
</faces-config>

Finally, you need to package this as a jar (not a war). My solution here was to make a symbolic link since I wanted component A to remain a war since it is used as a war component on it’s own.

That’s it. Now for the user of this component;

Component B

You need to include a classpath ref to the above mentioned jar.

In the .xhtml file you’re going to refer to the facelet tag

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:mf="http://yarc.name/mfoFaceletTags"

...

>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 ...
 </head>
 <body>
 ...
 <mf:siteNav/>
 </body>
 </html>

–

If that isn’t simple and beautiful, then I don’t know what. Almost poetry.

Week-end time!

Thanks to Laliluna for small tricks and hints and the excellent facelet documentation.