Hello,
I am reasonably new to the webMethods world. And I am wondering if webMethods supports creadentials in WSSE headers? Also if webMethods supports SAML tokens in WSSE headers?
I understand that a Custom SOAP processor (according to chapter 7 of SOAP dev. guide> needs to be implemented to ensure AuthN/AuthZ happens. However, I fail to understand if webMethods expects user credentials in HPPT headers only.
Thanks
Cheers
G
Sure. Integration Server supports WS-Security using Username, X509 Certificate or SAML tokens…
Well, that is, if the custom soap processor that you write from scratch supports those things. IS, out-of-the-box lacks any and all support for WS-Security today.
I’ve written custom soap processors to handle authentication and optionally authorization based on Username and SAML tokens now for four different projects so I can say with certainty that it is very, very possible. It just takes a bit of work… OK, a lot of work.
If you want to use XML digital signature or XML encryption in your tokens or messages that also is possible, but with even more work.
The Infravio acquisition provides some hope that WS-* , XML digsig and XML encryption support is not that far away, but the work to integrate Infravio X-Broker (to be relabeled SOA Management) with Integration Server has yet to be done.
Take a look at some of the custom soap processor threads in this forum for ideas of what is involved. A custom soap processor is typically just a Flow (or java) service that pre-processes soap requests received by Integration Server. You can make that Flow service do anything you need before the requested operation is invoked. Harder than it should be by far, but very feasible and highly performant when done right.
Mark
Mark,
Thanks for the reply.
“Infravio acquisition” - does that mean wM is now a part of Infravio?
“custom soap processor…pre-processes SOAP…” - In this case, can one compare a custom SOAP processor to a JAX-RPC Handler? Well, I know you must be thinking NO RPC!!, but I come from a WSM product team (Confluent Software) background. We used AXIS handlers, mostly JAX-RPC, extensively for a while.
Well, if a SOAP Processor is more-or-less a request Handler, then can I assume, AuthN and AuthZ can be delegated to external entities? For instance, can one hook a SAML server to perform AuthN on user credentials and return tokens? And ofcourse token verification? And also, for AuthZ, can one plug a XACML PEP-PDP, instead of the built in ACL mechanism??
Thanks
Cheers
G
WM acquired Infravio last month. Infravio’s two products, X-Registry and X-Broker will replace webMethods ServiceNet soon. I start a proof-of-concept with X-Broker later this week which will be my first hands on with Infravio products.
I think the ServiceNet “agents” that were embedded inside app servers made use of JAX-RPC handlers. A very early design for the Integration Server 7.x web services support also apparently considered having developers write JAX-RPC handlers to do things like process soap headers (a design point that I didn’t favor).
The soap processor would get the entire soap request, extracting the token and sending it to a third party (such as an identity management policy server such as Netegrity) is very feasible. Of course, your soap client has to have some way of obtaining the SAML token. I looked briefly at using something like Ping Identity’s PingTrust for that purpose, but it was overkill for my current project which just needs Username tokens.
IS does support a pluggable authentication mechanism that could be used for this purpose by mapping a user represented in the token to an Integration Server user. However, I find it easier to delegate authorization to a third-party policy server that uses the fully qualified name of the service as the resource that is being requested. If the security checkpoint in the soap processor determines that the user represented in the token is not authorized to invoke the requested service, then that service is never invoked and a security exception is returned to the user in a soap fault (header fault to be picky).
Mark
Interesting you mentioned this Mark. This is the exact same thing that I am trying to work out if wM can handle. The third party policy server I have in mind is a XACML ref implementation (sourceforge). What I have in my mind is the following XACML request:
Subject: username or SAML token
Action: execute (for most cases)
Resouce: fully qualified Service name.
The PDP in XACML context would then apply a policy from an LDAP repository or what have you, to determine if the action is permitted. SAML token may be used to fetch the identity of the user, using SAML servers such as Netegrity or ID servers like former Oblix Coreid (now Oracle something). In addition to permit/deny, Obligations may also be returned by PDP for wM to honour.
Whats your opinion on this?
Cheers
G
It can be done, but since it’s all custom development, the more scope you add, the longer it will take.
I’m hopeful that Infravio’s X-Broker can serve as an intermediary to do much of the heaving lifting before the request makes it to IS. That should greatly reduce the custom development with the trade off of higher licensing costs.
If you have the time in the schedule and the in-house web services and Flow development expertise, you could save license costs by adding these features into an IS custom soap processor.
But, do your homework on the amount of effort requires to design, develop and support this functionality. Just because you can, doesn’t mean you should.
Mark
Thanks for your pointers in this regard Mark. I appreciate it.
Cheers
G
It was a much larger effort the first couple of times. Now that I’ve got the basic pattern, the work goes much, much quicker. Each project brings some new wrinkle: a new type of token, different third-party ID management vendors, new web services standards, but the core design of my custom soap processor has remained the same.
Yes, it should have been a part of IS some time ago, but once you build the basic custom soap processor, enhancing it to support new stuff that comes along is pretty straightforward.
Mark
Well, I am sure that is because of good design employed for the processor. IMHO, any design for a robust, scalable custom soap processor, functionalities must be designed as pluggable components.
This can be effectively realized using popular design patterns such as (Abstract)Factory, Chain of Responsibilities and Service Provider Interfaces.
Anyway, Mark, I am now looking for info on ServiceNet and Infravio. I m more interested in the capabilities of either of them, short comings and designs/architecture. Can you give me any pointers on where to look?
I have started with the WSM section of webMethods web site and am about to search this list.
Thanks
Cheers
Gautham
P.S. Mark, I had been away from work for a while and hence the delay in the reply.
ServiceNet is no longer being sold and has been effectively replaced with the Infravio X-Registry and X-Broker products. Both will get new names and will be released as webMethods products shortly after IntegrationWorld.
Mark
Oh okie,
Thanks for that Mark.
Any pointers on where I can look for detailed info. on webMethods and Infravio X-Registry/X-Broker?
I am assuming, from some of your previous posts, that security model is applicable on X-Broker and X-Registry is more or less a UDDI registry.
I just found out from Infravios’ web site that one of the flavors of X-Registry is a simple UDDI registry. However, I am now unsure I understand the roles of X-Reg. and X-Broker, in Infravios’ product lineup.
Please advice.
Cheers
Gautham Kasinath
The Infravio website is probably the best place for now, but I’m sure the info there will find its way to webMethods Advantage shortly.
Your regional sales manager can also arrange an evaluation of X-registry now or X-Broker after IW2006, if you have a legitimate business need.
Mark
Mark,
Whats IW2006?
Thanks
Gautham Kasinath
Hello again Mark,
I was wondering if you have been able to work on Infravios’ X-Broker (especially on the security infrastructure and extendability), since you mentioned this.
If yes, would you like to share a few pointers regarding the same?
I am not working on Infravio or ServiceNet at the moment, but was looking forward to learning from your experience, which may be handy when I do start working on them.
Thanks a bunch.
Regds
Gautham
Unfortunately, my POC has been delayed. However, it does appear that one can use Infravio’s X-Registry product to define security policies that can be expressed as WS-Policy-compliant policies and exported to a variety of enforcement points including XML appliances, app servers and, of course, X-Broker to be enforced as requests pass through these enforcement points playing the role of an intermediary.
I don’t know what limits exist on what types of security policies are supported by either Infravio products or by WS-Policy, but would certainly assume the most common security token profiles (Username, X509 and SAML) would be supported.
Check out the Infravio website for more details.
Hope that helps,
Mark