Category Archives: standards


I found CoScripter today at the Alphaworks site in the SOA & WebServices zone

I found this scripting language to be very helpful. Though in its early phase of development, its really impressive!

CoScripter is a system for recording, automating, and sharing business processes performed in a web browser such as printing photos online, requesting a vacation hold for postal mail, or checking a bank account balance. CoScripter lets you make a recording as you perform a procedure, play it back later automatically, and share it with your friends.

During my Experiments with using it, I felt there should have been following things

  1. Tab browsing
  2. Looping
  3. Calling scripts from other scripts.
  4. And may be browser support.. !?

I am sure the people at IBM Research must already know this, but still “my .002 (?) cents” in support for the same.

Currently un-supported features are listed here.

I am sure, any techie guy would surely love this feature.. at least to try out .

CoScripter is daam Cool! Give it a SHOT.. I am sure.. you would love it.

Technorati tags: , , , ,


Defective iPhone !

A news service here quotes that some experts have found a security flaw with iPhone.

The details are as

By David Raikow, CMP Channel
5:53 PM EDT Mon. Jul. 23, 2007

A team of security researchers say they have discovered a security flaw in Apple’s iPhone that would allow an attacker to take nearly complete control over a target device.

The group, which works for consulting and assessment firm Independent Security Evaluators (ISE), is withholding technical details until August 2 in order to give Apple time to fix the problem. They do claim, however, to have successfully exploited the vulnerability, and have posted a video of an attack on their website.

The vulnerability–known as a buffer overflow–lies in the Safari web browser built into the iPhone, said team member Charlie Miller.

By directing the browser to a web page containing malicious code, Miller says that his team has forced an iPhone to connect to a server and personal information contained on the device, including previous SMS text messages, contact information, call history, and voice mail data. By modifying the malicious code, an attacker could also have forced the phone to call out, send text messages, or record audio.

The ISE team noted several techniques an attacker could use to trick a user into accessing a malicious web site, including links embedded in email or online forum posts.

A more subtle attacker could set up a wireless router disguised as a free public access point, and then inject the malicious code into any page an iPhone user attempts to access.

The video on the team’s website shows just such an attack on a device attempting to access the New York Times website. As the iPhone can be configured to connect to wireless networks without asking the user, this could present a particularly effective attack.

Though browser vulnerabilities are not uncommon, Miller believes that this one is particularly bad because of weaknesses in the underlying security architecture of the iPhone. Apple’s approach, he says, appears to have focused on limiting the applications on the device and restricting how it can be accessed, rather than handling those applications in a secure fashion. Most significantly, iPhone appears to run applications with full administrative rights, giving a successful attacker those same privileges.

“Unfortunately,” the ISE team concluded in their paper, “once an iPhone application is breached by an attacker, very little prevents an attacker from obtaining complete control over the system.”

The ISE team released a draft whitepaper July 19 outlining the flaw. After reading the whitepaper, Paul Henry, Secure Computing’s Vice President of Technology Evangelism, agreed with Miller’s assessment of the iPhone’s security architecture. “Apple seems to have literally abandoned a core principle of the unix operating system: the rule of least privilege.”

Henry asserts, however, that the real underlying issue is inherent in the drive to put more functionality on smaller devices. “You simply don’t have the processing power on something like a phone to be able to handle properly securing it,” he told CRN. “Running applications as root–that’s a horsepower issue with the phones themselves. They’re trying to keep the CPU utilization down to acceptable levels to get that performance experience for the user.”

While Miller emphasized that vulnerabilities are an inevitable part of every piece of software and every computing device, he also argued that Apple’s reputation for security may have less to do with technical prowess than it’s relatively small user base.

“This wasn’t an easy bug to find, but it wasn’t that hard either,” Miller told CRN. “If people had been looking at Safari as hard as they look at Internet Explorer, this would have turned up awhile ago. Unfortunately, they may end up being victims of their own success.”

Miller says that the vulnerability also exists in the Mac OS X and Windows versions of Safari, but that he was uncertain if it would be exploitable on either platform as a practical matter. While a successful attack on the Mac or Windows versions could be serious, in neither case would the attacker gain the degree of access the ISE team claims to have achieved on the iPhone.

Apple has not responded to requests for comment.

The original story is here.

Technorati tags: , , , , , , , ,

Is this correct ?

Having SOA *stack* defeats the purpose of loose coupling itself ?


Regardless of the vendor, none has a so called *stack* where one could do a clean swap of components and thus achieve the flexibility and scalability !


Well, Standards with proprietary bindings !


Having a *stack* defeats the purpose of loose coupling itself.

Though, in some cases you could actually replace the components.. its very rare that you would see a re-mix of this SOA song.




SOAP-MSG protected by WS-Security has 3 possible issues in regards to SECURITY TOKEN.

  • Security Token format incompatibility
  • Security Token trust
  • Namespace differences

WS-TRUST addresses these issues by introducing a STS (Secure Token Service).

Example Scenario: –

In order to secure a communication between two parties, the two parties must exchange security credentials (either directly or indirectly). However, each party needs to determine if they can “trust” the asserted credentials of the other party. WS-TRUST specification defines extensions to [WS-Security] that provide:

· Methods for issuing, renewing, and validating security tokens.

· Ways to establish, assess the presence of, and broker trust relationships

The goal of WS-Trust is to enable applications to construct trusted [SOAP] message exchanges. This trust is represented through the exchange and brokering of security tokens. This specification provides a protocol agnostic way to issue, renew, and validate these security tokens.

Implementation Strategy

Web Services Trust Model


1. IBM® Tivoli® Federated Identity Manager provides an implementation of the WS-Trust specification. It acts as a STS.

2. Security Token Generation can be done by configuring WAS


1. Client understands X.509 certificates only.

2. Service understands SAML only.

  1. SOAP Gateway recognizes that it must map to SAML, so it contacts the STS.
  2. The STS sends back the token in the requested format.
  3. The gateway formats and sends the message for the service.

WS-TRUST addresses the security token needs of SOAP messages as

1. Format: An STS is used to exchange tokens into formats understandable by recipients.

2. Trust: The STS issues signed tokens forming the basis of trust for entities with which it has formed a trust relationship.

3. Namespace: The STS will return tokens in appropriate syntax for the recipient.

Discussions welcome. The doc. was created for introductory purposes.

Anything you wish should be added / removed / changed ? plz. let me know.

the doc. can be found here :  WS – TRUST

Technorati tags: , , , , , , , ,

WS – Specifications

While searching for materials on WebService Trust, I came across this presentation, which acts as a good introduction to the concept.

And also the following figure, which summarizes the web services specification stack.

WS-Secure Conversation : How to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys.

WS-Federation : How to manage and broker the trust relationships in a heterogeneous, federated environment including support for federated identities

WS-Authorization : How to manage authorization data and authorization policies.

WS-Policy : The capabilities and constraints of security and other business policies on intermediaries and endpoints (for example, required security tokens, supported encryption algorithms and privacy rules).

WS-Trust : A framework for trust models that enables Web services to securely


WS-Privacy : A model for how Web services and requesters state subject privacy

preferences and organizational privacy practice statements.

WS-Security : How to attach signature encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets (an encryption system developed at MIT), to messages.

Technorati tags: , , , , , , , , ,